다음을 통해 공유

.NET Framework 4.6.x로의 마이그레이션을 위한 대상 다시 지정 변경 내용

  • 아티클

이 문서에는 .NET Framework 4.6, 4.6.1 및 4.6.2에서 발생한 앱 호환성 문제가 나열되어 있습니다.

.NET Framework 4.6

ASP.NET

HtmlTextWriter가 <br/> 요소를 올바르게 렌더링하지 않음

세부 정보

.NET Framework 4.6부터 <BR /> 요소로 RenderBeginTag(String) 및 RenderEndTag()를 호출하면 (두 개가 아닌) 단 하나의 <BR />만 올바르게 삽입합니다.

제안 해결 방법

응용 프로그램이 추가 <BR /> 태그에 종속된 경우 RenderBeginTag(String)를 두 번째로 호출해야 합니다. 이 동작 변경은 .NET Framework 4.6 이상을 대상으로 하는 응용 프로그램에만 영향을 주므로 다른 옵션은 이전 버전의 .NET Framework를 대상으로 하여 이전 동작을 가져오는 것입니다.

이름 값
Scope Microsoft Edge
버전 4.6
형식 대상 변경

영향을 받는 API

ClickOnce

SHA-256 코드 서명 인증서를 사용하는 ClickOnce로 게시된 앱이 Windows 2003에서 실패할 수 있음

설명

실행 파일이 SHA256으로 서명됩니다. 이전에는 코드 서명 인증서가 SHA-1 또는 SHA-256인지에 관계없이 SHA1로 서명되었습니다. 적용 대상:

  • Visual Studio 2012 이상으로 빌드된 모든 애플리케이션
  • .NET Framework 4.5가 있는 시스템에서 Visual Studio 2010 또는 이전 버전으로 빌드된 애플리케이션 또한 .NET Framework 4.5 이상이 있는 경우 컴파일 시의 대상 .NET Framework 버전에 관계없이 ClickOnce 매니페스트도 SHA-256 인증서에 대해 SHA-256으로 서명됩니다.

제안 해결 방법

ClickOnce 실행 파일의 서명 변경 내용은 Windows Server 2003 시스템에만 영향을 줍니다. KB 938397을 설치해야 합니다. 앱이 .NET Framework 4.0 또는 이전 버전을 대상으로 하는 경우에도 SHA-256으로 매니페스트에 서명하는 변경 내용으로 인해 .NET Framework 4.5 이상 버전에서 런타임 종속성이 발생합니다.

이름 값
Scope Microsoft Edge
버전 4.5
형식 대상 변경

ClickOnce가 4.0 대상 앱에서 SHA-256 지원

세부 정보

이전에 SHA-256으로 서명된 인증서가 있는 ClickOnce 앱은 앱이 4.0을 대상으로 하더라도 .NET Framework 4.5 이상이 필요했습니다. 이제 .NET Framework 4.0을 대상으로 하는 ClickOnce 앱을 SHA-256으로 서명한 경우에도 .NET Framework 4.0에서 실행할 수 있습니다.

제안 해결 방법

이 변경 내용은 해당 종속성을 제거하고 .NET Framework 4 이전 버전을 대상으로 하는 ClickOnce 앱을 SHA-256 인증서로 서명할 수 있게 합니다.

이름 값
Scope 부
버전 4.6
형식 대상 변경

핵심

CurrentCulture 및 CurrentUICulture가 작업에 걸쳐 전달됨

설명

.NET Framework 4.6부터 System.Globalization.CultureInfo.CurrentCulture 및 System.Globalization.CultureInfo.CurrentUICulture은 스레드의 System.Threading.ExecutionContext에 저장되며 비동기 작업을 통해 전달됩니다. 즉, System.Globalization.CultureInfo.CurrentCulture 또는 System.Globalization.CultureInfo.CurrentUICulture의 변경은 이후 비동기적으로 실행되는 작업에서 반영됩니다. 이는 모든 비동기 작업에서 System.Globalization.CultureInfo.CurrentCulture 및 System.Globalization.CultureInfo.CurrentUICulture을 다시 설정하는 이전 .NET Framework 버전의 동작과 다릅니다.

제안 해결 방법

이 변경의 영향을 받는 앱은 비동기 작업에서 원하는 System.Globalization.CultureInfo.CurrentCulture 또는 System.Globalization.CultureInfo.CurrentUICulture을 첫 번째 작업으로 명확하게 설정하여 문제를 해결할 수 있습니다. 또는 다음 호환성 스위치를 설정하여 System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture을 전달하지 않는 이전 동작을 옵트인할 수 있습니다.

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

이 문제는 .NET Framework 4.6.2의 WPF에서 해결되었습니다. 또한 KB 3139549를 통해 .NET Frameworks 4.6, 4.6.1에서 해결되었습니다. .NET Framework 4.6 이상을 대상으로 하는 애플리케이션은 디스패처 작업 전반에 걸쳐 WPF 애플리케이션(System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture)에서 올바른 동작을 자동으로 유지합니다.

이름 값
Scope 부
버전 4.6
형식 대상 변경

영향을 받는 API

ETW 이벤트 이름은 "Start" 또는 "Stop" 접미사만 다를 수 없음

설명

.NET Framework 4.6 및 4.6.1의 경우 두 개의 ETW(Windows용 이벤트 추적) 이벤트 이름이 "Start" 또는 "Stop" 접미사만 다를 때(예: 한 이벤트는 LogUser, 다른 이벤트는 LogUserStart라고 이름을 지정하는 경우) 런타임에서 ArgumentException을 throw합니다. 이 경우 런타임에서 로깅을 발생할 수 없는 이벤트 소스를 구성할 수 없습니다.

제안 해결 방법

예외를 방지하려면 두 이벤트 이름이 "Start" 또는 "Stop" 접미사만 다르지 않도록 하세요. 이 요구 사항은 .NET Framework 4.6.2부터 제거됩니다. 런타임은 "Start" 및 "Stop" 접미사만 다른 이벤트 이름을 명확하게 할 수 있습니다.

이름 값
Scope Microsoft Edge
버전 4.6
형식 대상 변경

Entity Framework

Visual Studio 2013을 사용하여 Entity Framework edmx를 빌드할 때 EntityDeploySplit 또는 EntityClean 작업을 사용하면 MSB4062 오류로 실패할 수 있음

설명

MSBuild 12.0 도구(Visual Studio 2013 포함)가 MSBuild 파일 위치를 변경하여 이전 Entity Framework 대상 파일을 유효하지 않게 했습니다. 그 결과로 EntityDeploySplit 및 EntityClean 작업이 Microsoft.Data.Entity.Build.Tasks.dll을 찾을 수 없어 실패합니다. 이 줄바꿈은 .NET Framework의 변경 때문이 아닌 도구 집합(MSBuild/VS) 변경 때문입니다. 이것은 단순히 .NET Framework를 업그레이드할 때가 아니라 개발자 도구를 업그레이드할 때에만 발생합니다.

