Microsoft .NET Framework 3.5 추가 정보

• 1. 시스템 요구 사항
• 1.1. 지원되는 아키텍처
• 1.2. 지원되는 운영 체제
• 1.3. 하드웨어 요구 사항
• 2. 알려진 문제
• 2.1. 설치
• 2.2. 제거
• 2.3. 제품 문제
• 2.3.1. 일반적인 문제
• 2.3.2. WCF(Windows Communication Foundation)
• 2.3.3. WPF(Windows Presentation Foundation)
• 2.3.4. Windows WF(Workflow Foundation)
• 3. 관련 링크

1. 시스템 요구 사항

1.1. 지원되는 아키텍처

2.1.11. "설치 관리자에서 오류가 발생했습니다. 0x8007177f. 이 컴퓨터에서 파일을 암호화할 수 없습니다."

도메인의 Windows Vista 컴퓨터에서 업데이트를 설치할 때 오류 메시지가 표시됩니다. 오류 로그에 "이 구성 요소에 대한 오류 코드 6015" 또는 "설치 관리자에서 오류가 발생했습니다. 0x8007177f. 이 컴퓨터에서 파일을 암호화할 수 없습니다."라는 메시지가 있습니다.

이 문제를 해결하려면

http://support.microsoft.com/kb/933595에서 제공하는 업데이트를 적용합니다.

2.1.12. Print Spooler 서비스가 실행 중이 아니면 설치가 실패합니다.

XPSEPSC 구성 요소를 설치하려면 Print Spooler 서비스가 "시작됨" 상태로 실행 중이어야 합니다. Print Spooler 서비스가 실행되고 있지 않으면 XPSEPSC 설치 관리자가 실패합니다.

이 문제를 해결하려면

.NET Framework를 설치하기 전에 Print Spooler 서비스를 시작합니다. 이렇게 하려면 다음을 수행합니다.

1. 시작을 클릭하고 설정을 가리킨 다음 제어판을 클릭하고 관리 도구를 두 번 클릭합니다.

2. 서비스를 두 번 클릭하고 서비스(로컬)를 클릭하여 선택한 다음 Print Spooler를 마우스 오른쪽 단추로 클릭하고 속성을 클릭합니다.

3. 시작을 클릭한 다음 확인을 클릭합니다.

2.1.13. TFC에서는 적절한 .NET Framework 3.5 언어 팩이 설치되지 않습니다.

.NET Framework 3.5가 설치되어 있지 않은 시스템에 TFC를 설치하는 경우 TFC 설치 관리자는 TFC를 설치하는 동안 .NET Framework 3.5 구성 요소를 설치합니다. 그러나 설치 시 적절한 .NET Framework 3.5 언어 팩을 설치하지는 않습니다.

이 문제를 해결하려면

1. TFC를 설치한 후 사용자의 UI 언어에 해당하는 .NET Framework 3.5 언어 팩을 수동으로 설치합니다. 언어 팩은 다음 사이트에서 다운로드 할 수 있습니다.
http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=c78987b9-97f4-455f-bee7-f6bfa4ad774e

2. Change Language 드롭다운 목록에서 언어를 선택하고 다운로드 페이지의 다운로드 지침에 따라 적절한 언어 버전을 다운로드 합니다.

2.2. 제거

2.2.1. 64비트 .NET Framework 2.0을 제거하면 .NET Framework 1.1이 실행되지 않을 수도 있습니다.

.NET Framework 1.1의 원본 릴리스는 32비트 전용입니다. 또한 .NET Framework 1.1 설치 프로그램에는 64비트 운영 체제에서 설치를 차단하는 시작 조건이 있습니다. 원본 릴리스 이후 시작 조건을 무시하고 .NET Framework 1.1을 설치할 수 있도록 새로운 64비트 운영 체제에 shim이 추가되었습니다. 하지만 .NET Framework 1.1은 64비트 운영 체제에 설치한 후 64비트 운영 체제용으로 설계된 새로운 버전의 .NET Framework(예: .NET Framework 2.0)와 함께 사용할 수 있도록 설계되지 않았기 때문에 일부 .NET Framework Side-by-Side 제거 시나리오가 올바르게 작동하지 않습니다.

다음과 같은 시나리오의 경우 64비트 운영 체제에서 문제가 발생할 수 있습니다.

1. .NET Framework 1.1을 설치합니다.

2. .NET Framework 2.0을 설치합니다.

3. .NET Framework 2.0을 제거합니다.

이 시나리오에서 .NET Framework 2.0을 제거하면 .NET Framework 1.1에 사용되는 일부 레지스트리 항목이 제거되어 .NET Framework 1.1이 더 이상 올바르게 작동하지 않습니다. .NET Framework 2.0을 제거한 후에는 .NET Framework 1.1을 복구하여 필수 레지스트리 값을 복원해야 합니다.

이 문제를 해결하려면

다음 작업을 수행합니다.

1. .NET Framework 1.1 설치 패키지(dotnetfx.exe)를 다운로드합니다.

2. 시작 메뉴에서 실행을 클릭하고 “cmd”를 입력한 다음 확인을 클릭합니다.

3. 명령 <full path to dotnetfx.exe> /t:%temp% /c:"msiexec.exe /fvecms %temp%\netfx.msi"를 실행합니다.

.NET Framework 1.1 복구 지침은 .NET Framework 1.1이 설치되어 있는 컴퓨터의 %windir%\Microsoft.NET\Framework\v1.1.4322\1033\repairRedist.htm에 있습니다.

2.3. 제품 문제

2.3.1. 일반적인 문제

2.3.1.1. 프로그램 추가/제거의 지원 정보 대화 상자를 사용하여 .NET Framework 3.0 SP1을 복구하려면 제품 설치 원본의 경로를 지정해야 합니다.

프로그램 추가/제거의 지원 정보 대화 상자를 사용하여 .NET Framework 3.0 SP1을 복구하려면 제품 설치 원본의 경로를 지정해야 합니다.

이 문제를 해결하려면

프로그램 추가/제거에서 변경 옵션을 사용하여 .NET Framework 3.0 SP1을 복구합니다.

2.3.1.2. ASMX 추적 기능을 사용하면 SqlString serialization이 작동하지 않습니다.

SqlString 인스턴스를 보내거나 받는 ASP.NET 웹 서비스에 대해 ASMX 추적 기능을 사용하면 런타임에 ArgumentOutOfRangeException 오류가 발생합니다.

이 문제를 해결하려면

ASP .Net 웹 서비스에 대해 ASMX 추적 기능을 사용하지 않도록 설정합니다.

2.3.1.3. 3.5.0.0 버전을 2.0.0.0 버전으로 가정하기 때문에 .NET Framework 3.5에 포함되어 있는 System.Management.Instrumentation.dll에 대한 COM 등록이 올바르지 않습니다.

WMI(Windows Management Instrumentation) Provider Extensions 인프라를 사용하는 WMI 공급자에서 구현된 기능을 WMI 클라이언트에서 사용하려고 할 때 "공급자 로드 오류"가 발생합니다. DLL(동적 연결 라이브러리)이 잘못 등록되었기 때문입니다. .NET Framework 3.5를 설치하는 동안 System.Management.Instrumentation.dll이 올바르게 등록되지 않았기 때문에 COM 클라이언트에서 해당 DLL에 구현된 클래스를 사용할 수 없습니다.

이 문제를 해결하려면

1. 시작을 클릭한 다음 모든 프로그램을 클릭합니다.

2. Microsoft Visual Studio 2008을 클릭하고 Visual Studio Tools를 클릭합니다.

3. Windows Vista 이전의 Windows 운영 체제의 경우 Microsoft Visual Studio 2008 명령 프롬프트를 클릭하여 명령 프롬프트 창을 엽니다. Windows Vista 이후 운영 체제의 경우 Microsoft Visual Studio 2008 명령 프롬프트를 마우스 오른쪽 단추로 클릭한 다음 관리자 권한으로 실행을 클릭하여 관리자 권한 명령 프롬프트 창을 엽니다.

4. 명령 프롬프트에서 "regasm %systemdrive%\program files\reference assemblies\microsoft\framework\v3.5\system.management.instrumentation.dll"을 입력한 다음 Enter 키를 누릅니다.