제안 해결 방법

.NET Framework 4.6부터 Entity Framework 대상 파일은 새 MSBuild 레이아웃으로 작업하도록 수정되었습니다. 해당 버전의 Framework로 업그레이드하면 이 문제가 해결됩니다. 또는 이 해결 방법을 대상 파일을 직접 패치하는 데 사용할 수 있습니다.

이름 값
Scope 주요함
버전 4.5.1
형식 대상 변경

JIT

IL ret은 try 영역에서 허용되지 않음

세부 정보

JIT64 Just-In-Time 컴파일러와 달리 RyuJIT(.NET Framework 4.6에서 사용됨)는 try 영역에서 IL ret 명령을 허용하지 않습니다. try 영역에서 반환은 ECMA-335 사양에서 허용되지 않으며 이러한 IL을 생성하는 알려진 관리 컴파일러는 없습니다. 그러나 이러한 IL이 리플렉션 내보내기를 사용하여 생성된 경우에는 JIT64 컴파일러에서 실행됩니다.

제안 해결 방법

앱이 try 영역에 ret opcode가 포함된 IL을 생성하는 경우 앱은 .NET Framework 4.5를 대상으로 이전 JIT를 사용하고 이 중단을 피할 수 있습니다. 또는 생성된 IL이 try 영역 이후로 돌아가도록 업데이트될 수 있습니다.

이름 값
Scope Microsoft Edge
버전 4.6
형식 대상 변경

.NET Framework 4.6의 새로운 64비트 JIT 컴파일러

세부 정보

.NET Framework 4.6부터는 새로운 64비트 JIT 컴파일러가 Just-In-Time 컴파일에 사용됩니다. 경우에 따라 예기치 않은 예외가 throw되거나 32비트 컴파일러 또는 이전 64비트 JIT 컴파일러를 사용하여 앱을 실행하는 경우와 다른 동작이 관찰됩니다. 이 변경 내용은 32비트 JIT 컴파일러에는 영향을 주지 않습니다. 알려진 차이점은 다음과 같습니다.

  • 특정 상황에서 최적화가 설정된 릴리스 빌드에서 Unboxing 작업으로 인해 NullReferenceException이 throw될 수 있습니다.
  • 일부 경우에는 큰 메서드 본문의 프로덕션 코드가 실행될 때 StackOverflowException이 throw될 수 있습니다.
  • 특정 상황에서 메서드에 전달된 구조체가 릴리스 빌드에서 값 형식이 아닌 참조 형식으로 처리됩니다. 이 문제의 징후 중 하나는 컬렉션의 개별 항목이 예기치 않은 순서로 표시되는 것입니다.
  • 특정 상황에서 최적화가 사용되도록 설정되어 있을 경우 UInt16 값을 높은 비트의 집합과 비교하면 결과가 잘못됩니다.
  • 배열 값을 초기화할 때와 같은 특정 상황에서 OpCodes.Initblk IL 명령에 따라 메모리가 초기화되면 잘못된 값이 사용될 수 있습니다. 이로 인해 처리되지 않은 예외 또는 잘못된 출력이 발생할 수 있습니다.
  • 드물게 특정한 상황에서 컴파일러 최적화가 사용되도록 설정되면 조건부 비트 테스트가 잘못된 Boolean 값을 반환하거나 예외를 throw할 수 있습니다.
  • 특정 상황에서 try 블록을 시작하기 전에 if 문을 사용해서 조건을 테스트한 후에 try 블록을 종료하고 catch 또는 finally 블록에서 동일한 조건을 평가하면 새로운 64비트 JIT 컴파일러는 코드를 최적화할 때 catch 또는 finally 블록에서 if 조건을 제거합니다. 결과적으로 catch 또는 finally 블록에서 if 문 내의 코드가 무조건적으로 실행됩니다.

제안 해결 방법

알려진 문제 완화
위에 나열된 문제가 발생하는 경우 다음 중 하나를 수행하여 해결할 수 있습니다.

  • .NET Framework 4.6.2로 업그레이드합니다. .NET Framework 4.6.2에 포함된 새로운 64비트 컴파일러는 이러한 각각의 알려진 문제를 해결합니다.

  • Windows 업데이트를 실행하여 사용 중인 Windows 버전을 최신 상태로 유지합니다. .NET Framework 4.6 및 4.6.1에 대한 서비스 업데이트는 unboxing 작업의 NullReferenceException을 제외하고 이러한 각 문제를 해결합니다.

  • 이전 64비트 JIT 컴파일러를 사용하여 컴파일합니다. 방법에 대한 자세한 내용은 기타 문제 완화 섹션을 참조하세요. 기타 문제 완화
    이전 64비트 JIT 컴파일러 및 새로운 64비트 JIT 컴파일러를 사용하여 컴파일한 코드 또는 둘 다 새로운 64비트 JIT 컴파일러를 사용하여 컴파일한 앱의 디버그 버전 및 릴리스 버전 간 동작에서 다른 차이가 발생하는 경우 다음을 수행하여 이전 64비트 JIT 컴파일러로 앱을 컴파일할 수 있습니다.

  • 애플리케이션별로 < 요소를 애플리케이션의 구성 파일에 추가할 수 있습니다. 다음은 새로운 64비트 JIT 컴파일러를 사용하는 컴파일을 사용하지 않도록 설정하고, 대신 레거시 64비트 JIT 컴파일러를 사용합니다.

    <?xml version ="1.0"?>
<configuration>
  <runtime>
   <useLegacyJit enabled="1" />
  </runtime>
</configuration>

  • 사용자별로 레지스트리의 HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework 키에 useLegacyJit라는 REG_DWORD 값을 추가할 수 있습니다. 값이 1이면 레거시 64비트 JIT 컴파일러가 사용되도록 설정되고 값이 0이면 새로운 64비트 JIT 컴파일러가 사용되도록 설정됩니다.

  • 컴퓨터별로 레지스트리의 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework 키에 useLegacyJit라는 REG_DWORD 값을 추가할 수 있습니다. 값이 1이면 레거시 64비트 JIT 컴파일러가 사용되도록 설정되고 값이 0이면 새로운 64비트 JIT 컴파일러가 사용되도록 설정됩니다. Microsoft Connect에 버그를 보고하여 문제를 알릴 수도 있습니다.

이름 값
Scope Microsoft Edge
버전 4.6
형식 대상 변경

네트워킹

인증서 EKU OID 유효성 검사

설명

.NET Framework 4.6부터는 SslStream 또는 ServicePointManager 클래스가 EKU(향상된 키 사용) OID(개체 식별자) 유효성 검사를 수행합니다. EKU(향상된 키 사용) 확장은 키를 사용하는 애플리케이션을 나타내는 OID(개체 식별자)의 모음입니다. EKU OID 유효성 검사는 원격 인증서 콜백을 사용하여 원격 인증서가 원하는 용도에 맞는 올바른 OID를 갖도록 합니다.

제안 해결 방법