참고: .NET Framework 3.5에 포함되어 있는 WMI Provider Extensions 기술을 사용하는 WMI 공급자를 작성하는 개발자는 공급자를 설치하기 전에 System.Management.Instrumentation.dll이 올바르게 등록되었는지 확인하고 필요한 경우 등록을 수정해야 합니다. 등록이 올바르지 않으면 공급자 오류가 발생합니다. http://go.microsoft.com/fwlink/?LinkID=103794의 절차에서는 이 DLL을 올바르게 등록하는 방법을 보여 줍니다.

2.3.1.4 ASP.NET에서 LinqDataSource가 런타임에 System.Security.SecurityException을 throw합니다.

.NET Framework 3.5 설치 프로그램의 일부로서, 일부 권한이 기본 구성 파일 web_mediumtrust.config 및 web_hightrust.config에 추가됩니다. 이 업데이트는 LinqDataSource를 보통 신뢰 또는 높은 신뢰 수준의 설정에서 사용하기 위해 필요합니다.

설치 관리자에서 사용자 지정 신뢰 구성 파일을 검색할 수 없으므로 수동으로 업데이트해야 합니다. 신뢰 설정을 업데이트하지 않으면 LinqDataSource 컨트롤에서 다음과 같은 런타임 예외가 발생할 수 있습니다. "System.Security.SecurityException: 'System.Security.Permissions.ReflectionPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' 형식의 사용 권한을 요청하지 못했습니다."

이 문제를 해결하려면

1. 일반적으로 %WINDIR%\Microsoft.NET\Framework\v2.0.50727\CONFIG\에 설치되어 있는 신뢰 구성 파일을 엽니다.

2. 이 파일에서 다음 두 가지 사항을 변경합니다.

- <SecurityClasses> 요소 아래에 다음과 같이 새 보안 클래스의 중첩 항목을 추가합니다.

                    <SecurityClasses>

                               ....

                                                <!-- this SecurityClass section is the work around for the compilation issue -->

                                                <SecurityClass

                                                                Name="ReflectionPermission"

                                                                Description="System.Security.Permissions.ReflectionPermission,

                                                                mscorlib,

                                                                Version=2.0.0.0, Culture=neutral,

                                                                PublicKeyToken=b77a5c561934e089"

                                />

                    </SecurityClasses>

- ASP.NET <PermissionSet>에 중첩된 <NamedPermissionSets> 섹션에서 아래와 같이 리플렉션 권한에 대해 <IPermission> 요소를 추가합니다.

                  <NamedPermissionSets>

                           <PermissionSet

                                  class="NamedPermissionSet"

                                  version="1"

                                 Name="ASP.NET">

                                 ...

                  <!-- this IPermission section is the work around for the reflection issue -->

   <IPermission
                            class="ReflectionPermission"
                                      version="1"
                                      Flags="RestrictedMemberAccess"
                    />

  </PermissionSet>

  ...

  </NamedPermission>

3. 파일을 저장하고 닫습니다.

2.3.1.5. Windows XP에서 .NET Framework 2.0, .NET Framework 3.0 또는 .NET Framework 3.5로 업그레이드하면 현재 사용자의 관리되는 기존 컨트롤 URL 동작을 덮어씁니다.

런타임을 .NET Framework 2.0 또는 .NET Framework 3.0에서 .NET Framework 3.5로 업그레이드하면 기본 설정이 현재 사용자의 관리되는 기존 코드 URL 동작을 덮어씁니다. 예를 들어, 사용자가 "사용 안 함"으로 설정한 URL 동작이 기본값인 "사용"으로 다시 설정될 수 있습니다.

영향을 받는 것으로 알려진 URL 동작은 "Authenticode로 서명되지 않은 구성 요소 실행"과 "Authenticode로 서명된 구성 요소 실행"입니다.

이 동작은 Windows XP에서만 발생하고 Windows 2003과 Windows Vista에서는 발생하지 않습니다.

이 동작은 .NET Framework 1.1을 .NET Framework 2.0으로 업그레이드할 때도 발생합니다.

이 문제를 해결하려면

.NET Framework를 업그레이드한 후 URL 동작을 수동으로 다시 설정해야 합니다.

2.3.1.6. Internet Explorer를 설치하는 동안 URL 동작 "매니페스트가 있는 구성 요소 권한"이 "사용 안 함"에서 "높음"으로 다시 설정됩니다.

Internet Explorer 6을 Internet Explorer 7로 업그레이드할 때 URL 동작 "매니페스트가 있는 구성 요소 권한"이 "사용 안 함"으로 설정되어 있으면 "높음"(기본값)으로 변경됩니다. 이는 Internet Explorer 7 설치 프로그램에서 해당 URL 동작이 기본값에서 변경되었음을 인식할 수 없기 때문에 발생하며, 결과적으로 URL 동작이 기본값으로 다시 설정됩니다. 이는 기본값인 약간 높음 보안 설정이 사용자가 이전에 선택한 설정보다 덜 제한적이므로 중요하게 고려해야 합니다.

이 문제를 해결하려면

업그레이드 후 URL 동작을 수동으로 다시 설정해야 합니다.

2.3.2. WCF(Windows Communication Foundation)

2.3.2.1. 메시지 보안 서명 전용 계약 요구 사항이 있는 wsHttpBinding에서 호환되지 않는 메시지가 생성됩니다.

wsHttpBinding 바인딩에서 메시지 보안이 사용될 때마다 WCF가 서비스의 보안 정책에 있는 <sp:EncryptSignature> 어설션을 내보냅니다. 전체 서비스 계약이 ProtectionLevel.Sign 또는 ProtectionLevel.None으로 설정되어 있고 계약의 작업 메시지에 암호화된 항목이 하나도 없는 경우(예: 사용자 이름 토큰) WCF가 보안 정책 사양과 호환되도록 <sp:EncryptSignature> 어설션을 내보내지 않습니다.

이 문제를 해결하려면

사용 가능한 해결 방법이 없습니다.

2.3.2.2. HTTPS 및 구성된 MEX 끝점이 사용된 경우 상대 externalMetadataLocation을 확인할 수 없습니다.

상대 ExternalMetadataLocation이 있는 ServiceMetadataBehavior를 사용하여 HTTPS를 통해 WCF 서비스에 대한 메타데이터 게시를 구성할 때 MEX(메타데이터 교환) 끝점이 구성되어 있으면 메타데이터 요청이 확인되지 않고, "config의 serviceMetadata 섹션에서 ExternalMetadataLocation 속성 또는 externalMetadataLocation 특성을 통해 ServiceMetadataBehavior에 제공된 URL이 상대 URL이며, 이 URL을 확인할 수 있는 기본 주소가 없습니다."라는 예외 메시지가 표시됩니다.

이 문제를 해결하려면

구성된 MEX 끝점을 WCF 서비스에서 모두 제거합니다.

2.3.2.3. 동작 변경: SSL 인증서 유효성 검사 및 인증서 경로

이전 버전까지는 IIS 또는 다른 웹 서버가 HTTPS를 사용하여 서버 인증서 대신 전체 서버 인증서 경로를 교환하도록 구성된 경우 중개 CA 인증서가 로컬 인증서 저장소에 없으면 WCF 클라이언트에서 서버의 인증서를 유효한 것으로 승인할 수 없었습니다. .NET Framework 버전 3.5에서는 WCF가 서버 인증서 확인을 위한 인증서 경로를 처리합니다.

이 문제를 해결하려면

필요한 해결 방법이 없습니다.

2.3.3. WPF(Windows Presentation Foundation)

알려진 문제가 없습니다.

2.3.4. Windows WF(Workflow Foundation)

2.3.4.1. Workflow Foundation 규칙에서 public이 아닌 확장 메서드를 사용할 수 없습니다.

워크플로 프로젝트에 정의되어 있는 public이 아닌 확장 메서드는 Workflow Foundation 규칙의 일부로 사용할 수 없습니다.

이 문제를 해결하려면

확장 메서드를 public으로 설정합니다.

3. 관련 링크

3.1. Visual Studio 2008 추가 정보: http://go.microsoft.com/fwlink/?LinkId=102508.

3.2. Visual Studio 2008 Express Editions 추가 정보: http://go.microsoft.com/fwlink/?LinkId=102509.

3.3. MSDN Library for Visual Studio 추가 정보: http://go.microsoft.com/fwlink/?LinkId=102512.

© 2007 Microsoft Corporation. All rights reserved. 사용 약관  | 상표  | 개인 정보 보호 정책