이 변경이 바람직하지 않은 경우 다음 스위치를 앱 구성 파일의 `에 있는 <AppContextSwitchOverrides>에 추가하여 인증서 EKU OID 유효성 검사를 해제할 수 있습니다.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontCheckCertificateEKUs=true" />
</runtime>

중요

이 설정은 이전 버전과의 호환성을 위해서만 제공됩니다. 그러나 사용하지 않는 것이 좋습니다.

이름 값
Scope 부
버전 4.6
형식 대상 변경

영향을 받는 API

System.Net.ServicePointManager 및 System.Net.Security.SslStream에서는 Tls 1.0, 1.1 및 1.2 프로토콜만 지원됨

세부 정보

.NET Framework 4.6부터 ServicePointManager 및 SslStream 클래스에서 Tls1.0, Tls1.1 또는 Tls1.2 프로토콜 중 하나만 사용할 수 있습니다. SSL3.0 프로토콜 및 RC4 암호화는 지원되지 않습니다.

제안 해결 방법

권장되는 완화 방법은 Tls1.0, Tls1.1 또는 Tls1.2로 서버 쪽 앱을 업그레이드하는 것입니다. 이 작업이 불가능하거나 클라이언트 앱이 손상된 경우 System.AppContext 클래스를 사용하여 다음 두 방법 중 하나로 이 기능을 옵트아웃(opt out)할 수 있습니다.

  • 여기에 설명된 대로 System.AppContext에서 compat 스위치를 프로그래밍 방식으로 설정되었습니다.
  • 다음 줄을 app.config 파일의 <runtime> 섹션에 추가
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
이름 값
Scope 부
버전 4.6
형식 대상 변경

영향을 받는 API

기본적으로 TLS 1.x는 SCH_SEND_AUX_RECORD 플래그를 기본 SCHANNEL API에 전달

세부 정보

TLS 1.x를 사용할 때 .NET Framework는 기본 Windows SCHANNEL API에 의존합니다. .NET Framework 4.6부터는 SCH_SEND_AUX_RECORD 플래그가 기본적으로 SCHANNEL로 전달됩니다. 이로 인해 SCHANNEL이 데이터를 두 개의 개별 레코드(첫 번째는 단일 바이트로, 두 번째는 n-1바이트로)로 암호화합니다. 드문 경우지만, 데이터가 단일 레코드에 상주한다고 가정하는 클라이언트와 기존 서버 사이의 통신이 끊어지기도 합니다.

제안 해결 방법

이 변경으로 인해 기존 서버와의 통신이 중단된 경우 SCH_SEND_AUX_RECORD 플래그 전송을 비활성화하고 앱 구성 파일의 <runtime> 섹션에 있는 <AppContextSwitchOverrides> 요소에 다음 스위치를 추가하여 데이터를 별도의 레코드로 분리하지 않는 이전 동작으로 복원할 수 있습니다.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchSendAuxRecord=true" />
</runtime>

중요

이 설정은 이전 버전과의 호환성을 위해서만 제공됩니다. 그러나 사용하지 않는 것이 좋습니다.

이름 값
Scope Microsoft Edge
버전 4.6
형식 대상 변경

영향을 받는 API

WCF(Windows Communication Foundation)

Null 인수를 사용한 CreateDefaultAuthorizationContext 호출이 변경되었습니다.

설명

Null authorizationPolicies를 사용하는 System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>)에 대한 호출로 반환된 System.IdentityModel.Policy.AuthorizationContext의 구현이 .NET Framework 4.6에서 변경되었습니다.

제안 해결 방법

드문 경우이지만 사용자 지정 인증을 사용하는 WCF 앱은 다르게 동작할 수 있습니다. 이러한 경우 두 가지 방법 중 하나로 이전 동작을 복원할 수 있습니다.

  • 4\.6 이전 버전의 .NET Framework를 대상으로 사용하도록 앱을 다시 컴파일합니다. IIS 호스트 서비스의 경우 이전 버전의.NET Framework를 대상으로 하는 <httpRuntime targetFramework="x.x"> 요소를 사용합니다.

  • 다음 줄을 app.config 파일의 <appSettings> 섹션에 추가합니다.

    <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
이름 값
Scope 부
버전 4.6
형식 대상 변경

영향을 받는 API

Windows Forms

Icon.ToBitmap은 PNG 프레임이 있는 아이콘을 Bitmap 개체로 성공적으로 변환합니다.

세부 정보

.NET Framework 4.6을 대상으로 하는 앱부터는 Icon.ToBitmap 메서드가 PNG 프레임이 있는 아이콘을 Bitmap 개체로 올바르게 변환합니다.

.NET Framework 4.5.2 및 이전 버전을 대상으로 하는 앱에서는 Icon 개체에 PNG 프레임이 있는 경우 Icon.ToBitmap 메서드가 ArgumentOutOfRangeException 예외를 throw합니다.

이 변경은 Icon 개체에 PNG 프레임이 있을 때 throw되는 ArgumentOutOfRangeException에 대해 특수 처리를 구현하고 .NET Framework 4.6을 대상으로 다시 컴파일되는 앱에 영향을 줍니다. .NET Framework 4.6에서 실행되는 경우 변환이 성공하고 ArgumentOutOfRangeException 이 더 이상 throw되지 않습니다. 따라서 예외 처리기가 더 이상 호출되지 않습니다.

제안 해결 방법

이 동작이 필요 없는 경우 app.config 파일의 <runtime> 섹션에 다음 요소를 추가하여 이전 동작을 유지할 수 있습니다.

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true" />

App.config 파일에 이미 AppContextSwitchOverrides 요소가 포함되어 있는 경우 새 값은 다음과 같이 값 특성과 병합되어야 합니다.

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
이름 값
Scope 부
버전 4.6
형식 대상 변경

영향을 받는 API

WPF(Windows Presentation Foundation)

CurrentCulture는 WPF 발송자 작업 간에 유지되지 않습니다.

설명

.NET Framework 4.6부터, System.Windows.Threading.Dispatcher 내에서 수행된 System.Globalization.CultureInfo.CurrentCulture 또는 System.Globalization.CultureInfo.CurrentUICulture에 대한 변경 내용은 해당 디스패처 작업이 끝날 때 손실됩니다. 마찬가지로, 디스패처 작업 외부에서 수행된 System.Globalization.CultureInfo.CurrentCulture 또는 System.Globalization.CultureInfo.CurrentUICulture의 변경 내용은 해당 작업이 실행될 때 반영되지 않을 수 있습니다. 실제로 이는 System.Globalization.CultureInfo.CurrentCulture 및 System.Globalization.CultureInfo.CurrentUICulture 변경 내용이 WPF UI 콜백과 WPF 애플리케이션의 다른 코드 간에 흐르지 않을 수 있음을 의미합니다. 이는 .NET Framework 4.6을 대상으로 하는 앱부터 System.Threading.ExecutionContext이 System.Globalization.CultureInfo.CurrentCulture 및 System.Globalization.CultureInfo.CurrentUICulture을 실행 컨텍스트에 저장하도록 변경되었기 때문입니다. WPF 발송자 작업이 작업을 시작할 때 사용된 실행 컨텍스트를 저장하고 작업이 완료되면 이전의 컨텍스트를 복원합니다. 이제는 System.Globalization.CultureInfo.CurrentCulture 및 System.Globalization.CultureInfo.CurrentUICulture가 해당 컨텍스트의 일부이므로 발송자 작업 내의 해당 속성 변경 내용이 작업 외부에서 유지되지 않습니다.

제안 해결 방법

이 변경의 영향을 받는 앱은 원하는 System.Globalization.CultureInfo.CurrentCulture 또는 System.Globalization.CultureInfo.CurrentUICulture를 필드에 저장하고 올바른 System.Globalization.CultureInfo.CurrentCulture 및 System.Globalization.CultureInfo.CurrentUICulture가 설정되도록 모든 디스패처 작업 본문(UI 이벤트 콜백 처리기 포함)을 확인하여 문제를 해결할 수 있습니다. 또는 이 WPF 변경 내용에 기반을 둔 ExecutionContext 변경 내용이 .NET Framework 4.6 이상을 대상으로 하는 앱에만 영향을 주기 때문에 대상을 .NET Framework 4.5.2로 변경하면 이 문제를 방지할 수 있습니다. 또한 .NET Framework 4.6 이상을 대상으로 하는 앱은 다음 호환성 스위치를 설정하여 이 문제를 해결할 수도 있습니다.

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

이 문제는 .NET Framework 4.6.2의 WPF에서 해결되었습니다. 또한 KB 3139549를 통해 .NET Frameworks 4.6, 4.6.1에서 해결되었습니다. .NET Framework 4.6 이상을 대상으로 하는 애플리케이션은 디스패처 작업 전반에 걸쳐 WPF 애플리케이션(System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture)에서 올바른 동작을 자동으로 유지합니다.

이름 값
Scope 부
버전 4.6
형식 대상 변경

여백의 WPF 레이아웃 반올림이 변경됨

세부 정보

여백이 반올림되는 방식과 그 안의 테두리 및 배경이 변경되었습니다. 레이아웃을 변경한 결과는 다음과 같습니다.

  • 요소의 너비나 높이가 최대 1픽셀씩 늘어나거나 줄어들 수 있습니다.
  • 개체의 배치가 최대 1픽셀씩 이동할 수 있습니다.
  • 가운데 맞춤 요소가 가로 또는 세로로 최대 1픽셀씩 가운데에서 벗어날 수 있습니다. 기본적으로 이 새 레이아웃은 .NET Framework 4.6을 대상으로 하는 앱에 대해서만 사용할 수 있습니다.

제안 해결 방법

이 수정은 높은 DPI에서 WPF 컨트롤의 오른쪽 또는 아래쪽의 클리핑을 제거하는 경향이 있으므로 이전 버전의 .NET Framework를 대상으로 하지만 NET Framework 4.6에서 실행되는 앱은 다음 줄을 app.config 파일의 <runtime> 섹션에 추가하여 이 새 동작을 옵트인(opt in)할 수 있습니다.

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />

.NET Framework 4.6을 대상으로 하지만 이전 레이아웃 알고리즘을 사용하여 WPF 컨트롤을 렌더링하려는 앱은 다음 줄을 app.config 파일의 <runtime> 섹션에 추가하여 수행할 수 있습니다.

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />
이름 값
Scope 부
버전 4.6
형식 대상 변경

XML, XSLT

잘못된 서로게이트 쌍에서 XmlWriter가 throw함

세부 정보

.NET Framework 4.5.2 또는 이전 버전을 대상으로 하는 앱의 경우 예외 대체(fallback) 처리를 사용하여 잘못된 서로게이트 쌍을 작성해도 항상 예외가 발생하지는 않습니다. .NET Framework 4.6을 대상으로 하는 앱의 경우 잘못된 서로게이트 쌍을 쓰려고 하면 System.ArgumentException을 throw합니다.

제안 해결 방법

필요한 경우 .NET Framework 4.5.2 이전 버전을 대상으로 하여 이 중단을 피할 수 있습니다. 또는 잘못된 서로게이트 쌍을 쓰기 전에 유효한 xml로 사전 처리할 수 있습니다.

이름 값
Scope Microsoft Edge
버전 4.6
형식 대상 변경

영향을 받는 API

복합 키를 사용하고 하나의 키가 비어 있는 경우 XSD 스키마 유효성 검사는 이제 올바르게 UNIQUE 제약 조건 위반을 감지함

세부 정보

.NET Framework 4.6 이전 버전은 키 중 하나가 비어있는 경우 XSD 유효성 검사가 복합 키에서 UNIQUE 제약 조건을 감지하지 않는 버그가 있었습니다. .NET Framework 4.6에서 이 문제가 수정되었습니다. 이렇게 하면 보다 정확한 유효성 검사가 되지만 이전에 검사되었던 일부 XML이 유효성 검사되지 않는 결과를 발생시킬 수 있습니다.

제안 해결 방법

완화된 .NET Framework 4.0 유효성 검사가 필요한 경우 유효성 검사 애플리케이션은 .NET Framework 4.5(또는 이전) 버전을 대상으로 할 수 있습니다. 하지만 .NET Framework 4.6으로 다시 대상을 지정하는 경우 중복 복합 키가 (이 문제 설명에 기술된 것처럼) 유효성 검사되지 않도록 코드 검토를 수행해야 합니다.

이름 값
Scope Microsoft Edge
버전 4.6
형식 대상 변경

.NET Framework 4.6.1

코어

ZipArchiveEntry 개체의 FullName 속성에서 경로 구분 문자 변경

설명

.NET Framework 4.6.1 이상 버전을 대상으로 하는 앱의 경우 CreateFromDirectory 메서드의 오버로드를 통해 생성된 ZipArchiveEntry 개체의 FullName 속성에서 경로 구분 문자가 백슬래시("\")에서 슬래시("/")로 변경되었습니다. 이 변경으로 인해 .NET 구현은 .ZIP 파일 형식 사양의 섹션 4.4.17.1과 일치하게 되고 비 Windows 시스템에서.ZIP 아카이브의 압축이 풀리게 됩니다.
Macintosh와 같은 비 Windows 운영 체제에서 이전 버전의 .NET Framework를 대상으로 하는 앱이 생성한 zip 파일의 압축을 풀면 디렉터리 구조가 유지되지 않습니다. 예를 들어 Macintosh에서는 해당 파일 이름이 디렉터리 경로, 백슬래시("\") 문자 및 파일 이름으로 연결된 파일 집합이 만들어집니다. 결과적으로 압축을 푼 파일의 디렉터리 구조는 유지되지 않습니다.

제안 해결 방법

.NET Framework System.IO 네임스페이스의 API는 슬래시("/") 또는 백슬래시("\")를 경로 구분 문자로 원활하게 처리할 수 있으므로 해당 API에 의해 Windows 운영 체제에서 압축 해제된 .ZIP 파일에 해당 변경이 미치는 영향은 최소로 유지될 것입니다.
이 변경을 원치 않을 경우 애플리케이션 구성 파일의 <runtime> 섹션에 구성 설정을 추가하여 옵트아웃할 수 있습니다. 다음 예제에서는 <runtime> 섹션 및 Switch.System.IO.Compression.ZipFile.UseBackslash 옵트아웃 스위치를 모두 보여줍니다.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
</runtime>

또한 이전 버전의 .NET Framework를 대상으로 하지만 .NET Framework 4.6.1 이상 버전에서 실행되는 앱은 애플리케이션 구성 파일의 <runtime> 섹션에 구성 설정을 추가하여 이 동작을 옵트인할 수 있습니다. 다음에서는 <runtime> 섹션 및 Switch.System.IO.Compression.ZipFile.UseBackslash 옵트인 스위치를 모두 보여줍니다.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
이름 값
Scope Microsoft Edge
버전 4.6.1
형식 대상 변경

영향을 받는 API

WCF(Windows Communication Foundation)

TransportWithMessageCredential 보안 모드로 WCF 바인딩

설명

.NET Framework 4.6.1부터는 TransportWithMessageCredential 보안 모드를 사용하는 WCF 바인딩이 비대칭 보안 키의 헤더에 대해 서명되지 않은 "to" 헤더가 있는 메시지를 받도록 설정할 수 있습니다. 기본적으로 서명되지 않은 "to" 헤더는 .NET Framework 4.6.1에서 계속 거부됩니다. 애플리케이션이 Switch.System.ServiceModel.AllowUnsignedToHeader 구성 스위치를 사용하여 이 새로운 작업 모드를 옵트인하는 경우에만 허용됩니다.

제안 해결 방법

이 기능은 옵트인 기능이기 때문에 기존 앱의 동작에는 영향을 주지 않습니다.
새 동작을 사용할지 여부를 제어하려면 다음 구성 설정을 사용합니다.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
이름 값
Scope 투명
버전 4.6.1
형식 대상 변경

영향을 받는 API

X509CertificateClaimSet.FindClaims가 모든 claimTypes를 고려

설명

.NET Framework 4.6.1을 대상으로 하는 앱에서 X509 클레임 집합이 해당 SAN 필드에 여러 DNS 항목이 있는 인증서로부터 초기화되는 경우 System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) 메서드가 claimType 인수를 모든 DNS 항목과 일치시키려고 합니다. 이전 버전의 .NET Framework를 대상으로 하는 앱의 경우 System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) 메서드는 claimType 인수를 마지막 DNS 항목과 일치시키려고 시도합니다.

제안 해결 방법

이 변경은 .NET Framework 4.6.1을 대상으로 하는 애플리케이션에만 영향을 줍니다. 이 변경 내용은 DisableMultipleDNSEntries 호환성 스위치로 비활성화(또는 4.6.1 전 버전을 대상으로 하는 경우 활성화)될 수 있습니다.

이름 값
Scope 부
버전 4.6.1
형식 대상 변경

영향을 받는 API

Windows Forms

Application.FilterMessage는 IMessageFilter.PreFilterMessage의 재진입 구현에 대해 더 이상 throw하지 않음

세부 정보

.NET Framework 4.6.1에 앞서 System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) 또는 System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter)라고 하는 PreFilterMessage(Message)를 사용하여 FilterMessage(Message)을 호출하면(DoEvents()도 호출하면서) System.IndexOutOfRangeException을 발생시킵니다.

4.6.1.NET Framework를 대상으로 하는 애플리케이션부터 이 예외는 더 이상 throw되지 않으며 위에서 설명한 것처럼 재진입 필터가 사용될 수 있습니다.

제안 해결 방법

위에서 설명한 재진입 PreFilterMessage(Message) 동작 때문에 FilterMessage(Message)가 더 이상 throw되지 않습니다. 이는 .NET Framework 4.6.1을 대상으로 하는 애플리케이션에만 영향을 줍니다. .NET Framework 4.6.1을 대상으로 하는 애플리케이션은 DontSupportReentrantFilterMessage 호환성 스위치를 사용하여 이 변경을 옵트아웃(또는 이전 프레임워크를 대상으로 하는 애플리케이션은 옵트인)할 수 있습니다.

이름 값
Scope Microsoft Edge
버전 4.6.1
형식 대상 변경

영향을 받는 API

WPF(Windows Presentation Foundation)

터치 지원 시스템에서 System.Windows.Input.PenContext.Disable 호출하면 ArgumentException이 throw될 수 있음

설명

상황에 따라 터치 지원 시스템에서 내부 System.Windows.Input.PenContext.Disable 메서드를 호출하면 재진입 때문에 처리되지 않은 T:System.ArgumentException가 throw될 수 있습니다.

제안 해결 방법

이 문제는 .NET Framework 4.7에서 해결되었습니다. 예외를 방지하려면 .NET Framework 4.7 이상의 .NET Framework 버전으로 업그레이드합니다.

이름 값
Scope Microsoft Edge
버전 4.6.1
형식 대상 변경

.NET Framework 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath가 NullReferenceException을 Throw함

세부 정보

.NET Framework 4.6.2에서 런타임은 null 문자를 포함하는 P:System.Web.HttpRuntime.AppDomainAppPath 값을 검색할 때 T:System.NullReferenceException를 throw합니다. .NET Framework 4.6.1 이전 버전에서 런타임은 T:System.ArgumentNullException를 throw합니다.

제안 해결 방법

이러한 변경에 대처하기 위해 다음 중 하나를 수행할 수 있습니다.

  • 애플리케이션이 .NET Framework 4.6.2에서 실행 중인 경우 T:System.NullReferenceException를 처리합니다.
  • .NET Framework 4.7로 업그레이드하면 이전 동작이 복원되고 T:System.ArgumentNullException가 throw됩니다.
이름 값
Scope Microsoft Edge
버전 4.6.2
형식 대상 변경

영향을 받는 API

핵심

AesCryptoServiceProvider 암호 해독기가 재사용 가능한 변환을 제공

설명

.NET Framework 4.6.2를 대상으로 하는 앱부터는 AesCryptoServiceProvider 암호 해독기가 재사용 가능 변환을 제공합니다. System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32)을 호출하고 나면 변환이 다시 초기화되므로 재사용할 수 있습니다. 이전 버전 .NET Framework를 대상으로 하는 앱의 경우 System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32)를 호출한 후에 System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32)를 호출하여 암호 해독기를 재사용하려고 하면 CryptographicException가 throw되거나 손상된 데이터가 생성됩니다.

제안 해결 방법

이것이 예상된 동작이므로 이 변경의 영향은 최소화되어야 합니다. 이전 동작에 의존하는 애플리케이션은 애플리케이션 구성 파일의 <runtime> 섹션에 다음 구성 설정을 추가하여 이 동작을 옵트아웃할 수 있습니다.

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=true"/>
</runtime>

또한 이전 버전의 .NET Framework를 대상으로 하지만 .NET Framework 4.6.2부터 시작하는 .NET Framework 버전에서 실행되는 애플리케이션은 애플리케이션 구성 파일의 <runtime> 섹션에 다음 구성 설정을 추가하여 이 동작을 옵트인할 수 있습니다.

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>
이름 값
Scope 부
버전 4.6.2
형식 대상 변경

영향을 받는 API

ClaimsIdentity 생성자 호출

설명

.NET Framework 4.6.2부터는 System.Security.Principal.IIdentity 매개 변수로 ClaimsIdentity 생성자가 System.Security.Claims.ClaimsIdentity.Actor 속성을 설정하는 방법이 변경되었습니다. System.Security.Principal.IIdentity 인수가 ClaimsIdentity 개체이고 해당 ClaimsIdentity 개체의 System.Security.Claims.ClaimsIdentity.Actor 속성이 null이 아닌 경우 Clone() 메서드를 사용하여 System.Security.Claims.ClaimsIdentity.Actor 속성이 연결됩니다. Framework 4.6.1 이전 버전에서 System.Security.Claims.ClaimsIdentity.Actor 속성은 기존 참조로 첨부됩니다. 이 변경으로 인해 .NET Framework 4.6.2부터는 새 ClaimsIdentity 개체의 System.Security.Claims.ClaimsIdentity.Actor 속성이 생성자의 System.Security.Principal.IIdentity 인수의 System.Security.Claims.ClaimsIdentity.Actor 속성과 같지 않습니다. .NET Framework 4.6.1 이전 버전에서는 이 속성이 같습니다.

제안 해결 방법

이 동작을 원치 않을 경우 애플리케이션 구성 파일에서 Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity 스위치를 true로 설정하여 이전 동작을 복원할 수 있습니다. 이렇게 하려면 web.config 파일의 <runtime> 섹션에 다음을 추가해야 합니다.

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>
이름 값
Scope Microsoft Edge
버전 4.6.2
형식 대상 변경

영향을 받는 API

경로 정규화의 변경

설명

.NET Framework 4.6.2를 대상으로 하는 앱부터 런타임이 경로를 정규화하는 방식이 변경되었습니다. 경로 정규화 중에는 대상 운영 체제의 올바른 경로에 맞게 경로 또는 파일을 식별하는 문자열이 수정됩니다. 정규화에는 일반적으로 다음이 수행됩니다.

  • 구성 요소 및 디렉터리 구분 기호 정규화
  • 상대 경로에 현재 디렉터리 적용
  • 경로의 상대 디렉터리(.) 또는 부모 디렉터리(..) 평가
  • 지정된 문자 자르기 .NET Framework 4.6.2를 대상으로 하는 앱부터는 경로 정규화의 다음 변경이 기본적으로 사용됩니다.
    • 런타임은 운영 체제의 GetFullPathName 함수를 지연시켜 경로를 정규화합니다.
  • 정규화 중에 더 이상 디렉터리 세그먼트의 끝(예: 디렉터리 이름 끝의 공백)이 잘리지 않습니다.
  • 완전 신뢰의 디바이스 경로 구문(\\.\ 포함) 지원 및 mscorlib.dll \\?\에서 파일 I/O API 지원
  • 런타임에서 디바이스 구문 경로가 유효한지 확인하지 않습니다.
  • 대체 데이터 스트림에 액세스하기 위해 디바이스 구문을 사용할 수 있습니다. 이 변경 내용을 통해 메서드에서 이전에 액세스할 수 없는 경로에 액세스할 수 있게 되며 성능이 향상됩니다. .NET Framework 4.6.1 이하 버전을 대상으로 하지만 .NET Framework 4.6.2 이상에서 실행되는 앱은 이러한 변경에 의해 영향을 받지 않습니다.

제안 해결 방법

.NET Framework 4.6.2 이상을 대상으로 하는 앱은 애플리케이션 구성 파일의 <runtime> 섹션에 다음을 추가하여 이 변경을 옵트아웃하고 레거시 정규화를 사용할 수 있습니다.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=true" />
</runtime>

.NET Framework 4.6.1 이하를 대상으로 하지만 .NET Framework 4.6.2 이상에서 실행되는 앱은 애플리케이션 구성 파일의 <runtime> 섹션에 다음 줄을 추가하여 경로 정규화에 변경을 사용할 수 있습니다.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
이름 값
Scope 부
버전 4.6.2
형식 대상 변경

CurrentCulture 및 CurrentUICulture가 작업에 걸쳐 전달됨

설명

.NET Framework 4.6부터 System.Globalization.CultureInfo.CurrentCulture 및 System.Globalization.CultureInfo.CurrentUICulture은 스레드의 System.Threading.ExecutionContext에 저장되며 비동기 작업을 통해 전달됩니다. 즉, System.Globalization.CultureInfo.CurrentCulture 또는 System.Globalization.CultureInfo.CurrentUICulture의 변경은 이후 비동기적으로 실행되는 작업에서 반영됩니다. 이는 모든 비동기 작업에서 System.Globalization.CultureInfo.CurrentCulture 및 System.Globalization.CultureInfo.CurrentUICulture을 다시 설정하는 이전 .NET Framework 버전의 동작과 다릅니다.

제안 해결 방법

이 변경의 영향을 받는 앱은 비동기 작업에서 원하는 System.Globalization.CultureInfo.CurrentCulture 또는 System.Globalization.CultureInfo.CurrentUICulture을 첫 번째 작업으로 명확하게 설정하여 문제를 해결할 수 있습니다. 또는 다음 호환성 스위치를 설정하여 System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture을 전달하지 않는 이전 동작을 옵트인할 수 있습니다.

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

이 문제는 .NET Framework 4.6.2의 WPF에서 해결되었습니다. 또한 KB 3139549를 통해 .NET Frameworks 4.6, 4.6.1에서 해결되었습니다. .NET Framework 4.6 이상을 대상으로 하는 애플리케이션은 디스패처 작업 전반에 걸쳐 WPF 애플리케이션(System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture)에서 올바른 동작을 자동으로 유지합니다.

이름 값
Scope 부
버전 4.6
형식 대상 변경

영향을 받는 API

ETW 이벤트 이름은 "Start" 또는 "Stop" 접미사만 다를 수 없음

설명

.NET Framework 4.6 및 4.6.1의 경우 두 개의 ETW(Windows용 이벤트 추적) 이벤트 이름이 "Start" 또는 "Stop" 접미사만 다를 때(예: 한 이벤트는 LogUser, 다른 이벤트는 LogUserStart라고 이름을 지정하는 경우) 런타임에서 ArgumentException을 throw합니다. 이 경우 런타임에서 로깅을 발생할 수 없는 이벤트 소스를 구성할 수 없습니다.

제안 해결 방법

예외를 방지하려면 두 이벤트 이름이 "Start" 또는 "Stop" 접미사만 다르지 않도록 하세요. 이 요구 사항은 .NET Framework 4.6.2부터 제거됩니다. 런타임은 "Start" 및 "Stop" 접미사만 다른 이벤트 이름을 명확하게 할 수 있습니다.

이름 값
Scope Microsoft Edge
버전 4.6
형식 대상 변경

긴 경로 지원

설명

.NET Framework 4.6.2를 대상으로 하는 앱부터 긴 경로(최대 32K자)가 지원되고 260자(또는 MAX_PATH)의 경로 길이 제한이 제거되었습니다. .NET Framework 4.6.2를 대상으로 다시 컴파일된 앱의 경우, 이전에는 260자를 초과했기 때문에 System.IO.PathTooLongException을 throw했던 코드 경로는 이제 다음 조건에서만 System.IO.PathTooLongException을 throw합니다.

  • 경로의 길이가 MaxValue(32,767)자보다 긴 경우
  • 운영 체제가 COR_E_PATHTOOLONG 또는 동급을 반환하는 경우 .NET Framework 4.6.1 이하 버전을 대상으로 하는 앱의 경우, 경로가 260자를 초과할 때마다 런타임에서 자동으로 System.IO.PathTooLongException을 throw합니다.

제안 해결 방법

.NET Framework 4.6.2를 대상으로 하는 앱의 경우, 필요하지 않으면 app.config 파일의 <runtime> 섹션에 다음을 추가하여 긴 경로 지원을 옵트아웃할 수 있습니다.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=true" />
</runtime>

이전 버전의 .NET Framework를 대상으로 하지만 .NET Framework 4.6.2 이상에서 실행되는 앱의 경우 app.config 파일의 <runtime> 섹션에 다음 줄을 추가하여 긴 경로 지원을 옵트인할 수 있습니다.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>
이름 값
Scope 부
버전 4.6.2
형식 대상 변경

경로 콜론 검사가 더욱 엄격해짐

설명

.NET Framework 4.6.2에서 이전에 지원되지 않던 경로(길이 및 형식 모두)를 지원하도록 여러 가지가 변경되었습니다. 적절한 드라이브 구분 기호(콜론) 구문에 대해 검사가 좀 더 정확해졌습니다. 이 구문은 이전에 허용되었던 일부 선택 경로 API에서 일부 URI 경로가 차단되는 부작용이 있었습니다.

제안 해결 방법

영향을 받는 API로 URI를 전달하는 경우 먼저 합법적인 경로가 되도록 문자열을 수정합니다.

  • URL에서 스키마를 수동으로 제거합니다(예: URL에서 file:// 제거).

  • URI를 Uri 클래스에 전달하고 LocalPath를 사용합니다.

또는 Switch.System.IO.UseLegacyPathHandling AppContext 스위치를 true로 설정하여 새 경로 정규화를 옵트아웃합니다.

이름 값
Scope Microsoft Edge
버전 4.6.2
형식 대상 변경

영향을 받는 API

보안

이제 RSACng가 비표준 키 크기의 RSA 키를 올바르게 로드함

설명

4\.6.2 이전의 .NET Framework 버전의 경우, RSA 인증서의 비표준 키 크기를 가진 고객은 System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) 및 System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2) 확장 메서드를 통해 해당 키에 액세스할 수 없습니다. “요청한 키 크기가 지원되지 않습니다”라는 메시지와 함께 System.Security.Cryptography.CryptographicException이 throw됩니다. .NET Framework 4.6.2에서 이 문제가 해결되었습니다. 마찬가지로, ImportParameters(RSAParameters) 및 ImportParameters(RSAParameters)은 System.Security.Cryptography.CryptographicException을 throw하지 않고 비표준 키 크기로 작업합니다.

제안 해결 방법

비표준 키 크기가 사용될 때 System.Security.Cryptography.CryptographicException이 throw되는 이전 동작에 의존하는 예외 처리 논리가 있는 경우 논리 제거를 고려하세요.

이름 값
Scope Microsoft Edge
버전 4.6.2
형식 대상 변경

영향을 받는 API

SignedXml.GetPublicKey는 대상 변경 없이 net462(또는 lightup)에서 RSACng를 반환

설명

.NET Framework 4.6.2부터는 SignedXml.GetPublicKey 메서드에서 반환된 개체의 구체적인 형식이 CryptoServiceProvider 구현에서 Cng 구현으로 변경되었습니다(쿼크 사용 안 함). 이는 구현이 certificate.PublicKey.Key 사용에서 RSACertificateExtensions.GetRSAPublicKey로 전달되는 내부 certificate.GetAnyPublicKey 사용으로 변경 되었기 때문입니다.

제안 해결 방법

.NET Framework 4.7.1에서 실행되는 앱부터는 앱 구성 파일의 런타임 섹션에 다음 구성 스위치를 추가하여 .NET Framework 4.6.1 이전 버전에서 기본적으로 사용되는 CryptoServiceProvider 구현을 사용할 수 있습니다.

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
이름 값
Scope Microsoft Edge
버전 4.6.2
형식 대상 변경

영향을 받는 API

WCF(Windows Communication Foundation)

재진입 서비스를 사용할 때 교착 상태가 발생할 수 있습니다.

설명

교착 상태가 발생하면 재진입 서비스의 인스턴스가 한번에 하나의 실행 스레드로 제한됩니다. 이 문제가 발생하기 쉬운 서비스는 코드에 다음과 같은 ServiceBehaviorAttribute가 있습니다.

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

제안 해결 방법

이 문제를 해결하려면 다음을 수행합니다.

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
  • .NET Framework 4.6.2의 최신 업데이트를 설치하거나 이후 버전의 .NET Framework로 업그레이드합니다. 이렇게 하면 OperationContext.Current에서 ExecutionContext의 흐름이 비활성화됩니다. 이 동작은 구성할 수 있습니다. 구성 파일에 다음 앱 설정을 추가하는 것과 같습니다.
<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

Switch.System.ServiceModel.DisableOperationContextAsyncFlow의 값은 재진입 서비스에 대해 false로 설정하면 안 됩니다.

이름 값
Scope 부
버전 4.6.2
형식 대상 변경

영향을 받는 API

OperationContext.Current는 using 절에서 호출될 때 null을 반환할 수 있습니다.

설명

다음 조건이 모두 참인 경우 OperationContext.Current이 null를 반환하고 NullReferenceException이 발생할 수 있습니다.

using (new OperationContextScope(OperationContext.Current))
{
    // OperationContext.Current is null.
    OperationContext context = OperationContext.Current;

    // ...
}

제안 해결 방법

이 문제를 해결하려면 다음을 수행합니다.

  • 다음과 같이 코드를 수정하여 새로운 null Current 이외의 개체를 인스턴스화합니다.

    OperationContext ocx = OperationContext.Current;
using (new OperationContextScope(OperationContext.Current))
{
    OperationContext.Current = new OperationContext(ocx.Channel);

    // ...
}

  • .NET Framework 4.6.2의 최신 업데이트를 설치하거나 이후 버전의 .NET Framework로 업그레이드합니다. 이렇게 하면 OperationContext.Current에서 ExecutionContext의 흐름이 비활성화되고 .NET Framework 4.6.1 및 이전 버전에서 WCF 애플리케이션의 동작이 복원됩니다. 이 동작은 구성할 수 있습니다. 구성 파일에 다음 앱 설정을 추가하는 것과 같습니다.

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

    이러한 변경은 바람직하지 않으며 애플리케이션이 작업 컨텍스트 간에 흐르는 실행 컨텍스트에 의존하는 경우 다음과 같이 해당 흐름을 활성화할수 있습니다.

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
</appSettings>
이름 값
Scope Microsoft Edge
버전 4.6.2
형식 대상 변경

영향을 받는 API

WCF 전송 보안이 CNG를 사용하여 저장한 인증서를 지원

설명

.NET Framework 4.6.2를 대상으로 하는 앱부터, WCF 전송 보안에서 Windows 암호화 라이브러리(CNG)를 사용하여 저장한 인증서를 지원합니다. 이 지원은 지수 길이가 32비트 이하인 공개 키로 인증서로 제한됩니다. 애플리케이션이 .NET Framework 4.6.2를 대상으로 하는 경우 이 기능은 기본적으로 켜집니다. 이전 버전의 .NET Framework에서 CSG 키 스토리지 공급자와 함께 X509 인증서를 사용하려고 하면 예외가 throw됩니다.

제안 해결 방법

.NET Framework 4.6.1 이전 버전을 대상으로 하지만 .NET Framework 4.6.2에서 실행 중인 앱은 app.config 또는 web.config 파일의 <runtime> 섹션에 다음 줄을 추가하여 CNG 인증서에 대한 지원을 사용하도록 설정할 수 있습니다.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IdentityModel.DisableCngCertificates=false" />
</runtime>

다음 코드를 사용하여 프로그래밍 방식으로 이 작업을 수행할 수도 있습니다.

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificate";

AppContext.SetSwitch(disableCngCertificates, false);

Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

이러한 변경으로 인해 CNG 인증서와의 보안 통신을 시작하려는 시도에 종속되는 예외 처리 코드를 더 이상 실행할 수 없습니다.

이름 값
Scope 부
버전 4.6.2
형식 대상 변경

Windows Forms

MemberDescriptor.Equals의 잘못된 구현

설명

MemberDescriptor.Equals 메서드의 원래 구현은 비교되는 개체의 두 가지 문자열 속성을 비교합니다. 즉, 범주 이름과 설명 문자열입니다. 수정은 첫 번째 개체의 Category를 두 번째의 Category와 비교하고, 첫 번째의 Description을 두 번째의 Description과 비교하는 것입니다.

제안 해결 방법

애플리케이션이 MemberDescriptor.Equals에 종속되어 있고 설명자가 동일할 때 false를 반환하는 경우 및 .NET Framework 4.6.2 이상 버전을 대상으로 하는 경우에 몇 가지 옵션이 있습니다.

  • MemberDescriptor.Equals 메서드를 호출하는 것 외에도 Category 및 Description 필드를 수동으로 비교하도록 코드를 변경합니다.
  • app.config 파일에 다음 값을 추가하여 이러한 변경 내용을 옵트아웃합니다.
<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true" />
</runtime>

애플리케이션이 .NET Framework 4.6.1 이하를 대상으로 하고 .NET Framework 4.6.2 이상에서 실행되는 경우 이 변경 내용을 활성화하려면 app.config 파일에 다음 값을 추가하여 호환성 스위치를 false로 설정하면 됩니다.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>
이름 값
Scope Microsoft Edge
버전 4.6.2
형식 대상 변경

영향을 받는 API

WPF(Windows Presentation Foundation)

CurrentCulture는 WPF 발송자 작업 간에 유지되지 않습니다.

설명

.NET Framework 4.6부터, System.Windows.Threading.Dispatcher 내에서 수행된 System.Globalization.CultureInfo.CurrentCulture 또는 System.Globalization.CultureInfo.CurrentUICulture에 대한 변경 내용은 해당 디스패처 작업이 끝날 때 손실됩니다. 마찬가지로, 디스패처 작업 외부에서 수행된 System.Globalization.CultureInfo.CurrentCulture 또는 System.Globalization.CultureInfo.CurrentUICulture의 변경 내용은 해당 작업이 실행될 때 반영되지 않을 수 있습니다. 실제로 이는 System.Globalization.CultureInfo.CurrentCulture 및 System.Globalization.CultureInfo.CurrentUICulture 변경 내용이 WPF UI 콜백과 WPF 애플리케이션의 다른 코드 간에 흐르지 않을 수 있음을 의미합니다. 이는 .NET Framework 4.6을 대상으로 하는 앱부터 System.Threading.ExecutionContext이 System.Globalization.CultureInfo.CurrentCulture 및 System.Globalization.CultureInfo.CurrentUICulture을 실행 컨텍스트에 저장하도록 변경되었기 때문입니다. WPF 발송자 작업이 작업을 시작할 때 사용된 실행 컨텍스트를 저장하고 작업이 완료되면 이전의 컨텍스트를 복원합니다. 이제는 System.Globalization.CultureInfo.CurrentCulture 및 System.Globalization.CultureInfo.CurrentUICulture가 해당 컨텍스트의 일부이므로 발송자 작업 내의 해당 속성 변경 내용이 작업 외부에서 유지되지 않습니다.

제안 해결 방법

이 변경의 영향을 받는 앱은 원하는 System.Globalization.CultureInfo.CurrentCulture 또는 System.Globalization.CultureInfo.CurrentUICulture를 필드에 저장하고 올바른 System.Globalization.CultureInfo.CurrentCulture 및 System.Globalization.CultureInfo.CurrentUICulture가 설정되도록 모든 디스패처 작업 본문(UI 이벤트 콜백 처리기 포함)을 확인하여 문제를 해결할 수 있습니다. 또는 이 WPF 변경 내용에 기반을 둔 ExecutionContext 변경 내용이 .NET Framework 4.6 이상을 대상으로 하는 앱에만 영향을 주기 때문에 대상을 .NET Framework 4.5.2로 변경하면 이 문제를 방지할 수 있습니다. 또한 .NET Framework 4.6 이상을 대상으로 하는 앱은 다음 호환성 스위치를 설정하여 이 문제를 해결할 수도 있습니다.

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

이 문제는 .NET Framework 4.6.2의 WPF에서 해결되었습니다. 또한 KB 3139549를 통해 .NET Frameworks 4.6, 4.6.1에서 해결되었습니다. .NET Framework 4.6 이상을 대상으로 하는 애플리케이션은 디스패처 작업 전반에 걸쳐 WPF 애플리케이션(System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture)에서 올바른 동작을 자동으로 유지합니다.

이름 값
Scope 부
버전 4.6
형식 대상 변경