.NET Framework의 새로운 기능
메모
.NET Framework는 보안 및 안정성 버그 수정을 사용하여 Windows 업데이트와 독립적으로 서비스됩니다. 일반적으로 보안 업데이트는 분기별로 릴리스됩니다. .NET Framework는 Windows에 계속 포함되며 제거할 계획은 없습니다. .NET Framework 앱을 마이그레이션할 필요는 없지만 새 개발의 경우 .NET 8 이상
이 문서에서는 다음 버전의 .NET Framework에서 새로운 주요 기능과 향상된 기능을 요약합니다.
- .NET Framework 4.8.1
- .NET Framework 4.8
- .NET Framework 4.7.2
- .NET Framework 4.7.1
- .NET Framework 4.7
- .NET Framework 4.6.2
- .NET Framework 4.6.1
- .NET 2015 및 .NET Framework 4.6
- .NET Framework 4.5.2
- .NET Framework 4.5.1
- .NET Framework 4.5
이 문서에서는 각 새 기능에 대한 포괄적인 정보를 제공하지 않으며 변경될 수 있습니다. .NET Framework에 대한 일반적인 내용은 시작참조하세요. 지원되는 플랫폼은 시스템 요구 사항참조하세요. 다운로드 링크 및 설치 지침은 설치 가이드참조하세요.
메모
또한 .NET Framework 팀은 NuGet을 사용하여 대역 외 기능을 릴리스하여 플랫폼 지원을 확장하고 변경할 수 없는 컬렉션 및 SIMD 사용 벡터 유형과 같은 새로운 기능을 도입합니다. 자세한 내용은 추가 클래스 라이브러리 및 API과 .NET Framework 및 대역 외 릴리스를 참조하세요.
.NET Framework용 NuGet 패키지의
.NET Framework 4.8.1 소개
.NET Framework 4.8.1은 매우 안정적인 제품을 유지하면서 많은 새로운 수정 사항과 몇 가지 새로운 기능을 추가하여 이전 버전의 .NET Framework 4.x를 기반으로 합니다.
.NET Framework 4.8.1 다운로드 및 설치
다음 위치에서 .NET Framework 4.8.1을 다운로드할 수 있습니다.
.NET Framework 4.8은 Windows 11, Windows 10 버전 21H2, Windows 10 버전 21H1, Windows 10 버전 20H2 및 Windows Server 2022부터 해당 서버 플랫폼에 설치할 수 있습니다. 웹 설치 관리자 또는 오프라인 설치 관리자를 사용하여 .NET Framework 4.8.1을 설치할 수 있습니다. 대부분의 사용자에게 권장되는 방법은 웹 설치 관리자를 사용하는 것입니다.
.NET Framework 4.8.1 개발자 팩
.NET Framework 4.8.1의 새로운 기능
.NET Framework 4.8.1에는 다음 영역에 새로운 기능이 도입되었습니다.
애플리케이션에서 보조 기술 사용자에게 적절한 환경을 제공할 수 있는 향상된 접근성은 .NET Framework 4.8.1의 주요 초점입니다. .NET Framework 4.8.1의 접근성 향상에 대한 정보는 .NET Framework에서의 접근성의 새로운 기능을 참조하세요.
.NET Framework 4.8.1은 .NET Framework 제품군에 네이티브 Arm64 지원을 추가합니다. 따라서 .NET Framework 앱 및 라이브러리의 방대한 에코시스템에 투자하면 Arm64에서 기본적으로 워크로드를 실행하는 이점을 활용할 수 있습니다. 즉, Arm64에서 에뮬레이트된 x64 코드를 실행하는 것과 비교할 때 성능이 향상됩니다.
Microsoft는모든 사용자가 액세스할 수
이 릴리스에서는 Windows Forms와 WPF 모두 도구 설명의 처리를 개선하여 접근성을 향상했습니다. 두 경우 모두 툴팁은 이제 WCAG2.1 콘텐츠의 가이드라인에 따라 호버 또는 포커스 지침을 준수합니다. 도구 설명에 대한 요구 사항은 다음과 같습니다.
- 도구 설명은 마우스로 가리키거나 키보드 탐색을 통해 컨트롤에 표시되어야 합니다.
- 도구 설명은 해제할 수 있어야 합니다. 즉, Esc 같은 간단한 키보드 명령은 도구 설명을 해제해야 합니다.
- 툴팁은 마우스로 가리킬 수 있어야 합니다. 사용자는 도구 설명 위에 마우스 커서를 놓을 수 있어야 합니다. 이를 통해 돋보기 사용과 같은 시나리오에서 저시력 사용자를 위한 도구 설명을 읽을 수 있습니다.
- 도구 설명은 상시 표시되어야 합니다. 특정 시간이 경과한 후에는 도구 설명이 자동으로 사라지지 않아야 합니다. 대신, 툴팁은 사용자가 마우스를 다른 컨트롤로 이동하거나 키보드 명령을 사용하여 닫아야 합니다.
Windows Forms에서 이 지원은 Windows 11 이상 운영 체제에서만 사용할 수 있습니다. Windows Forms는 Windows API에 대한 얇은 관리 래퍼이며, 새 툴팁 동작은 Windows 11에서만 사용할 수 있게 되었습니다. WPF에는 액세스 가능한 도구 설명에 대한 운영 체제 버전 종속성이 없습니다.
WPF는 .NET Framework 4.8에서 WCAG2.1 호환 도구 설명에 대한 대부분의 요구 사항을 구현했습니다. 이 릴리스에서 WPF는
Windows Forms는 .NET Framework용으로 만든 최초의 Windows UI 스택입니다. 따라서 원래는 현재 접근성 요구 사항을 충족하지 않는 레거시 접근성 기술을 활용하기 위해 만들어졌습니다. 이 릴리스에서 Windows Forms는 여러 가지 문제를 해결했습니다. 접근성 관련 변경 사항의 전체 목록은 .NET Framework의 '접근성의 새로운 기능'()을 방문하세요.을 참고하시기 바랍니다.
.NET Framework 4.8.1의 Windows Forms 개선 사항의 주요 내용은 다음과 같습니다.
텍스트 패턴 지원– Windows Forms는 UIA 텍스트 패턴에 대한 지원을 추가했습니다. 이 패턴을 사용하면 보조 기술이 TextBox 또는 유사한 텍스트 기반 컨트롤의 내용을 한 글자씩 탐색할 수 있습니다. 컨트롤 내에서 텍스트를 선택하고 변경할 수 있으며 커서에 새 텍스트를 삽입할 수 있습니다. Windows Forms는 TextBox, DataGridView 셀, ComboBox 컨트롤 등에 대한 지원을 추가했습니다.
대비 문제 해결 - 여러 컨트롤에서 Windows Forms는 선택 사각형의 대비 비율을 더 어둡고 더 잘 표시하도록 변경했습니다.
다음과 같은 여러 DataGridView 문제를 해결했습니다.
- 스크롤 막대 이름이 일관성 있게 업데이트되었습니다.
- 이제 내레이터가 빈 DataGridView 셀에 집중할 수 있습니다.
- 개발자는 Custom DataGridView 셀에 대한 지역화된 컨트롤 형식 속성을 설정할 수 있습니다.
- DataGridViewLink 셀의 링크 색이 배경과 더 잘 대비되도록 업데이트되었습니다.
.NET Framework 4.8 소개
.NET Framework 4.8은 매우 안정적인 제품을 유지하면서 많은 새로운 수정 사항과 몇 가지 새로운 기능을 추가하여 이전 버전의 .NET Framework 4.x를 기반으로 합니다.
.NET Framework 4.8 다운로드 및 설치
다음 위치에서 .NET Framework 4.8을 다운로드할 수 있습니다.
.NET Framework 4.8은 Windows 10, Windows 8.1, Windows 7 SP1 및 Windows Server 2008 R2 SP1부터 해당 서버 플랫폼에 설치할 수 있습니다. 웹 설치 관리자 또는 오프라인 설치 관리자를 사용하여 .NET Framework 4.8을 설치할 수 있습니다. 대부분의 사용자에게 권장되는 방법은 웹 설치 관리자를 사용하는 것입니다.
.NET Framework 4.8 개발자 팩
.NET Framework 4.8의 새로운 기능
.NET Framework 4.8에서는 다음 영역에 새로운 기능이 도입되었습니다.
애플리케이션이 보조 기술 사용자에게 적절한 환경을 제공할 수 있도록 하는 향상된 접근성은 .NET Framework 4.8의 주요 초점입니다. .NET Framework 4.8에서의 접근성 향상에 대한 정보는 .NET Framework의 새로운 접근성 기능을 참조하세요.
기본 클래스
FIPS가 암호화에 미치는 영향을 줄였습니다. 이전 버전의 .NET Framework에서는 시스템 암호화 라이브러리가 "FIPS 모드"로 구성된 경우, SHA256Managed 같은 관리형 암호화 공급자 클래스가 CryptographicException 예외를 발생시킵니다. 시스템 암호화 라이브러리와 달리 암호화 공급자 클래스의 관리되는 버전이 FIPS(연방 정보 처리 표준) 140-2 인증을 받지 않았기 때문에 이러한 예외가 throw됩니다. FIPS 모드에서 개발 머신을 사용하는 개발자는 거의 없기 때문에 보통 프로덕션 시스템에서 예외가 발생합니다.
.NET Framework 4.8을 대상으로 하는 애플리케이션에서는 기본적으로 다음 관리형 암호화 클래스가 이 경우 예외 CryptographicException를 더 이상 발생시키지 않습니다.
- MD5Cng
- MD5CryptoServiceProvider
- RC2CryptoServiceProvider
- RijndaelManaged
- RIPEMD160Managed
- SHA256Managed
대신 이러한 클래스는 암호화 작업을 시스템 암호화 라이브러리로 리디렉션합니다. 이러한 변경으로 인해 개발자 환경과 프로덕션 환경 간의 혼동을 효과적으로 제거하고 네이티브 구성 요소와 관리되는 구성 요소가 동일한 암호화 정책에서 작동하게 됩니다. 이러한 예외에 의존하는 애플리케이션은 AppContext 스위치 Switch.System.Security.Cryptography.UseLegacyFipsThrow
true
설정하여 이전 동작을 복원할 수 있습니다. 자세한 내용은 FIPS 모드에서 CryptographyException을 발생시키지 않는 관리 암호화 클래스에 대해참조하세요.
업데이트된 버전의 ZLib 사용
.NET Framework 4.5부터 clrcompression.dll 어셈블리는 데이터 압축을 위한 네이티브 외부 라이브러리인 ZLib사용하여 deflate 알고리즘에 대한 구현을 제공합니다. .NET Framework 4.8 버전의 clrcompression.dll ZLib 버전 1.2.11을 사용하도록 업데이트되었습니다. 여기에는 몇 가지 주요 개선 사항 및 수정 사항이 포함됩니다.
WCF(Windows Communication Foundation)
ServiceHealthBehavior 소개
상태 엔드포인트는 오케스트레이션 도구에서 건강 상태를 기반으로 서비스를 관리하는 데 널리 사용됩니다. 상태 검사는 모니터링 도구를 사용하여 서비스의 가용성 및 성능에 대한 알림을 추적하고 제공하는 데 사용할 수도 있습니다.
ServiceHealthBehavior은 IServiceBehavior을 확장하는 WCF 서비스 동작입니다. ServiceDescription.Behaviors 컬렉션에 추가된 경우 서비스 동작은 다음을 수행합니다.
HTTP 응답 코드를 사용하여 서비스 상태를 반환합니다. 쿼리 문자열에서 HTTP/GET 상태 프로브 요청에 대한 HTTP 상태 코드를 지정할 수 있습니다.
서비스 상태에 대한 정보를 게시합니다. 서비스 상태, 스로틀 수 및 용량을 포함한 서비스별 세부 정보는
?health
쿼리 문자열과 함께 HTTP/GET 요청을 사용하여 표시할 수 있습니다. 잘못된 WCF 서비스 문제를 해결할 때는 이러한 정보에 쉽게 액세스할 수 있습니다.
상태 엔드포인트를 노출하고 WCF 서비스 상태 정보를 게시하는 두 가지 방법이 있습니다.
코드를 통해. 예를 들어:
ServiceHost host = new ServiceHost(typeof(Service1), new Uri("http://contoso:81/Service1")); ServiceHealthBehavior healthBehavior = host.Description.Behaviors.Find<ServiceHealthBehavior>(); healthBehavior ??= new ServiceHealthBehavior(); host.Description.Behaviors.Add(healthBehavior);
Dim host As New ServiceHost(GetType(Service1), New Uri("http://contoso:81/Service1")) Dim healthBehavior As ServiceHealthBehavior = host.Description.Behaviors.Find(Of ServiceHealthBehavior)() If healthBehavior Is Nothing Then healthBehavior = New ServiceHealthBehavior() End If host.Description.Behaviors.Add(healthBehavior)
구성 파일을 사용합니다. 예를 들어:
<behaviors> <serviceBehaviors> <behavior name="DefaultBehavior"> <serviceHealth httpsGetEnabled="true"/> </behavior> </serviceBehaviors> </behaviors>
OnServiceFailure
, OnDispatcherFailure
, OnListenerFailure
, OnThrottlePercentExceeded
), 등의 쿼리 매개 변수를 사용하여 서비스의 상태를 쿼리할 수 있으며 각 쿼리 매개 변수에 대해 HTTP 응답 코드를 지정할 수 있습니다. 쿼리 매개 변수에 대해 HTTP 응답 코드를 생략하면 기본적으로 503 HTTP 응답 코드가 사용됩니다. 예를 들어:
서비스 실패 시:
https://contoso:81/Service1?health&OnServiceFailure=450
ServiceHost.State
보다 크면 450 HTTP 응답 상태 코드가 반환됩니다.
쿼리 매개 변수 및 예제:
OnDispatcherFailure:
https://contoso:81/Service1?health&OnDispatcherFailure=455
채널 디스패처의 상태가 CommunicationState.Opened초과하면 455 HTTP 응답 상태 코드가 반환됩니다.
OnListenerFailure:
https://contoso:81/Service1?health&OnListenerFailure=465
채널 수신기의 상태가 CommunicationState.Opened보다 크면 465 HTTP 응답 상태 코드가 반환됩니다.
스로틀 퍼센트 초과 발생:
https://contoso:81/Service1?health&OnThrottlePercentExceeded= 70:350,95:500
응답 및 해당 HTTP 응답 코드 {200 – 599}을(를) 트리거하는 백분율 {1 – 100}을(를) 지정합니다. 이 예제에서는 다음을 수행합니다.
백분율이 95보다 크면 500 HTTP 응답 코드가 반환됩니다.
백분율이 70에서 95 사이이면 350이 반환됩니다.
그렇지 않으면 200이 반환됩니다.
서비스 상태는 https://contoso:81/Service1?health
같은 쿼리 문자열을 지정하거나 xml에서 https://contoso:81/Service1?health&Xml
같은 쿼리 문자열을 지정하여 HTML로 표시될 수 있습니다.
https://contoso:81/Service1?health&NoContent
같은 쿼리 문자열은 빈 HTML 페이지를 반환합니다.
WPF(Windows Presentation Foundation)
높은 DPI 향상된 기능
.NET Framework 4.8에서 WPF는 Per-Monitor V2 DPI 인식 및 Mixed-Mode DPI 크기 조정에 대한 지원을 추가합니다. Windows에서 높은 DPI 개발에 관한 추가 정보는 고해상도 DPI 데스크톱 애플리케이션 개발 및을(를) 참조하세요.
.NET Framework 4.8은 Mixed-Mode DPI 크기 조정을 지원하는 플랫폼의 High-DPI WPF 애플리케이션에서 호스트된 HWND 및 Windows Forms 상호 운용에 대한 지원을 개선합니다(Windows 10 2018년 4월 업데이트부터 시작). 호스트된 HWND나 Windows Forms 컨트롤이 SetThreadDpiHostingBehavior 및 SetThreadDpiAwarenessContext를 호출하여 Mixed-Mode DPI 크기 조정 창으로 생성될 경우, 이는 Per-Monitor V2 WPF 애플리케이션 내에서 호스트될 수 있으며, 크기와 비율이 적절하게 조정됩니다. 이러한 호스트된 콘텐츠는 네이티브 DPI에서 렌더링되지 않습니다. 대신 운영 체제는 호스트된 콘텐츠의 크기를 적절한 크기로 조정합니다. 또한 Per-Monitor v2 DPI 인식 모드를 지원하면 고해상도 DPI 애플리케이션의 네이티브 창 안에서 WPF 컨트롤(즉, 부모 컨트롤)을 호스트할 수 있습니다.
Mixed-Mode 높은 DPI 크기 조정을 지원하려면 애플리케이션 구성 파일에서 다음 AppContext 스위치를 설정하십시오.
<runtime>
<AppContextSwitchOverrides value = "Switch.System.Windows.DoNotScaleForDpiChanges=false; Switch.System.Windows.DoNotUsePresentationDpiCapabilityTier2OrGreater=false"/>
</runtime>
공용 언어 런타임
.NET Framework 4.8의 런타임에는 다음과 같은 변경 내용과 향상된 기능이 포함되어 있습니다.
JIT 컴파일러대한
NGEN 개선. 런타임은 NGEN 이미지에서 매핑된 데이터가 메모리 상주하지 않도록 NGEN(네이티브 이미지 생성기) 이미지에 대한 메모리 관리를 개선했습니다. 이렇게 하면 실행될 메모리를 수정하여 임의 코드를 실행하려는 공격에 사용할 수 있는 노출 영역이 줄어듭니다.
모든 어셈블리에 대한 맬웨어 방지 검사. 이전 버전의 .NET Framework에서 런타임은 Windows Defender 또는 타사 맬웨어 방지 소프트웨어를 사용하여 디스크에서 로드된 모든 어셈블리를 검색합니다. 그러나 Assembly.Load(Byte[]) 메서드와 같은 다른 원본에서 로드된 어셈블리는 검색되지 않으며 검색되지 않은 맬웨어를 포함할 수 있습니다. Windows 10에서 실행되는 .NET Framework 4.8부터 런타임은 AMSI(맬웨어 방지 검사 인터페이스)구현하는 맬웨어 방지 솔루션으로 검사를 트리거합니다.
.NET Framework 4.7.2의 새로운 기능
.NET Framework 4.7.2에는 다음 영역에 새로운 기능이 포함되어 있습니다.
.NET Framework 4.7.2의 지속적인 초점은 접근성이 향상되어 애플리케이션이 보조 기술 사용자에게 적절한 환경을 제공할 수 있게 해줍니다. .NET Framework 4.7.2의 접근성 향상에 대한 정보를 보려면, .NET Framework에서 접근성의 새로운 기능을 참조하십시오.
기본 클래스
.NET Framework 4.7.2는 많은 수의 암호화 기능 향상, ZIP 보관 파일에 대한 향상된 압축 해제 지원 및 추가 컬렉션 API를 제공합니다.
RSA.Create 및 DSA.Create의 새로운 오버로드
DSA.Create(DSAParameters) 및 RSA.Create(RSAParameters) 메서드를 사용하면 새 DSA 또는 RSA 키를 인스턴스화할 때 키 매개 변수를 제공할 수 있습니다. 다음과 같은 코드를 바꿀 수 있습니다.
// Before .NET Framework 4.7.2
using (RSA rsa = RSA.Create())
{
rsa.ImportParameters(rsaParameters);
// Other code to execute using the RSA instance.
}
' Before .NET Framework 4.7.2
Using rsa = RSA.Create()
rsa.ImportParameters(rsaParameters)
' Other code to execute using the rsa instance.
End Using
다음과 같은 코드를 사용합니다.
// Starting with .NET Framework 4.7.2
using (RSA rsa = RSA.Create(rsaParameters))
{
// Other code to execute using the rsa instance.
}
' Starting with .NET Framework 4.7.2
Using rsa = RSA.Create(rsaParameters)
' Other code to execute using the rsa instance.
End Using
DSA.Create(Int32) 및 RSA.Create(Int32) 메서드를 사용하면 특정 키 크기의 새 DSA 또는 RSA 키를 생성할 수 있습니다. 예를 들어:
using (DSA dsa = DSA.Create(2048))
{
// Other code to execute using the dsa instance.
}
Using dsa = DSA.Create(2048)
' Other code to execute using the dsa instance.
End Using
Rfc2898DeriveBytes 생성자는 해시 알고리즘 이름 수락합니다.
Rfc2898DeriveBytes 클래스에는 키를 파생할 때 사용할 HMAC 알고리즘을 식별하는 HashAlgorithmName 매개 변수가 있는 세 개의 새 생성자가 있습니다. 개발자는 SHA-1을 사용하는 대신 다음 예제와 같이 SHA-256과 같은 SHA-2 기반 HMAC를 사용해야 합니다.
private static byte[] DeriveKey(string password, out int iterations, out byte[] salt,
out HashAlgorithmName algorithm)
{
iterations = 100000;
algorithm = HashAlgorithmName.SHA256;
const int SaltSize = 32;
const int DerivedValueSize = 32;
using (Rfc2898DeriveBytes pbkdf2 = new Rfc2898DeriveBytes(password, SaltSize,
iterations, algorithm))
{
salt = pbkdf2.Salt;
return pbkdf2.GetBytes(DerivedValueSize);
}
}
Private Shared Function DeriveKey(password As String, ByRef iterations As Integer,
ByRef salt AS Byte(), ByRef algorithm As HashAlgorithmName) As Byte()
iterations = 100000
algorithm = HashAlgorithmName.SHA256
Const SaltSize As Integer = 32
Const DerivedValueSize As Integer = 32
Using pbkdf2 = New Rfc2898DeriveBytes(password, SaltSize, iterations, algorithm)
salt = pbkdf2.Salt
Return pbkdf2.GetBytes(DerivedValueSize)
End Using
End Function
임시 키에 대한 지원
PFX 가져오기는 필요에 따라 하드 드라이브를 우회하여 메모리에서 직접 프라이빗 키를 로드할 수 있습니다. 새 X509KeyStorageFlags.EphemeralKeySet 플래그가 X509Certificate2 생성자 또는 X509Certificate2.Import 메서드의 오버로드 중 하나에 지정되면 프라이빗 키가 임시 키로 로드됩니다. 이렇게 하면 디스크에 키가 표시되지 않습니다. 그렇지만:
키가 디스크에 유지되지 않으므로 이 플래그로 로드된 인증서는 X509Store에 추가할 수 있는 좋은 후보가 아닙니다.
이러한 방식으로 로드된 키는 거의 항상 Windows CNG를 통해 로드됩니다. 따라서 호출자는 cert.GetRSAPrivateKey()와 같은 확장 메서드를 호출하여 프라이빗 키에 액세스해야 합니다. X509Certificate2.PrivateKey 속성이 작동하지 않습니다.
레거시 X509Certificate2.PrivateKey 속성은 인증서에서 작동하지 않으므로 개발자는 임시 키로 전환하기 전에 엄격한 테스트를 수행해야 합니다.
프로그래밍 방식으로 PKCS#10 인증서 서명 요청 및 X.509 공개 키 인증서
.NET Framework 4.7.2부터 워크로드는 CSR(인증서 서명 요청)을 생성할 수 있으며, 이를 통해 인증서 요청 생성을 기존 도구에서 준비할 수 있습니다. 이는 테스트 시나리오에서 자주 유용합니다.
자세한 내용 및 코드 예제는 .NET 블로그"PKCS#10 인증 서명 요청 및 X.509 공개 키 인증서의 프로그래밍 방식 만들기"를 참조하세요.
새 SignerInfo 멤버
.NET Framework 4.7.2부터 SignerInfo 클래스는 서명에 대한 자세한 정보를 노출합니다. System.Security.Cryptography.Pkcs.SignerInfo.SignatureAlgorithm 속성의 값을 검색하여 서명자가 사용하는 서명 알고리즘을 확인할 수 있습니다. SignerInfo.GetSignature 호출하여 이 서명자에 대한 암호화 서명의 복사본을 가져올 수 있습니다.
CryptoStream이 삭제된 후 래핑된 스트림을 계속 열어 두기
.NET Framework 4.7.2부터 CryptoStream 클래스에는 Dispose 래핑된 스트림을 닫지 않도록 허용하는 추가 생성자가 있습니다. CryptoStream 인스턴스가 삭제된 후 래핑된 스트림을 열어 두려면 다음과 같이 새 CryptoStream 생성자를 호출합니다.
var cStream = new CryptoStream(stream, transform, mode, leaveOpen: true);
Dim cStream = New CryptoStream(stream, transform, mode, leaveOpen:=true)
DeflateStream 압축 해제 변경
.NET Framework 4.7.2부터 DeflateStream 클래스의 압축 해제 작업 구현이 기본적으로 네이티브 Windows API를 사용하도록 변경되었습니다. 일반적으로 이로 인해 성능이 크게 향상됩니다.
Windows API를 사용한 압축 해제 지원은 .NET Framework 4.7.2를 대상으로 하는 애플리케이션에 대해 기본적으로 사용하도록 설정됩니다. 이전 버전의 .NET Framework를 대상으로 하지만 .NET Framework 4.7.2에서 실행되는 애플리케이션은 애플리케이션 구성 파일에 다음 AppContext 스위치 추가하여 이 동작을 옵트인할 수 있습니다.
<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=false" />
추가 컬렉션 API
.NET Framework 4.7.2는 SortedSet<T> 및 HashSet<T> 형식에 많은 새 API를 추가합니다. 여기에는 다음이 포함되었습니다.
다른 컬렉션 형식에 사용되는 try 패턴을 이러한 두 형식으로 확장하는
TryGetValue
메서드입니다. 메서드는 다음과 같습니다.Enumerable.To*
확장 메서드, 컬렉션을 HashSet<T>로 변환하는:컬렉션의 용량을 설정할 수 있는 새 HashSet<T> 생성자로, HashSet<T> 크기를 미리 알면 성능이 향상됩니다.
ConcurrentDictionary<TKey,TValue> 클래스에는 사전에서 값을 검색하거나 찾을 수 없는 경우 추가하거나 사전에 값을 추가하거나 이미 있는 경우 업데이트하는 AddOrUpdate 및 GetOrAdd 메서드의 새 오버로드가 포함됩니다.
public TValue AddOrUpdate<TArg>(TKey key, Func<TKey, TArg, TValue> addValueFactory, Func<TKey, TValue, TArg, TValue> updateValueFactory, TArg factoryArgument)
public TValue GetOrAdd<TArg>(TKey key, Func<TKey, TArg, TValue> valueFactory, TArg factoryArgument)
Public AddOrUpdate(Of TArg)(key As TKey, addValueFactory As Func(Of TKey, TArg, TValue), updateValueFactory As Func(Of TKey, TValue, TArg, TValue), factoryArgument As TArg) As TValue
Public GetOrAdd(Of TArg)(key As TKey, valueFactory As Func(Of TKey, TArg, TValue), factoryArgument As TArg) As TValue
ASP.NET
Web Forms에서 종속성 주입 지원
DI(종속성 주입) 개체와 해당 종속성을 분리하므로 종속성이 변경되었다는 이유로 개체의 코드를 더 이상 변경할 필요가 없습니다. .NET Framework 4.7.2를 대상으로 하는 ASP.NET 애플리케이션을 개발할 때 다음을 수행할 수 있습니다.
처리기 및 모듈 ,페이지 인스턴스 및 ASP.NET 웹 애플리케이션 프로젝트의 사용자 컨트롤을setter 기반, 인터페이스 기반 및 생성자 기반 삽입을 사용합니다. ASP.NET 웹 사이트 프로젝트의
처리기 및 모듈 ,페이지 인스턴스 , 그리고 사용자 컨트롤에 setter 기반 및 인터페이스 기반 주입을 사용하십시오. 다른 종속성 주입 프레임워크를 연결합니다.
동일한 사이트 쿠키 대한
SameSite 브라우저에서 사이트 간 요청과 함께 쿠키를 보낼 수 없습니다. .NET Framework 4.7.2는 System.Web.SameSiteMode 열거형 멤버인 값을 가진 HttpCookie.SameSite 속성을 추가합니다. 값이 SameSiteMode.Strict 또는 SameSiteMode.Lax경우 ASP.NET set-cookie 헤더에 SameSite
특성을 추가합니다. SameSite 지원은 HttpCookie 개체뿐만 아니라 FormsAuthentication 및 System.Web.SessionState 쿠키에도 적용됩니다.
다음과 같이 HttpCookie 개체에 대해 SameSite를 설정할 수 있습니다.
var c = new HttpCookie("secureCookie", "same origin");
c.SameSite = SameSiteMode.Lax;
Dim c As New HttpCookie("secureCookie", "same origin")
c.SameSite = SameSiteMode.Lax
web.config 파일을 수정하여 애플리케이션 수준에서 SameSite 쿠키를 구성할 수도 있습니다.
<system.web>
<httpCookies sameSite="Strict" />
</system.web>
웹 구성 파일을 수정하여 FormsAuthentication 및 System.Web.SessionState 쿠키에 대해 SameSite를 추가할 수 있습니다.
<system.web>
<authentication mode="Forms">
<forms cookieSameSite="Lax">
<!-- ... -->
</forms>
</authentication>
<sessionState cookieSameSite="Lax"></sessionState>
</system.web>
네트워킹
HttpClientHandler 속성 구현
.NET Framework 4.7.1은 System.Net.Http.HttpClientHandler 클래스에 8개의 속성을 추가했습니다. 그러나 두 사람은 PlatformNotSupportedException을 던졌다. .NET Framework 4.7.2는 이제 이러한 속성에 대한 구현을 제공합니다. 속성은 다음과 같습니다.
SQLClient
Azure Active Directory 유니버설 인증 및 다단계 인증 대한
규정 준수 및 보안 요구가 증가함에 따라 많은 고객이 MFA(다단계 인증)를 사용해야 합니다. 또한 현재의 모범 사례에서는 연결 문자열에 사용자 암호를 직접 포함시키는 것을 권장하지 않습니다. 이러한 변경 내용을 지원하기 위해 .NET Framework 4.7.2는 MFA 및
이전 버전의 .NET Framework에서 SQL 연결은 SqlAuthenticationMethod.ActiveDirectoryPassword 및 SqlAuthenticationMethod.ActiveDirectoryIntegrated 옵션만 지원했습니다. 둘 다 MFA를 지원하지 않는 비대화형 ADAL 프로토콜일부입니다. 새 SqlAuthenticationMethod.ActiveDirectoryInteractive 옵션을 사용하면 SQL 연결은 MFA뿐만 아니라 기존 인증 방법(암호 및 통합 인증)을 지원하므로 사용자가 연결 문자열에 암호를 유지하지 않고도 대화형으로 사용자 암호를 입력할 수 있습니다.
자세한 내용과 예제는 .NET 블로그"SQL -- Azure AD 유니버설 및 다단계 인증 지원"을 참조하세요.
Always Encrypted 버전 2에 대한 지원
NET Framework 4.7.2는 enclave 기반 Always Encrypted에 대한 지원을 추가합니다. Always Encrypted의 원래 버전은 암호화 키가 클라이언트를 떠나지 않는 클라이언트 쪽 암호화 기술입니다. enclave 기반 "Always Encrypted"에서 클라이언트는 선택적으로 암호화 키를 보안 엔클레이브에 보낼 수 있습니다. 보안 엔클레이브는 SQL Server의 일부로 간주될 수 있는 안전한 계산 엔터티이지만, SQL Server 코드는 이를 변조할 수 없습니다. enclave 기반 Always Encrypted를 지원하기 위해 .NET Framework 4.7.2는 다음 형식과 멤버를 System.Data.SqlClient 네임스페이스에 추가합니다.
SqlConnectionStringBuilder.EnclaveAttestationUrl은 enclave 기반 Always Encrypted에 대한 URI를 지정합니다.
SqlColumnEncryptionEnclaveProvider- 모든 엔클레이브 공급자가 파생되는 하나의 추상 클래스입니다.
SqlEnclaveSession- 지정된 enclave 세션의 상태를 캡슐화합니다.
SqlEnclaveAttestationParameters- 특정 증명 프로토콜을 실행하는 데 필요한 정보를 가져오기 위해 SQL Server에서 사용하는 증명 매개 변수를 제공합니다.
그런 다음 애플리케이션 구성 파일은 enclave 공급자에 대한 기능을 제공하는 추상 System.Data.SqlClient.SqlColumnEncryptionEnclaveProvider 클래스의 구체적인 구현을 지정합니다. 예를 들어:
<configuration>
<configSections>
<section name="SqlColumnEncryptionEnclaveProviders" type="System.Data.SqlClient.SqlColumnEncryptionEnclaveProviderConfigurationSection,System.Data,Version=4.0.0.0,Culture=neutral,PublicKeyToken=b77a5c561934e089"/>
</configSections>
<SqlColumnEncryptionEnclaveProviders>
<providers>
<add name="Azure" type="Microsoft.SqlServer.Management.AlwaysEncrypted.AzureEnclaveProvider,MyApp"/>
<add name="HGS" type="Microsoft.SqlServer.Management.AlwaysEncrypted.HGSEnclaveProvider,MyApp" />
</providers>
</SqlColumnEncryptionEnclaveProviders >
</configuration>
enclave 기반 Always Encrypted의 기본 흐름은 다음과 같습니다.
사용자는 엔클레이브 기반의 Always Encrypted를 지원하는 SQL Server에 대한 Always Encrypted 연결을 만듭니다. 드라이버는 증명 서비스에 연결하여 올바른 보안 영역에 연결하고 있는지 확인합니다.
인클레이브가 인증되면 드라이버는 SQL Server에서 호스트된 보안 인클레이브와 보안 채널을 설정합니다.
드라이버는 SQL 연결 기간 동안 클라이언트가 승인한 암호화 키를 보안 구역과 공유합니다.
윈도우즈 프레젠테이션 파운데이션 (Windows Presentation Foundation)
소스를 기준으로 ResourceDictionaries 찾기
.NET Framework 4.7.2부터 진단 도우미는 지정된 원본 Uri에서부터 만들어진 ResourceDictionaries를 찾는 것이 가능합니다. (이 기능은 프로덕션 애플리케이션이 아닌 진단 도우미에서 사용하기 위한 것입니다.) Visual Studio의 "편집 및 계속" 기능과 같은 진단 도우미를 사용하면 사용자가 변경 내용을 실행 중인 애플리케이션에 적용하려는 의도로 ResourceDictionary를 편집할 수 있습니다. 이를 달성하기 위한 한 가지 단계는 현재 편집 중인 사전에서 실행 중인 애플리케이션이 만든 모든 ResourceDictionaries를 찾는 것입니다. 예를 들어 애플리케이션은 지정된 원본 URI에서 콘텐츠가 복사되는 ResourceDictionary를 선언할 수 있습니다.
<ResourceDictionary Source="MyRD.xaml" />
MyRD.xaml의 원래 태그를 편집하는 도구인 진단 보조 프로그램은 새로운 기능을 사용하여 사전을 찾을 수 있습니다. 이 기능은 ResourceDictionaryDiagnostics.GetResourceDictionariesForSource새 정적 메서드에 의해 구현됩니다. 진단 도우미는 다음 코드와 같이 원래 태그를 식별하는 절대 URI를 사용하여 새 메서드를 호출합니다.
IEnumerable<ResourceDictionary> dictionaries = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(new Uri("pack://application:,,,/MyApp;component/MyRD.xaml"));
Dim dictionaries As IEnumerable(Of ResourceDictionary) = ResourceDictionaryDiagnostics.GetResourceDictionariesForSource(New Uri("pack://application:,,,/MyApp;component/MyRD.xaml"))
이 메서드는 VisualDiagnostics 사용하도록 설정되고 ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO
환경 변수가 설정되지 않는 한 빈 열거 가능 항목을 반환합니다.
리소스 사전 (ResourceDictionary) 소유자 찾기
.NET Framework 4.7.2부터 진단 도우미는 지정된 ResourceDictionary소유자를 찾을 수 있습니다. (이 기능은 프로덕션 애플리케이션이 아닌 진단 도우미에서 사용하기 위한 것입니다.) ResourceDictionary변경될 때마다 WPF는 변경의 영향을 받을 수 있는 모든 DynamicResource 참조를 자동으로 찾습니다.
Visual Studio의 "편집 및 계속" 기능과 같은 진단 도우미는 StaticResource 참조를 처리하도록 이 기능을 확장할 수 있습니다. 이 프로세스의 첫 번째 단계는 사전의 소유자를 찾는 것입니다. 즉, Resources
속성이 사전을 참조하는 모든 개체(직접 또는 간접적으로 ResourceDictionary.MergedDictionaries 속성을 통해)를 찾습니다.
Resources
속성이 있는 각 기본 형식에 대해 하나씩 System.Windows.Diagnostics.ResourceDictionaryDiagnostics 클래스에 구현된 세 가지 새 정적 메서드는 다음 단계를 지원합니다.
이 메서드들은 VisualDiagnostics가 활성화되고 ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO
환경 변수가 설정된 경우를 제외하고는 빈 열거 가능 항목을 반환합니다.
StaticResource 참조 찾기
이제 진단 도우미는 StaticResource 참조가 확인될 때마다 알림을 받을 수 있습니다. (이 기능은 프로덕션 애플리케이션이 아닌 진단 도우미에서 사용하기 위한 것입니다.) Visual Studio의 "편집 및 계속" 기능과 같은 진단 도우미는 ResourceDictionary 값이 변경되면 리소스의 모든 사용을 업데이트할 수 있습니다. WPF는 DynamicResource 참조에 대해 이 작업을 자동으로 수행하지만 StaticResource 참조에는 의도적으로 수행하지 않습니다. .NET Framework 4.7.2부터 진단 도우미는 이러한 알림을 사용하여 정적 리소스의 사용을 찾을 수 있습니다.
알림은 새 ResourceDictionaryDiagnostics.StaticResourceResolved 이벤트에 의해 구현됩니다.
public static event EventHandler<StaticResourceResolvedEventArgs> StaticResourceResolved;
Public Shared Event StaticResourceResolved As EventHandler(Of StaticResourceResolvedEventArgs)
이 이벤트는 런타임이 StaticResource 참조를 해결할 때마다 발생합니다. StaticResourceResolvedEventArgs 인수는 해상도를 설명하고 StaticResource 참조를 호스트하는 개체 및 속성과 해결에 사용되는 ResourceDictionary 및 키를 나타냅니다.
public class StaticResourceResolvedEventArgs : EventArgs
{
public Object TargetObject { get; }
public Object TargetProperty { get; }
public ResourceDictionary ResourceDictionary { get; }
public object ResourceKey { get; }
}
Public Class StaticResourceResolvedEventArgs : Inherits EventArgs
Public ReadOnly Property TargetObject As Object
Public ReadOnly Property TargetProperty As Object
Public ReadOnly Property ResourceDictionary As ResourceDictionary
Public ReadOnly Property ResourceKey As Object
End Class
VisualDiagnostics 사용이 활성화되지 않거나 ENABLE_XAML_DIAGNOSTICS_SOURCE_INFO
환경 변수가 설정되지 않으면 이벤트가 발생하지 않고 해당 add
접근자가 무시됩니다.
ClickOnce
Windows Forms, WPF(Windows Presentation Foundation) 및 VSTO(Visual Studio Tools for Office)용 HDPI 인식 애플리케이션은 모두 ClickOnce를 사용하여 배포할 수 있습니다. 애플리케이션 매니페스트에 다음 항목이 있으면 .NET Framework 4.7.2에서 배포가 성공합니다.
<windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>
Windows Forms 애플리케이션의 경우 애플리케이션 매니페스트가 아닌 애플리케이션 구성 파일에서 DPI 인식을 설정하는 이전 해결 방법은 ClickOnce 배포가 성공하기 위해 더 이상 필요하지 않습니다.
.NET Framework 4.7.1의 새로운 기능
.NET Framework 4.7.1에는 다음 영역에 새로운 기능이 포함되어 있습니다.
또한 .NET Framework 4.7.1의 주요 초점은 애플리케이션이 보조 기술 사용자에게 적절한 환경을 제공할 수 있도록 하는 향상된 접근성입니다. .NET Framework 4.7.1의 접근성 향상에 대한 정보를 보려면 .NET Framework의 접근성의 새로운 기능을 참조하세요.
기본 클래스
.NET Standard 2.0 지원
.NET Standard 해당 버전의 표준을 지원하는 각 .NET 구현에서 사용할 수 있어야 하는 API 집합을 정의합니다. .NET Framework 4.7.1은 .NET Standard 2.0을 완벽하게 지원하며, .NET Standard 2.0에 정의된 것 중에서 .NET Framework 4.6.1, 4.6.2 및 4.7에 없는 약 200개의 API를 추가합니다 . (이러한 버전의 .NET Framework는 추가 .NET Standard 지원 파일도 대상 시스템에 배포된 경우에만 .NET Standard 2.0을 지원합니다.) 자세한 내용은 .NET Framework 4.7.1 런타임 및 컴파일러 기능 블로그 게시물의 "BCL - .NET Standard 2.0 지원"을 참조하세요.
구성 작성기에 대한 지원
구성 작성기를 사용하면 개발자가 런타임에 애플리케이션에 대한 구성 설정을 동적으로 삽입하고 빌드할 수 있습니다. 사용자 지정 구성 작성기를 사용하여 구성 섹션의 기존 데이터를 수정하거나 구성 섹션을 처음부터 완전히 빌드할 수 있습니다. 구성 작성기 없이 .config 파일은 정적이며 해당 설정은 애플리케이션이 시작되기 몇 시간 전에 정의됩니다.
사용자 지정 구성 작성기를 만들려면 추상 ConfigurationBuilder 클래스에서 작성기를 파생시키고, ConfigurationBuilder.ProcessConfigurationSection과 ConfigurationBuilder.ProcessRawXml를 재정의하십시오. 당신은 또한 .config 파일에서 빌더도 정의합니다. 자세한 내용은 .NET Framework 4.7.1 ASP.NET 및 구성 기능 블로그 게시물의 "구성 작성기" 섹션을 참조하세요.
런타임 기능 감지
System.Runtime.CompilerServices.RuntimeFeature 클래스는 컴파일 시간 또는 런타임에 지정된 .NET 구현에서 미리 정의된 기능이 지원되는지 여부를 결정하는 메커니즘을 제공합니다. 컴파일 시 컴파일러는 지정된 필드가 있는지 여부를 확인하여 기능이 지원되는지 여부를 확인할 수 있습니다. 그렇다면 해당 기능을 활용하는 코드를 내보낼 수 있습니다. 런타임에 애플리케이션은 런타임에 코드를 내보내기 전에 RuntimeFeature.IsSupported 메서드를 호출할 수 있습니다. 자세한 내용은 런타임에서 지원하는 기능을 설명하는 도우미 메서드 추가에 대해 설명한 을 참조하십시오.
값 튜플 형식은 직렬화할 수 있습니다
.NET Framework 4.7.1부터 System.ValueTuple 및 연결된 제네릭 형식은 Serializable로 표시되어 이진 직렬화를 허용합니다. 이렇게 하면 Tuple<T1,T2,T3> 및 Tuple<T1,T2,T3,T4>같은 튜플 형식을 값 튜플 형식으로 더 쉽게 마이그레이션할 수 있습니다. 자세한 내용은 .NET Framework 4.7.1 런타임 및 컴파일러 기능 블로그 게시물의
읽기 전용 참조에 대한 지원
.NET Framework 4.7.1은 System.Runtime.CompilerServices.IsReadOnlyAttribute추가합니다. 이 특성은 언어 컴파일러에서 읽기 전용 ref 반환 형식 또는 매개 변수가 있는 멤버를 표시하는 데 사용됩니다. 자세한 내용은 .NET Framework 4.7.1 런타임 및 컴파일러 기능 블로그 게시물의 "컴파일러 -- ReadOnlyReferences 지원"을 참조하세요. ref 반환 값에 대한 자세한 내용은 Ref 반환 값, ref 지역 변수, 그리고 Ref 반환 값 (Visual Basic)를 참조하세요.
CLR(공용 언어 런타임)
가비지 수집 성능 향상
.NET Framework 4.7.1에서 GC(가비지 수집)를 변경하면 특히 LOH(대규모 개체 힙) 할당의 경우 전반적인 성능이 향상됩니다. .NET Framework 4.7.1에서는 SOH(작은 개체 힙) 및 LOH 할당에 별도의 잠금이 사용되므로 백그라운드 GC가 SOH를 스윕할 때 LOH 할당이 발생할 수 있습니다. 결과적으로 많은 수의 LOH 할당을 수행하는 애플리케이션은 할당 잠금 경합이 줄어들고 성능이 개선될 것으로 예상됩니다. 자세한 내용은 .NET Framework 4.7.1 런타임 및 컴파일러 기능 블로그 게시물의 "런타임 -- GC 성능 향상" 섹션을 참조하세요.
네트워킹
SHA-2 지원이 Message.HashAlgorithm에 대해 제공됩니다
.NET Framework 4.7 및 이전 버전에서 Message.HashAlgorithm 속성은 HashAlgorithm.Md5 및 HashAlgorithm.Sha 값을 지원합니다. .NET Framework 4.7.1부터 HashAlgorithm.Sha256, HashAlgorithm.Sha384및 HashAlgorithm.Sha512 지원됩니다. 이 값이 실제로 사용되는지 여부는 MSMQ에 따라 달라집니다. Message 인스턴스 자체는 해시를 수행하지 않고 단순히 값을 MSMQ에 전달하기 때문에 MSMQ에 따라 달라집니다. 자세한 내용은 .NET Framework 4.7.1 ASP.NET 및 구성 기능 블로그 게시물의 "Message.HashAlgorithm에 대한 SHA-2 지원" 섹션을 참조하세요.
ASP.NET
ASP.NET 애플리케이션의 실행 단계
ASP.NET 23개의 이벤트를 포함하는 미리 정의된 파이프라인에서 요청을 처리합니다. ASP.NET은 각 이벤트 처리기를 실행 단계로 처리합니다. .NET Framework 4.7까지의 ASP.NET 버전에서는 네이티브 스레드와 관리되는 스레드 간 전환으로 인해 ASP.NET이 실행 컨텍스트를 전달할 수 없습니다. 대신, ASP.NET은 선택적으로 HttpContext만 전달합니다. .NET Framework 4.7.1부터 HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) 메서드를 사용하면 모듈이 주변 데이터를 복원할 수도 있습니다. 이 기능은 추적, 프로파일링, 진단 또는 트랜잭션과 관련된 라이브러리(예: 애플리케이션의 실행 흐름에 관심이 있는 라이브러리)를 대상으로 합니다. 자세한 내용은 .NET Framework 4.7.1 ASP.NET 및 구성 기능 블로그 게시물의 "ASP.NET 실행 단계 기능"을 참조하세요.
ASP.NET HttpCookie 구문 분석
.NET Framework 4.7.1에는 문자열에서 HttpCookie 개체를 만들고 만료 날짜 및 경로와 같은 쿠키 값을 정확하게 할당하는 표준화된 방법을 제공하는 HttpCookie.TryParse새 메서드가 포함되어 있습니다. 자세한 내용은 "ASP.NET HttpCookie 구문 분석"을 .NET Framework 4.7.1 ASP.NET 및 구성 기능 블로그 게시물에서 참조하세요.
ASP.NET 양식 인증 자격 증명에 대한 SHA-2 해시 옵션
.NET Framework 4.7 및 이전 버전에서는 ASP.NET 개발자가 MD5 또는 SHA1을 사용하여 구성 파일에 해시된 암호를 사용하여 사용자 자격 증명을 저장할 수 있도록 허용했습니다. .NET Framework 4.7.1부터 ASP.NET SHA256, SHA384 및 SHA512와 같은 새로운 보안 SHA-2 해시 옵션도 지원합니다. SHA1은 기본값으로 유지되며 기본이 아닌 해시 알고리즘은 웹 구성 파일에서 정의할 수 있습니다.
중요하다
사용 가능한 가장 안전한 인증 흐름을 사용하는 것이 좋습니다. Azure SQL에 연결하는 경우 권장되는 인증 방법은 Azure 리소스에 대한 관리 되는 ID입니다.
.NET Framework 4.7의 새로운 기능
.NET Framework 4.7에는 다음 영역에 새로운 기능이 포함되어 있습니다.
- 기본 클래스
- 네트워킹
- ASP.NET
- WCF(Windows Communication Foundation)
- Windows Forms
- Windows Presentation Foundation (WPF)
.NET Framework 4.7에 추가된 새 API 목록은 GitHub에서 .NET Framework 4.7 API 변경 참조하세요. .NET Framework 4.7의 기능 향상 및 버그 수정 목록은 GitHub에서 .NET Framework 4.7 변경 목록을 참조하세요. 자세한 내용은 .NET 블로그에서 .NET Framework 4.7 발표를 참조하세요.
기본 클래스
.NET Framework 4.7은 DataContractJsonSerializer에 의해 serialization 기능이 향상됩니다.
타원 곡선 암호화(ECC)를 이용한 기능 향상 *
.NET Framework 4.7에서는 개체가 이미 설정된 키를 나타낼 수 있도록 ECDsa 및 ECDiffieHellman 클래스에 ImportParameters(ECParameters)
메서드가 추가되었습니다. 명시적 곡선 매개 변수를 사용하여 키를 내보내기 위한 ExportParameters(Boolean)
메서드도 추가되었습니다.
.NET Framework 4.7은 또한 추가 곡선(Brainpool 곡선 제품군 포함)에 대한 지원을 추가하고 새로운 Create 및 Create 팩터리 메서드를 통해 쉽게 만들기 위한 미리 정의된 정의를 추가했습니다.
GitHub에서 .NET Framework 4.7 암호화 개선의 예제를 볼 수 있습니다.
DataContractJsonSerializer 컨트롤 문자에 대한 더 나은 지원
.NET Framework 4.7에서 DataContractJsonSerializer 클래스는 ECMAScript 6 표준에 따라 컨트롤 문자를 직렬화합니다. 이 동작은 .NET Framework 4.7을 대상으로 하는 애플리케이션에 대해 기본적으로 사용하도록 설정되며.NET Framework 4.7에서 실행되지만 이전 버전의 .NET Framework를 대상으로 하는 애플리케이션에 대한 옵트인 기능입니다. 자세한 내용은 애플리케이션 호환성 섹션을 참조하세요.
네트워킹
.NET Framework 4.7은 다음과 같은 네트워크 관련 기능을 추가합니다.
TLS 프로토콜* 대한 기본 운영 체제 지원
HTTP, FTP 및 SMTP와 같은 System.Net.Security.SslStream 및 업 스택 구성 요소에서 사용되는 TLS 스택을 통해 개발자는 운영 체제에서 지원하는 기본 TLS 프로토콜을 사용할 수 있습니다. 개발자는 더 이상 TLS 버전을 하드 코딩할 필요가 없습니다.
ASP.NET
.NET Framework 4.7에서 ASP.NET 다음과 같은 새로운 기능을 포함합니다.
오브젝트 캐시 확장성
.NET Framework 4.7부터 ASP.NET 개발자가 메모리 내 개체 캐싱 및 메모리 모니터링에 대한 기본 ASP.NET 구현을 대체할 수 있는 새로운 API 집합을 추가합니다. 이제 개발자는 ASP.NET 구현이 적절하지 않은 경우 다음 세 가지 구성 요소 중 어느 것을 대체할 수 있습니다.
개체 캐시 저장소. 개발자는 새 캐시 공급자 구성 섹션을 사용하여 새 ICacheStoreProvider 인터페이스를 사용하여 ASP.NET 애플리케이션에 대한 개체 캐시의 새 구현을 연결할 수 있습니다.
메모리 모니터링. ASP.NET 기본 메모리 모니터는 프로세스에 대해 구성된 프라이빗 바이트 제한에 가깝게 실행 중이거나 컴퓨터가 사용 가능한 총 실제 RAM이 부족한 경우 애플리케이션에 알깁니다. 이러한 제한에 가까워지면 알림이 전송됩니다. 어떤 애플리케이션의 경우, 알림이 구성된 한계에 너무 가깝게 발생하여 유용하게 대처하는 것이 어렵습니다. 이제 개발자는 ApplicationMonitors.MemoryMonitor 속성을 사용하여 기본값을 대체할 고유한 메모리 모니터를 작성할 수 있습니다.
메모리 제한 반응. 기본적으로 ASP.NET 개체 캐시를 트리밍하고 프라이빗 바이트 프로세스 제한이 가까워지면 주기적으로 GC.Collect 호출하려고 시도합니다. 일부 애플리케이션의 경우 GC.Collect 호출 빈도 또는 트리밍된 캐시 양은 비효율적입니다. 이제 개발자는 애플리케이션의 메모리 모니터에 IObserver 구현을 구독하여 기본 동작을 바꾸거나 보완할 수 있습니다.
WCF(Windows Communication Foundation)
WCF(Windows Communication Foundation)는 다음과 같은 기능과 변경 내용을 추가합니다.
TLS 1.1 또는 TLS 1.2 기본 메시지 보안 설정을 구성하는 기능
.NET Framework 4.7부터 WCF를 사용하면 SSL 3.0 및 TLS 1.0 외에도 TLS 1.1 또는 TLS 1.2를 기본 메시지 보안 프로토콜로 구성할 수 있습니다. 이는 옵트인 설정입니다. 사용하도록 설정하려면 애플리케이션 구성 파일에 다음 항목을 추가해야 합니다.
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>
WCF 애플리케이션 및 WCF 직렬화 안정성 향상
WCF에는 경합 조건을 제거하는 여러 코드 변경 내용이 포함되어 있으므로 성능과 직렬화 옵션의 안정성이 향상됩니다. 여기에는 다음이 포함되었습니다.
- SocketConnection.BeginRead 및
SocketConnection.Read 호출에서 비동기 및 동기 코드를 혼합하기 위한 더 나은 지원. - SharedConnectionListener 및 DuplexChannelBinder에서 연결을 중단할 때 신뢰성이 향상되었습니다.
- FormatterServices.GetSerializableMembers(Type) 메서드를 호출할 때 serialization 작업의 안정성이 향상되었습니다.
- ChannelSynchronizer.RemoveWaiter 메서드를 호출하여 웨이터를 제거할 때 안정성이 향상되었습니다.
Windows Forms
.NET Framework 4.7에서 Windows Forms는 높은 DPI 모니터에 대한 지원을 개선합니다.
높은 DPI 지원
.NET Framework 4.7을 대상으로 하는 애플리케이션부터 .NET Framework는 Windows Forms 애플리케이션에 대한 높은 DPI 및 동적 DPI 지원을 제공합니다. 고해상도 모니터에서 양식 및 컨트롤의 레이아웃과 모양을 개선하는 데 고해상도(DPI) 지원이 도움이 됩니다. 동적 DPI는 사용자가 DPI를 변경하거나 실행 중인 애플리케이션의 배율 인수를 표시할 때 폼 및 컨트롤의 레이아웃과 모양을 변경합니다.
높은 DPI 지원은 애플리케이션 구성 파일에서 <System.Windows.Forms.ConfigurationSection> 섹션을 정의하여 구성하는 옵트인 기능입니다. Windows Forms 애플리케이션에 높은 DPI 지원과 동적 DPI 지원을 추가하는 방법에 대한 자세한 내용은 Windows Forms의 높은 DPI 지원을 참조하세요.
WPF(Windows Presentation Foundation)
.NET Framework 4.7에서 WPF에는 다음과 같은 향상된 기능이 포함되어 있습니다.
Windows WM_POINTER 메시지를 기반으로 한 터치/스타일러스 스택 지원
이제 Windows Ink 서비스 플랫폼(WISP) 대신 WM_POINTER 메시지에 기반한 터치/스타일러스 스택을 사용할 수 있습니다. .NET Framework의 옵트인 기능입니다. 자세한 내용은 애플리케이션 호환성 섹션을 참조하세요.
WPF 인쇄 API에 대한 새 구현
System.Printing.PrintQueue 클래스의 WPF 인쇄 API는 사용되지 않는 XPS Print API대신 Windows 인쇄 문서 패키지 API 호출합니다. 이러한 변경이 애플리케이션 호환성에 미치는 영향은 애플리케이션 호환성 섹션을 참조하세요.
.NET Framework 4.6.2의 새로운 기능
.NET Framework 4.6.2에는 다음 영역에 새로운 기능이 포함되어 있습니다.
.NET Framework 4.6.2에 추가된 새 API 목록은 GitHub에서 .NET Framework 4.6.2 API 변경 참조하세요. .NET Framework 4.6.2의 기능 향상 및 버그 수정 목록은 GitHub에서 .NET Framework 4.6.2 변경 사항 목록을 참조하세요. 자세한 내용은 .NET 블로그에서 .NET Framework 4.6.2 발표를 참조하세요.
ASP.NET
.NET Framework 4.6.2에서 ASP.NET 다음과 같은 향상된 기능을 포함합니다.
데이터 주석 유효성 검사기에서 지역화된 오류 메시지에 대한 지원 향상
데이터 주석 유효성 검사기를 사용하면 클래스 속성에 하나 이상의 특성을 추가하여 유효성 검사를 수행할 수 있습니다. 유효성 검사에 실패할 경우 특성의 ValidationAttribute.ErrorMessage 요소는 오류 메시지의 텍스트를 정의합니다. .NET Framework 4.6.2부터 ASP.NET 오류 메시지를 쉽게 지역화할 수 있습니다. 다음과 같은 경우 오류 메시지가 지역화됩니다.
ValidationAttribute.ErrorMessage은 유효성 검사 속성으로 제공됩니다.
리소스 파일은 App_LocalResources 폴더에 저장됩니다.
지역화된 리소스 파일의 이름은
DataAnnotation.Localization.{
이름}.resx
형식입니다. 여기서 이름는 languageCode-
country/regionCode 또는 languageCode형식의 문화권 이름입니다.리소스의 키 이름은 ValidationAttribute.ErrorMessage 특성에 할당된 문자열이며 해당 값은 지역화된 오류 메시지입니다.
예를 들어 다음 데이터 주석 특성은 잘못된 등급에 대한 기본 문화권의 오류 메시지를 정의합니다.
public class RatingInfo
{
[Required(ErrorMessage = "The rating must be between 1 and 10.")]
[Display(Name = "Your Rating")]
public int Rating { get; set; }
}
Public Class RatingInfo
<Required(ErrorMessage = "The rating must be between 1 and 10.")>
<Display(Name = "Your Rating")>
Public Property Rating As Integer = 1
End Class
그런 다음, 리소스 파일인 DataAnnotation.Localization.fr.resx를 만들 수 있습니다. 이 파일의 키는 오류 메시지 문자열이고 값은 지역화된 오류 메시지입니다. 파일은 App.LocalResources
폴더에 있어야 합니다. 예를 들어 다음은 지역화된 프랑스어(fr) 언어 오류 메시지의 키와 해당 값입니다.
이름 | 가치 |
---|---|
등급은 1에서 10 사이여야 합니다. | 점수는 1에서 10 사이여야 합니다. |
또한 데이터 주석 지역화는 확장할 수 있습니다. 개발자는 리소스 파일 이외의 위치에 지역화 문자열을 저장하기 위해 IStringLocalizerProvider 인터페이스를 구현하여 자체 문자열 지역화 공급자를 연결할 수 있습니다.
비동기 지원 세션 상태 저장소 공급자
이제 ASP.NET 작업 반환 메서드를 세션 상태 저장소 공급자와 함께 사용할 수 있으므로 ASP.NET 앱이 비동기의 확장성 이점을 얻을 수 있습니다. ASP.NET는 세션 상태 저장소 공급자를 사용하여 비동기 작업을 지원하기 위해 IHttpModule을 상속하는 새 인터페이스 System.Web.SessionState.ISessionStateModule를 포함하며, 이 인터페이스를 통해 개발자가 자체 세션 상태 모듈 및 비동기 세션 저장소 공급자를 구현할 수 있습니다. 인터페이스는 다음과 같이 정의됩니다.
public interface ISessionStateModule : IHttpModule {
void ReleaseSessionState(HttpContext context);
Task ReleaseSessionStateAsync(HttpContext context);
}
Public Interface ISessionStateModule : Inherits IHttpModule
Sub ReleaseSessionState(context As HttpContext)
Function ReleaseSessionStateAsync(context As HttpContext) As Task
End Interface
또한 SessionStateUtility 클래스에는 비동기 작업을 지원하는 데 사용할 수 있는 IsSessionStateReadOnly 및 IsSessionStateRequired두 가지 새로운 메서드가 포함되어 있습니다.
출력 캐시 공급자에 대한 비동기 지원
.NET Framework 4.6.2부터 작업 반환 메서드를 출력 캐시 공급자와 함께 사용하여 비동기의 확장성 이점을 제공할 수 있습니다. 이러한 방법을 구현하는 공급자는 웹 서버에서 스레드 차단을 줄이고 ASP.NET 서비스의 확장성을 향상시킵니다.
비동기 출력 캐시 공급자를 지원하기 위해 다음 API가 추가되었습니다.
System.Web.Caching.OutputCacheProviderAsync 클래스는 System.Web.Caching.OutputCacheProvider을 상속하며, 개발자가 비동기 출력 캐시 공급자를 구현할 수 있도록 합니다.
출력 캐시를 구성하기 위한 도우미 메서드를 제공하는 OutputCacheUtility 클래스입니다.
System.Web.HttpCachePolicy 클래스의 새 메서드 18개. 여기에는 GetCacheability, GetCacheExtensions, GetETag, GetETagFromFileDependencies, GetMaxAge, GetMaxAge, GetNoStore, GetNoTransforms, GetOmitVaryStar, GetProxyMaxAge, GetRevalidation, GetUtcLastModified, GetVaryByCustom, HasSlidingExpiration및 IsValidUntilExpires포함합니다.
System.Web.HttpCacheVaryByContentEncodings 클래스의 새 메서드 2개: GetContentEncodings 및 SetContentEncodings.
System.Web.HttpCacheVaryByHeaders 클래스의 새 메서드 2개: GetHeaders 및 SetHeaders.
System.Web.HttpCacheVaryByParams 클래스의 새 메서드 2개: GetParams 및 SetParams.
System.Web.Caching.AggregateCacheDependency 클래스에 있는 GetFileDependencies 메서드.
CacheDependency에서 GetFileDependencies 메서드입니다.
문자 범주
.NET Framework 4.6.2의 문자는 유니코드 표준 버전 8.0.0따라 분류됩니다. .NET Framework 4.6 및 .NET Framework 4.6.1에서 문자는 유니코드 6.3 문자 범주에 따라 분류되었습니다.
유니코드 8.0에 대한 지원은 CharUnicodeInfo 클래스의 문자 분류와 이를 사용하는 형식 및 메서드로 제한됩니다. 여기에는 StringInfo 클래스, Char.GetUnicodeCategory 오버로드된 메서드, .NET Framework 정규식 엔진에서 인식하는 문자 클래스가 포함됩니다. 문자 및 문자열 비교 및 정렬은 이 변경의 영향을 받지 않으며 기본 운영 체제 또는 Windows 7 시스템에서 .NET Framework에서 제공하는 문자 데이터에 계속 의존합니다.
유니코드 6.0에서 유니코드 7.0으로의 문자 범주 변경 내용은 유니코드 컨소시엄 웹 사이트에서 유니코드 표준 버전 7.0.0 참조하세요. 유니코드 7.0에서 유니코드 8.0으로 변경되는 내용은 유니코드 컨소시엄 웹 사이트에서 유니코드 표준 버전 8.0.0 참조하세요.
암호화
FIPS 186-3 DSA 포함하는 X509 인증서에 대한
.NET Framework 4.6.2는 키가 FIPS 186-2 1024비트 제한을 초과하는 DSA(디지털 서명 알고리즘) X509 인증서에 대한 지원을 추가합니다.
.NET Framework 4.6.2는 FIPS 186-3의 더 큰 키 크기를 지원하는 것 외에도 SHA-2 해시 알고리즘 제품군(SHA256, SHA384 및 SHA512)을 사용하여 서명을 계산할 수 있습니다. FIPS 186-3 지원은 새 System.Security.Cryptography.DSACng 클래스에서 제공됩니다.
.NET Framework 4.6의 RSA 클래스 및 .NET Framework 4.6.1의 ECDsa 클래스에 대한 최근 변경 내용에 따라 .NET Framework 4.6.2의 DSA 추상 기본 클래스에는 호출자가 캐스팅하지 않고 이 기능을 사용할 수 있도록 하는 추가 메서드가 있습니다. 다음 예제와 같이 DSACertificateExtensions.GetDSAPrivateKey 확장 메서드를 호출하여 데이터에 서명할 수 있습니다.
public static byte[] SignDataDsaSha384(byte[] data, X509Certificate2 cert)
{
using (DSA dsa = cert.GetDSAPrivateKey())
{
return dsa.SignData(data, HashAlgorithmName.SHA384);
}
}
Public Shared Function SignDataDsaSha384(data As Byte(), cert As X509Certificate2) As Byte()
Using DSA As DSA = cert.GetDSAPrivateKey()
Return DSA.SignData(data, HashAlgorithmName.SHA384)
End Using
End Function
다음 예제와 같이 DSACertificateExtensions.GetDSAPublicKey 확장 메서드를 호출하여 서명된 데이터를 확인할 수 있습니다.
public static bool VerifyDataDsaSha384(byte[] data, byte[] signature, X509Certificate2 cert)
{
using (DSA dsa = cert.GetDSAPublicKey())
{
return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384);
}
}
Public Shared Function VerifyDataDsaSha384(data As Byte(), signature As Byte(), cert As X509Certificate2) As Boolean
Using dsa As DSA = cert.GetDSAPublicKey()
Return dsa.VerifyData(data, signature, HashAlgorithmName.SHA384)
End Using
End Function
ECDiffieHellman 키 파생 루틴에 대한 입력에 대한 명확성 향상
.NET Framework 3.5는 세 가지 다른 KDF(키 파생 함수) 루틴을 사용하여 타원 곡선 Diffie-Hellman 키 계약에 대한 지원을 추가했습니다. 루틴 및 루틴 자체에 대한 입력은 ECDiffieHellmanCng 개체의 속성을 통해 구성되었습니다. 그러나 모든 루틴이 모든 입력 속성을 읽는 것은 아니므로 개발자의 과거에 대한 혼란의 여지가 충분했습니다.
.NET Framework 4.6.2에서 이 문제를 해결하기 위해 다음 세 가지 메서드가 ECDiffieHellman 기본 클래스에 추가되어 이러한 KDF 루틴과 해당 입력을 보다 명확하게 나타냅니다.
ECDiffieHellman 메서드 | 설명 |
---|---|
DeriveKeyFromHash(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[]) | 수식을 사용하여 키 소재를 파생시킵니다. HASH(secretPrepend || x || secretAppend) HASH(secretPrepend OrElse x OrElse secretAppend) 여기서 x EC Diffie-Hellman 알고리즘의 계산 결과입니다. |
DeriveKeyFromHmac(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[], Byte[]) | 수식을 사용하여 키 자료를 도출합니다. HMAC(hmacKey, secretPrepend || x || secretAppend) HMAC(hmacKey, secretPrepend OrElse x OrElse secretAppend) 여기서 x EC Diffie-Hellman 알고리즘의 계산 결과입니다. |
DeriveKeyTls(ECDiffieHellmanPublicKey, Byte[], Byte[]) | TLS의 의사 임의 함수(PRF) 파생 알고리즘을 사용하여 키 자료를 파생합니다. |
지속형 키 대칭 암호화 지원
Windows CNG(암호화 라이브러리)는 지속형 대칭 키를 저장하고 하드웨어에 저장된 대칭 키를 사용하기 위한 지원을 추가했으며, .NET Framework 4.6.2를 사용하면 개발자가 이 기능을 사용할 수 있습니다. 키 이름 및 키 공급자의 개념은 구현에 따라 다릅니다. 이 기능을 사용하려면 기본 팩터리 접근 방식(예: Aes.Create
호출) 대신 구체적인 구현 형식의 생성자를 활용해야 합니다.
AES(AesCng) 및 3DES(TripleDESCng) 알고리즘에 대한 지속형 키 대칭 암호화 지원이 있습니다. 예를 들어:
public static byte[] EncryptDataWithPersistedKey(byte[] data, byte[] iv)
{
using (Aes aes = new AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider))
{
aes.IV = iv;
// Using the zero-argument overload is required to make use of the persisted key
using (ICryptoTransform encryptor = aes.CreateEncryptor())
{
if (!encryptor.CanTransformMultipleBlocks)
{
throw new InvalidOperationException("This is a sample, this case wasn't handled...");
}
return encryptor.TransformFinalBlock(data, 0, data.Length);
}
}
}
Public Shared Function EncryptDataWithPersistedKey(data As Byte(), iv As Byte()) As Byte()
Using Aes As Aes = New AesCng("AesDemoKey", CngProvider.MicrosoftSoftwareKeyStorageProvider)
Aes.IV = iv
' Using the zero-argument overload Is required to make use of the persisted key
Using encryptor As ICryptoTransform = Aes.CreateEncryptor()
If Not encryptor.CanTransformMultipleBlocks Then
Throw New InvalidOperationException("This is a sample, this case wasn't handled...")
End If
Return encryptor.TransformFinalBlock(data, 0, data.Length)
End Using
End Using
End Function
SHA-2 해시 대한
.NET Framework 4.6.2는 RSA-SHA256, RSA-SHA384 및 RSA-SHA512 PKCS#1 서명 메서드 및 SHA256, SHA384 및 SHA512 참조 다이제스트 알고리즘에 대한 SignedXml 클래스에 대한 지원을 추가합니다.
URI 상수는 모두 SignedXml에 노출됩니다.
SignedXml 필드 | 상수 |
---|---|
XmlDsigSHA256Url | "http://www.w3.org/2001/04/xmlenc#sha256" |
XmlDsigRSASHA256Url | "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" |
XmlDsigSHA384Url | "http://www.w3.org/2001/04/xmldsig-more#sha384" |
XmlDsigRSASHA384Url | "http://www.w3.org/2001/04/xmldsig-more#rsa-sha384" |
XmlDsigSHA512Url | "http://www.w3.org/2001/04/xmlenc#sha512" |
XmlDsigRSASHA512Url | "http://www.w3.org/2001/04/xmldsig-more#rsa-sha512" |
이러한 알고리즘에 대한 지원을 추가하기 위해 사용자 지정 SignatureDescription 처리기를 CryptoConfig 등록한 프로그램은 이전과 마찬가지로 계속 작동하지만 이제 플랫폼 기본값이 있으므로 CryptoConfig 등록이 더 이상 필요하지 않습니다.
SqlClient
.NET Framework Data Provider for SQL Server(System.Data.SqlClient)에는 .NET Framework 4.6.2의 다음과 같은 새로운 기능이 포함되어 있습니다.
Azure SQL 데이터베이스를 사용하여 연결 풀링 및 시간 제한
연결 풀링이 활성화되고 시간 제한 또는 기타 로그인 오류가 발생하면 예외가 캐시되고, 5초에서 최대 1분 동안 후속 연결 시도 시 캐시된 예외가 발생합니다. 자세한 내용은 SQL Server 연결 풀링 (ADO.NET)을 참조하세요.
일반적으로 신속하게 복구되는 일시적인 오류로 연결 시도가 실패할 수 있으므로 Azure SQL Database에 연결할 때 이 동작은 바람직하지 않습니다. 연결 재시도 환경을 최적화하기 위해 Azure SQL Database에 대한 연결이 실패할 때 연결 풀 차단 기간 동작이 제거됩니다.
새 PoolBlockingPeriod
키워드를 추가하면 앱에 가장 적합한 차단 기간을 선택할 수 있습니다. 값은 다음과 같습니다.
Azure SQL Database에 연결하는 애플리케이션에 대한 연결 풀 차단 기간이 비활성화되고 다른 SQL Server 인스턴스에 연결하는 애플리케이션에 대한 연결 풀 차단 기간이 활성화됩니다. 기본값입니다. 서버 엔드포인트 이름이 다음 중 어느 것으로 끝나는 경우 Azure SQL Database로 간주됩니다.
.database.windows.net
.database.chinacloudapi.cn
.database.usgovcloudapi.net
.database.cloudapi.de
연결 풀 차단 기간은 항상 사용하도록 설정됩니다.
연결 풀 차단 기간은 항상 사용하지 않도록 설정됩니다.
상시 암호화를 위한
SQLClient는 Always Encrypted의 두 가지 향상된 기능을 소개합니다.
암호화된 데이터베이스 열에 대해 매개 변수가 있는 쿼리의 성능을 향상시키기 위해 이제 쿼리 매개 변수에 대한 암호화 메타데이터가 캐시됩니다. SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled 속성을
true
(기본값)로 설정하면 동일한 쿼리가 여러 번 호출되면 클라이언트는 서버에서 매개 변수 메타데이터를 한 번만 검색합니다.이제 키 캐시의 열 암호화 키 항목은 구성 가능한 시간 간격 후에 제거되고 SqlConnection.ColumnEncryptionKeyCacheTtl 속성을 사용하여 설정됩니다.
Windows Communication Foundation
.NET Framework 4.6.2에서 Windows Communication Foundation은 다음 영역에서 향상되었습니다.
CNG 사용하여 저장된 인증서에 대한 WCF 전송 보안 지원
WCF 전송 보안은 Windows CNG(암호화 라이브러리)를 사용하여 저장된 인증서를 지원합니다. .NET Framework 4.6.2에서 이 지원은 길이가 32비트 이하인 공개 키가 있는 인증서를 사용하는 것으로 제한됩니다. 애플리케이션이 .NET Framework 4.6.2를 대상으로 하는 경우 이 기능은 기본적으로 설정됩니다.
.NET Framework 4.6.1 이하를 대상으로 하지만 .NET Framework 4.6.2에서 실행되는 애플리케이션의 경우 app.config 또는 web.config 파일의 <런타임> 섹션에 다음 줄을 추가하여 이 기능을 사용하도록 설정할 수 있습니다.
<AppContextSwitchOverrides
value="Switch.System.IdentityModel.DisableCngCertificates=false"
/>
다음과 같은 코드를 사용하여 프로그래밍 방식으로 이 작업을 수행할 수도 있습니다.
private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificates";
AppContext.SetSwitch(disableCngCertificates, false);
Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)
DataContractJsonSerializer 클래스에 의해 여러 일광 절약 시간 조정 규칙이 더 잘 지원됩니다
고객은 애플리케이션 구성 설정을 사용하여 DataContractJsonSerializer 클래스가 단일 표준 시간대에 대해 여러 조정 규칙을 지원하는지 여부를 확인할 수 있습니다. 이는 옵트인 기능입니다. 사용하도록 설정하려면 app.config 파일에 다음 설정을 추가합니다.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseTimeZoneInfo=false" />
</runtime>
이 기능을 사용하도록 설정하면 DataContractJsonSerializer 개체는 TimeZone 형식 대신 TimeZoneInfo 형식을 사용하여 날짜 및 시간 데이터를 역직렬화합니다. TimeZoneInfo는 여러 조정 규칙을 지원하여 기록 표준 시간대 데이터를 사용할 수 있게 해줍니다. 반면 TimeZone은 이를 지원하지 않습니다.
TimeZoneInfo 구조 및 표준 시간대 조정에 대한 자세한 내용은 표준 시간대 개요참조하세요.
NetNamedPipeBinding의 최적의 일치
WCF에는 클라이언트 애플리케이션에서 항상 요청된 것과 가장 일치하는 URI에서 수신 대기하는 서비스에 연결할 수 있도록 설정할 수 있는 새 앱 설정이 있습니다. 이 앱 설정이 false
(기본값)로 설정되면, NetNamedPipeBinding을 사용하는 클라이언트가 요청된 URI의 일부 문자열에 해당하는 URI에서 수신 대기 중인 서비스에 연결을 시도할 수 있습니다.
예를 들어 클라이언트는 net.pipe://localhost/Service1
수신 대기하는 서비스에 연결하려고 하지만 관리자 권한으로 실행되는 컴퓨터의 다른 서비스는 net.pipe://localhost
수신 대기합니다. 이 앱 설정이 false
설정되면 클라이언트가 잘못된 서비스에 연결을 시도합니다. 앱 설정을 true
설정하면 클라이언트는 항상 가장 일치하는 서비스에 연결됩니다.
메모
NetNamedPipeBinding 사용하는 클라이언트는 전체 엔드포인트 주소가 아닌 서비스의 기본 주소(있는 경우)를 기반으로 서비스를 찾습니다. 이 설정이 항상 작동하도록 하려면 서비스에서 고유한 기본 주소를 사용해야 합니다.
이 변경을 사용하도록 설정하려면 클라이언트 애플리케이션의 App.config 또는 Web.config 파일에 다음 앱 설정을 추가합니다.
<configuration>
<appSettings>
<add key="wcf:useBestMatchNamedPipeUri" value="true" />
</appSettings>
</configuration>
SSL 3.0은 기본 프로토콜 아닙니다.
전송 보안 및 자격 증명 유형의 인증서와 함께 NetTcp를 사용하는 경우 SSL 3.0은 더 이상 보안 연결을 협상하는 데 사용되는 기본 프로토콜이 아닙니다. TLS 1.0이 NetTcp의 프로토콜 목록에 포함되어 있기 때문에 대부분의 경우 기존 앱에 영향을 주지 않아야 합니다. 모든 기존 클라이언트는 TLS 1.0 이상을 사용하여 연결을 협상할 수 있어야 합니다. Ssl3이 필요한 경우 다음 구성 메커니즘 중 하나를 사용하여 협상된 프로토콜 목록에 추가합니다.
<netTcpBinding> 섹션의 <전송> 섹션
WPF(Windows Presentation Foundation)
.NET Framework 4.6.2에서 Windows Presentation Foundation은 다음 영역에서 향상되었습니다.
그룹 정렬
CollectionView 개체를 사용하여 데이터를 그룹화하는 애플리케이션은 이제 그룹을 정렬하는 방법을 명시적으로 선언할 수 있습니다. 명시적 정렬은 앱이 그룹을 동적으로 추가 또는 제거하거나 그룹화와 관련된 항목 속성의 값을 변경할 때 발생하는 직관적이지 않은 순서 지정 문제를 해결합니다. 또한 그룹화 속성의 비교를 전체 컬렉션의 종류에서 그룹의 종류로 이동하여 그룹 만들기 프로세스의 성능을 향상시킬 수 있습니다.
그룹 정렬을 지원하기 위해 새 GroupDescription.SortDescriptions 및 GroupDescription.CustomSort 속성은 GroupDescription 개체에서 생성된 그룹의 컬렉션을 정렬하는 방법을 설명합니다. 이는 동일한 이름의 ListCollectionView 속성이 데이터 항목을 정렬하는 방법을 설명하는 방식과 유사합니다.
PropertyGroupDescription 클래스의 두 가지 새 정적 속성인 CompareNameAscending 및 CompareNameDescending가장 일반적인 경우에 사용할 수 있습니다.
예를 들어 다음 XAML은 연령별로 데이터를 그룹화하고, 연령 그룹을 오름차순으로 정렬하고, 각 연령 그룹 내의 항목을 성으로 그룹화합니다.
<GroupDescriptions>
<PropertyGroupDescription
PropertyName="Age"
CustomSort=
"{x:Static PropertyGroupDescription.CompareNamesAscending}"/>
</PropertyGroupDescription>
</GroupDescriptions>
<SortDescriptions>
<SortDescription PropertyName="LastName"/>
</SortDescriptions>
터치 키보드 지원
터치 키보드 지원을 사용하면 텍스트 입력을 사용할 수 있는 컨트롤에서 터치 입력을 받을 때 Windows 10에서 터치 키보드를 자동으로 호출하고 해제하여 WPF 애플리케이션에서 포커스 추적을 수행할 수 있습니다.
이전 버전의 .NET Framework에서 WPF 애플리케이션은 WPF 펜/터치 제스처 지원을 사용하지 않도록 설정하지 않고 포커스 추적을 옵트인할 수 없습니다. 따라서 WPF 애플리케이션은 전체 WPF 터치 지원을 선택하거나 Windows 마우스 프로모션을 사용해야 합니다.
모니터별 DPI
WPF 앱에 대한 높은 DPI 및 하이브리드-DPI 환경의 최근 확산을 지원하기 위해 .NET Framework 4.6.2의 WPF는 모니터별 인식을 가능하게 합니다. WPF 앱이 모니터별 DPI 인식이 되도록 설정하는 방법에 대한 자세한 내용은 GitHub의 샘플 및 개발자 가이드 참조하세요.
이전 버전의 .NET Framework에서 WPF 앱은 시스템 DPI를 인식합니다. 즉, 애플리케이션의 UI는 앱이 렌더링되는 모니터의 DPI에 따라 OS에 따라 적절하게 크기가 조정됩니다.
.NET Framework 4.6.2에서 실행되는 앱의 경우 다음과 같이 애플리케이션 구성 파일의 <런타임> 섹션에 구성 문을 추가하여 WPF 앱에서 모니터별 DPI 변경을 사용하지 않도록 설정할 수 있습니다.
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.DoNotScaleForDpiChanges=false"/>
</runtime>
WF(Windows Workflow Foundation)
.NET Framework 4.6.2에서 Windows Workflow Foundation은 다음 영역에서 향상되었습니다.
다시 호스팅된 WF 디자이너에서 C# 식 및 IntelliSense 지원
.NET Framework 4.5부터 WF는 Visual Studio Designer 및 코드 워크플로 모두에서 C# 식을 지원합니다. 다시 호스트된 워크플로 디자이너는 워크플로 디자이너가 Visual Studio 외부의 애플리케이션(예: WPF)에 있을 수 있도록 하는 WF의 주요 기능입니다. Windows Workflow Foundation은 다시 호스트된 워크플로 디자이너에서 C# 식 및 IntelliSense를 지원하는 기능을 제공합니다. 자세한 내용은 Windows Workflow Foundation 블로그참조하세요.
Availability of IntelliSense when a customer rebuilds a workflow project from Visual Studio
4.6.2 이전의 .NET Framework 버전에서는 고객이 Visual Studio에서 워크플로 프로젝트를 다시 빌드할 때 WF Designer IntelliSense가 중단됩니다. 프로젝트 빌드가 성공적이면 디자이너에서 워크플로 유형을 찾을 수 없으며 누락된 워크플로 유형에 대한 IntelliSense의 경고가 오류 목록 창에 표시됩니다. .NET Framework 4.6.2는 이 문제를 해결하고 IntelliSense를 사용할 수 있도록 합니다.
워크플로 추적이 있는 워크플로 V1 애플리케이션은 이제 FIPS 모드에서 실행됩니다
FIPS 준수 모드가 설정된 컴퓨터는 이제 워크플로 추적을 사용하여 워크플로 버전 1 스타일 애플리케이션을 성공적으로 실행할 수 있습니다. 이 시나리오를 사용하려면 app.config 파일을 다음과 같이 변경해야 합니다.
<add key="microsoft:WorkflowRuntime:FIPSRequired" value="true" />
이 시나리오를 사용하지 않는 경우 애플리케이션을 실행하면 "이 구현은 Windows 플랫폼 FIPS 유효성 검사 암호화 알고리즘의 일부가 아닙니다."라는 메시지와 함께 예외가 계속 생성됩니다.
Visual Studio 워크플로 디자이너 동적 업데이트를 사용하는 경우
워크플로 디자이너, FlowChart 활동 디자이너 및 기타 워크플로 활동 디자이너는 이제 DynamicUpdateServices.PrepareForUpdate 메서드를 호출한 후 저장된 워크플로를 성공적으로 로드하고 표시합니다. .NET Framework 4.6.2 이전의 .NET Framework 버전에서는 DynamicUpdateServices.PrepareForUpdate 호출한 후 저장된 워크플로에 대해 Visual Studio에서 XAML 파일을 로드하면 다음과 같은 문제가 발생할 수 있습니다.
워크플로 디자이너는 XAML 파일을 올바르게 로드할 수 없습니다(ViewStateData.Id 줄 끝에 있는 경우).
순서도 활동 디자이너 또는 다른 워크플로 활동 디자이너는 연결된 속성 값 대신 기본 위치에 모든 개체를 표시할 수 있습니다.
ClickOnce
ClickOnce는 이미 지원하는 1.0 프로토콜 외에도 TLS 1.1 및 TLS 1.2를 지원하도록 업데이트되었습니다. ClickOnce는 필요한 프로토콜을 자동으로 검색합니다. TLS 1.1 및 1.2 지원을 사용하도록 설정하려면 ClickOnce 애플리케이션 내에서 추가 단계가 필요하지 않습니다.
Windows Forms 및 WPF 앱을 UWP 앱으로 변환
이제 Windows는 WPF 및 Windows Forms 앱을 비롯한 기존 Windows 데스크톱 앱을 UWP(유니버설 Windows 플랫폼)로 가져오는 기능을 제공합니다. 이 기술은 기존 코드 베이스를 UWP로 점진적으로 마이그레이션하여 모든 Windows 10 디바이스에 앱을 가져올 수 있게 함으로써 브리지 역할을 합니다.
변환된 데스크톱 앱은 UWP 앱의 앱 ID와 유사한 앱 ID를 얻게 되며, 이를 통해 UWP API에 액세스하여 라이브 타일 및 알림과 같은 기능을 사용할 수 있습니다. 앱은 이전처럼 계속 동작하며 완전 신뢰 앱으로 실행됩니다. 앱이 변환되면 앱 컨테이너 프로세스를 기존 완전 신뢰 프로세스에 추가하여 적응형 사용자 인터페이스를 추가할 수 있습니다. 모든 기능을 앱 컨테이너 프로세스로 이동하면 완전 신뢰 프로세스를 제거하고 모든 Windows 10 디바이스에서 새 UWP 앱을 사용할 수 있습니다.
디버깅 개선 사항
NullReferenceException이(가) throw될 때 추가 분석을 수행하도록 .NET Framework 4.6.2에서 관리되지 않는 디버깅 API 이 향상되어 한 줄의 소스 코드에서 어떤 변수가 null
인지 확인할 수 있습니다. 이 시나리오를 지원하기 위해 관리되지 않는 디버깅 API에 다음 API가 추가되었습니다.
ICorDebugCode4, ICorDebugVariableHome및 관리되는 변수의 네이티브 홈을 노출하는 ICorDebugVariableHomeEnum 인터페이스입니다. 이렇게 하면 디버거가 NullReferenceException 발생할 때 일부 코드 흐름 분석을 수행하고 뒤로 작업하여
null
네이티브 위치에 해당하는 관리되는 변수를 확인할 수 있습니다.ICorDebugType2::GetTypeID 메서드는 ICorDebugType을 COR_TYPEID에 매핑하여 디버거가 ICorDebugType 인스턴스 없이도 COR_TYPEID를 가져올 수 있게 합니다. 그런 다음 COR_TYPEID의 기존 API를 사용하여 형식의 클래스 레이아웃을 확인할 수 있습니다.
.NET Framework 4.6.1의 새로운 기능
.NET Framework 4.6.1에는 다음 영역에 새로운 기능이 포함되어 있습니다.
.NET Framework 4.6.1에 대한 자세한 내용은 다음 항목을 참조하세요.
암호화: ECDSA를 포함하는 X509 인증서 지원
.NET Framework 4.6은 X509 인증서에 대한 RSACng 지원을 추가했습니다. .NET Framework 4.6.1은 ECDSA(타원 곡선 디지털 서명 알고리즘) X509 인증서에 대한 지원을 추가합니다.
ECDSA는 더 나은 성능을 제공하고 RSA보다 더 안전한 암호화 알고리즘으로, TLS(전송 계층 보안) 성능 및 확장성이 중요한 훌륭한 선택을 제공합니다. .NET Framework 구현은 호출을 기존 Windows 기능으로 래핑합니다.
다음 예제 코드는 .NET Framework 4.6.1에 포함된 ECDSA X509 인증서에 대한 새 지원을 사용하여 바이트 스트림에 대한 서명을 쉽게 생성하는 방법을 보여 줍니다.
using System;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;
public class Net461Code
{
public static byte[] SignECDsaSha512(byte[] data, X509Certificate2 cert)
{
using (ECDsa privateKey = cert.GetECDsaPrivateKey())
{
return privateKey.SignData(data, HashAlgorithmName.SHA512);
}
}
public static byte[] SignECDsaSha512(byte[] data, ECDsa privateKey)
{
return privateKey.SignData(data, HashAlgorithmName.SHA512);
}
}
Imports System.Security.Cryptography
Imports System.Security.Cryptography.X509Certificates
Public Class Net461Code
Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
Using privateKey As ECDsa = cert.GetECDsaPrivateKey()
Return privateKey.SignData(data, HashAlgorithmName.SHA512)
End Using
End Function
Public Shared Function SignECDsaSha512(data As Byte, privateKey As ECDsa) As Byte()
Return privateKey.SignData(data, HashAlgorithmName.SHA512)
End Function
End Class
이는 .NET Framework 4.6에서 서명을 생성하는 데 필요한 코드와 뚜렷한 대조를 제공합니다.
using System;
using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;
public class Net46Code
{
public static byte[] SignECDsaSha512(byte[] data, X509Certificate2 cert)
{
// This would require using cert.Handle and a series of p/invokes to get at the
// underlying key, then passing that to a CngKey object, and passing that to
// new ECDsa(CngKey). It's a lot of work.
throw new Exception("That's a lot of work...");
}
public static byte[] SignECDsaSha512(byte[] data, ECDsa privateKey)
{
// This way works, but SignData probably better matches what you want.
using (SHA512 hasher = SHA512.Create())
{
byte[] signature1 = privateKey.SignHash(hasher.ComputeHash(data));
}
// This might not be the ECDsa you got!
ECDsaCng ecDsaCng = (ECDsaCng)privateKey;
ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512;
return ecDsaCng.SignData(data);
}
}
Imports System.Security.Cryptography
Imports System.Security.Cryptography.X509Certificates
Public Class Net46Code
Public Shared Function SignECDsaSha512(data As Byte(), cert As X509Certificate2) As Byte()
' This would require using cert.Handle and a series of p/invokes to get at the
' underlying key, then passing that to a CngKey object, and passing that to
' new ECDsa(CngKey). It's a lot of work.
Throw New Exception("That's a lot of work...")
End Function
Public Shared Function SignECDsaSha512(data As Byte(), privateKey As ECDsa) As Byte()
' This way works, but SignData probably better matches what you want.
Using hasher As SHA512 = SHA512.Create()
Dim signature1 As Byte() = privateKey.SignHash(hasher.ComputeHash(data))
End Using
' This might not be the ECDsa you got!
Dim ecDsaCng As ECDsaCng = CType(privateKey, ECDsaCng)
ecDsaCng.HashAlgorithm = CngAlgorithm.Sha512
Return ecDsaCng.SignData(data)
End Function
End Class
ADO.NET
다음이 ADO.NET에 추가되었습니다.
하드웨어로 보호된 키를 위한 Always Encrypted 지원
이제 ADO.NET HSM(하드웨어 보안 모듈)에 기본적으로 Always Encrypted 열 마스터 키 저장을 지원합니다. 이 지원을 통해 고객은 사용자 지정 열 마스터 키 저장소 공급자를 작성하고 애플리케이션에 등록하지 않고도 HSM에 저장된 비대칭 키를 활용할 수 있습니다.
고객은 HSM에 저장된 열 마스터 키로 보호되는 Always Encrypted 데이터에 액세스하려면 앱 서버 또는 클라이언트 컴퓨터에 HSM 공급업체에서 제공하는 CSP 공급자 또는 CNG 키 저장소 공급자를 설치해야 합니다.
AlwaysOn 대한 향상된 MultiSubnetFailover 연결 동작
이제 SqlClient는 AG(AlwaysOn 가용성 그룹)에 대한 더 빠른 연결을 자동으로 제공합니다. 애플리케이션이 다른 서브넷의 AlwaysOn AG(가용성 그룹)에 연결하는지 여부를 투명하게 검색하고 현재 활성 서버를 빠르게 검색하고 서버에 대한 연결을 제공합니다. 이 릴리스 이전에 애플리케이션은 AlwaysOn 가용성 그룹에 연결 중임을 나타내기 위해 "MultisubnetFailover=true"
포함하도록 연결 문자열을 설정해야 했습니다. 연결 키워드를 true
설정하지 않으면 애플리케이션에서 AlwaysOn 가용성 그룹에 연결하는 동안 시간 제한이 발생할 수 있습니다. 이 릴리스로 애플리케이션은 더 이상 MultiSubnetFailover로 true
설정할 필요가 없습니다. Always On 가용성 그룹에 대한 SqlClient 지원에 관한 자세한 내용은 고가용성 및 재해 복구에 대한 SqlClient 지원을 참조하세요.
WPF(Windows Presentation Foundation)
Windows Presentation Foundation에는 다양한 개선 사항과 변경 내용이 포함되어 있습니다.
향상된 성능
터치 이벤트 발생 지연은 .NET Framework 4.6.1에서 수정되었습니다. 또한 RichTextBox 컨트롤에 입력할 때 더 이상 빠른 입력 중에 렌더링 스레드가 차단되지 않습니다.
맞춤법 검사 개선 사항
WPF의 맞춤법 검사기는 추가 언어 맞춤법 검사에 대한 운영 체제 지원을 활용하도록 Windows 8.1 이상 버전에서 업데이트되었습니다. Windows 8.1 이전의 Windows 버전에서는 기능이 변경되지 않습니다.
이전 버전의 .NET Framework와 마찬가지로 TextBox 컨트롤 또는 RichTextBox 블록에 대한 언어는 다음 순서대로 확인됩니다.
xml:lang
이 있으면.현재 입력 언어입니다.
현재 문화.
WPF의 언어 지원에 대한 자세한 내용은.NET Framework 4.6.1 기능에 대한
사용자별 사용자 지정 사전 대한 추가 지원
.NET Framework 4.6.1에서 WPF는 전역적으로 등록된 사용자 지정 사전을 인식합니다. 이 기능은 컨트롤별로 등록하는 기능 외에도 사용할 수 있습니다.
이전 버전의 WPF에서는 사용자 지정 사전이 제외된 단어 및 자동 고침 목록을 인식하지 못했습니다.
%AppData%\Microsoft\Spelling\<language tag>
디렉터리 아래에 배치할 수 있는 파일을 사용하여 Windows 8.1 및 Windows 10에서 지원됩니다. 다음 규칙이 이러한 파일에 적용됩니다.
파일에는 .dic(추가된 단어의 경우), .exc(제외된 단어의 경우) 또는 .acl(자동 고침의 경우)의 확장명이 있어야 합니다.
파일은 BOM(바이트 순서 표시)으로 시작하는 UTF-16 LE 일반 텍스트여야 합니다.
각 줄은 추가 및 제외된 단어 목록의 단어, 또는 자동 고침 단어 목록에서 세로 막대("|")로 구분된 자동 고침 쌍의 단어로 구성되어야 합니다.
이러한 파일은 읽기 전용으로 간주되며 시스템에서 수정하지 않습니다.
메모
이러한 새 파일 형식은 WPF 맞춤법 검사 API에서 직접 지원되지 않으며 애플리케이션에서 WPF에 제공된 사용자 지정 사전은 .lex 파일을 계속 사용해야 합니다.
샘플
Microsoft/WPF 샘플 GitHub 리포지토리에는 여러 WPF 샘플이 있습니다. 끌어오기 요청을 보내거나 GitHub 문제열어 샘플을 개선하는 데 도움을 주세요.
DirectX 확장
WPF에는 DX10 및 Dx11 콘텐츠와 쉽게 상호 운용할 수 있는 D3DImage 새로운 구현을 제공하는 NuGet 패키지 포함되어 있습니다. 이 패키지의 코드는 오픈 소스로 공개되었으며 GitHub 에서 사용할 수 있습니다.
Windows Workflow Foundation: 트랜잭션
이제 Transaction.EnlistPromotableSinglePhase 메서드는 트랜잭션을 승격하기 위해 MSDTC가 아닌 다른 분산 트랜잭션 관리자를 사용할 수 있습니다. 이렇게 하려면 GUID 트랜잭션 프로모터 식별자를 새 Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) 오버로드에 지정합니다. 이 작업이 성공하면 트랜잭션의 기능에 제한이 적용됩니다. MSDTC 이외의 트랜잭션 프로모터가 등록되면, 다음 메서드는 MSDTC로 승격되어야 하므로 TransactionPromotionException 예외를 발생시킵니다.
MSDTC가 아닌 트랜잭션 프로모터가 등록되면, 이는 자신이 정의한 프로토콜을 사용하여 향후 지속 가능한 등록에 사용되어야 합니다. 트랜잭션 프로모터의 Guid은(는) PromoterType 속성을 사용하여 얻을 수 있습니다. 트랜잭션이 승격되면 트랜잭션 프로모터는 승격된 토큰을 나타내는 Byte 배열을 제공합니다. 애플리케이션은 GetPromotedToken 메서드를 사용하여 MSDTC가 아닌 승격된 트랜잭션에 대해 승격된 토큰을 가져올 수 있습니다.
새 Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) 오버로드의 사용자는 승격 작업이 성공적으로 완료되도록 특정 호출 순서를 따라야 합니다. 이러한 규칙은 메서드의 설명서에 설명되어 있습니다.
프로파일링
관리되지 않는 프로파일링 API는 다음과 같이 향상되었습니다.
ICorProfilerInfo7 인터페이스에서 PDB에 대한 향상된 액세스를 지원합니다.
ASP.NET Core에서는 Roslyn에서 어셈블리를 메모리 내로 컴파일하는 것이 훨씬 더 일반화되고 있습니다. 프로파일링 도구를 만드는 개발자의 경우 이는 지금까지 디스크에서 직렬화된 PDB가 더 이상 존재하지 않을 수 있음을 의미합니다. 프로파일러 도구는 종종 PDB를 사용하여 코드 검사 또는 줄별 성능 분석과 같은 작업을 위해 코드를 소스 줄에 다시 매핑합니다. ICorProfilerInfo7 인터페이스에는 이제 ICorProfilerInfo7::GetInMemorySymbolsLength 및 ICorProfilerInfo7::ReadInMemorySymbols두 가지 새로운 메서드가 포함되어 있습니다. 이를 통해 이러한 프로파일러 도구가 인메모리 PDB 데이터에 액세스할 수 있습니다. 새로운 API를 사용하면, 프로파일러가 인메모리 PDB의 콘텐츠를 바이트 배열로 가져온 다음 처리하거나 직렬화하여 디스크에 저장할 수 있습니다.
ICorProfiler 인터페이스를 사용하여 더 나은 계측.
이제 동적 계측에
ICorProfiler
API ReJit 기능을 사용하는 프로파일러가 일부 메타데이터를 수정할 수 있습니다. 이전에는 이러한 도구가 언제든지 IL을 계측할 수 있었지만 메타데이터는 모듈 로드 시간에만 수정할 수 있습니다. IL은 메타데이터를 참조하므로 수행할 수 있는 계측의 종류가 제한되었습니다. 특히 새AssemblyRef
,TypeRef
,TypeSpec
,MemberRef
,MemberSpec
및UserString
레코드를 추가하여 모듈 로드 후 메타데이터 편집의 하위 집합을 지원하기 위해 ICorProfilerInfo7::ApplyMetaData 메서드를 추가하여 이러한 제한 중 일부를 해제했습니다. 이렇게 변경하면 훨씬 더 광범위한 즉석 계측이 가능합니다.
NGEN(네이티브 이미지 생성기) PDB
컴퓨터 간 이벤트 추적을 사용하면 고객이 컴퓨터 A에서 프로그램을 프로파일링하고 컴퓨터 B에서 원본 줄 매핑을 사용하여 프로파일링 데이터를 볼 수 있습니다. 이전 버전의 .NET Framework를 사용하면 프로파일링된 컴퓨터의 모든 모듈과 네이티브 이미지를 IL PDB가 포함된 분석 머신으로 복사하여 원본-네이티브 매핑을 만듭니다. 이 프로세스는 휴대폰 애플리케이션과 같이 파일이 비교적 작은 경우 잘 작동할 수 있지만, 파일은 데스크톱 시스템에서 매우 크고 복사하는 데 상당한 시간이 필요할 수 있습니다.
Ngen PDB를 사용하면 NGen은 IL PDB에 의존하지 않고 IL에서 네이티브로의 매핑을 포함하는 PDB를 생성할 수 있습니다. 크로스 머신 이벤트 추적 시나리오에서 필요한 것은 머신 A에서 생성된 네이티브 이미지 PDB를 머신 B로 복사하고, 디버그 인터페이스 액세스 API를 사용하여 IL PDB의 소스-to-IL 매핑과 네이티브 이미지 PDB의 IL-네이티브 매핑을 읽는 것입니다. 두 매핑을 결합하면 원본-네이티브 매핑이 제공됩니다. 네이티브 이미지 PDB는 모든 모듈 및 네이티브 이미지보다 훨씬 작기 때문에 컴퓨터 A에서 컴퓨터 B로 복사하는 프로세스가 훨씬 빠릅니다.
.NET 2015의 새로운 기능
.NET 2015에는 .NET Framework 4.6 및 .NET Core가 도입되었습니다. 일부 새로운 기능은 둘 다에 적용되며, 다른 기능은 .NET Framework 4.6 또는 .NET Core와 관련이 있습니다.
ASP.NET Core
.NET 2015에는 최신 클라우드 기반 앱을 빌드하기 위한 린 .NET 구현인 ASP.NET Core가 포함되어 있습니다. ASP.NET Core는 모듈식이므로 애플리케이션에 필요한 기능만 포함할 수 있습니다. IIS에서 호스트되거나 사용자 지정 프로세스에서 자체 호스팅될 수 있으며 동일한 서버에서 다른 버전의 .NET Framework를 사용하여 앱을 실행할 수 있습니다. 여기에는 클라우드 배포를 위해 설계된 새로운 환경 구성 시스템이 포함되어 있습니다.
MVC, Web API 및 웹 페이지는 MVC 6이라는 단일 프레임워크로 통합됩니다. Visual Studio 2015 이상에서 도구를 통해 ASP.NET Core 앱을 빌드합니다. 기존 애플리케이션은 새 .NET Framework에서 작동합니다. 그러나 MVC 6 또는 SignalR 3을 사용하는 앱을 빌드하려면 Visual Studio 2015 이상에서 프로젝트 시스템을 사용해야 합니다.
자세한 내용은 ASP.NET Core참조하세요.
ASP.NET 업데이트
비동기 응답 처리를 위한 작업 기반 API
이제 ASP.NET은 언어의
async/await
지원을 사용하여 응답을 비동기적으로 플러시할 수 있는, 비동기 응답 플러시 HttpResponse.FlushAsync작업 기반 API를 간단하게 제공합니다.모델 바인딩은 작업 반환 메서드 지원합니다.
.NET Framework 4.5에서 ASP.NET Web Forms 페이지 및 사용자 컨트롤에서 CRUD 기반 데이터 작업에 확장 가능한 코드 중심 접근 방식을 사용하도록 설정하는 모델 바인딩 기능을 추가했습니다. 이제 모델 바인딩 시스템은 Task반환 모델 바인딩 메서드를 지원합니다. 이 기능을 통해 Web Forms 개발자는 Entity Framework를 포함한 최신 버전의 ORM을 사용할 때, 데이터 바인딩 시스템의 편리함과 비동기의 확장성 이점을 동시에 누릴 수 있습니다.
비동기 모델 바인딩은
aspnet:EnableAsyncModelBinding
구성 설정에 의해 제어됩니다.<appSettings> <add key=" aspnet:EnableAsyncModelBinding" value="true|false" /> </appSettings>
대상 .NET Framework 4.6 앱에서는 기본적으로
true
로 설정됩니다. .NET Framework 4.6에서 이전 버전의 .NET Framework를 대상으로 실행되는 앱에서는 기본적으로false
로 설정됩니다. 구성 설정을true
으로 설정하여 사용할 수 있습니다.HTTP/2 지원(Windows 10)
HTTP/2 훨씬 더 나은 연결 사용률(클라이언트와 서버 간의 왕복 감소)을 제공하는 새 버전의 HTTP 프로토콜로, 사용자의 웹 페이지 로드 대기 시간이 짧아집니다. 프로토콜은 단일 환경의 일부로 요청되는 여러 아티팩트를 최적화하므로 웹 페이지(서비스가 아닌)는 HTTP/2에서 가장 많은 이점을 제공합니다. .NET Framework 4.6의 ASP.NET HTTP/2 지원이 추가되었습니다. 네트워킹 기능은 여러 계층에 존재하기 때문에 WINDOWS, IIS 및 ASP.NET HTTP/2를 사용하도록 설정하기 위해 새로운 기능이 필요했습니다. ASP.NET 함께 HTTP/2를 사용하려면 Windows 10에서 실행해야 합니다.
HTTP/2는 기본적으로 System.Net.Http.HttpClient API를 사용하는 Windows 10 UWP(유니버설 Windows 플랫폼) 앱에서도 지원됩니다.
ASP.NET 애플리케이션에서 PUSH_PROMISE 기능을 사용하는 방법을 제공하기 위해 PushPromise(String) 및 PushPromise(String, String, NameValueCollection)두 오버로드가 있는 새 메서드가 HttpResponse 클래스에 추가되었습니다.
메모
ASP.NET Core는 HTTP/2를 지원하지만 PUSH PROMISE 기능에 대한 지원은 아직 추가되지 않았습니다.
브라우저와 웹 서버(Windows의 IIS)는 모든 작업을 수행합니다. 사용자를 위해 많은 작업을 수행할 필요가 없습니다.
대부분의 주요 브라우저는 HTTP/2지원하므로 서버에서 지원하는 경우 사용자가 HTTP/2 지원을 활용할 수 있습니다.
토큰 바인딩 프로토콜에 대한 지원
Microsoft와 Google은 토큰 바인딩 프로토콜인증에 대한 새로운 접근 방식을 공동 작업하고 있습니다. 전제는 인증 토큰(브라우저 캐시)을 도난당하고 범죄자가 암호 또는 기타 권한 있는 지식 없이 보안 리소스(예: 은행 계좌)에 액세스하는 데 사용할 수 있다는 것입니다. 새 프로토콜은 이 문제를 완화하는 것을 목표로 합니다.
토큰 바인딩 프로토콜은 Windows 10에서 브라우저 기능으로 구현됩니다. ASP.NET 앱은 프로토콜에 참여하므로 인증 토큰의 유효성이 합법적인 것으로 확인됩니다. 클라이언트 및 서버 구현은 프로토콜에 지정된 엔드 투 엔드 보호를 설정합니다.
임의 문자열 해시 알고리즘
.NET Framework 4.5에는 임의 문자열 해시 알고리즘도입되었습니다. ASP.NET의 일부 기능이 안정적인 해시 코드에 의존했기 때문에 ASP.NET이 지원되지 않았습니다. .NET Framework 4.6에서는 이제 임의 문자열 해시 알고리즘이 지원됩니다. 이 기능을 사용하려면
aspnet:UseRandomizedStringHashAlgorithm
구성 설정을 사용합니다.<appSettings> <add key="aspnet:UseRandomizedStringHashAlgorithm" value="true|false" /> </appSettings>
ADO.NET
이제 ADO .NET은 SQL Server 2016에서 사용할 수 있는 Always Encrypted 기능을 지원합니다. Always Encrypted를 사용하면 SQL Server가 암호화된 데이터에 대한 작업을 수행할 수 있으며, 가장 좋은 점은 암호화 키가 서버가 아닌 고객의 신뢰할 수 있는 환경 내 애플리케이션에 상주한다는 것입니다. Always Encrypted는 고객 데이터를 보호하므로 DBA는 일반 텍스트 데이터에 액세스할 수 없습니다. 데이터 암호화 및 암호 해독은 드라이버 수준에서 투명하게 수행되어 기존 애플리케이션에 대한 변경을 최소화합니다. 자세한 내용은 Always Encrypted(데이터베이스 엔진) 및 Always Encrypted(클라이언트 개발)참조하세요.
64비트 JIT 컴파일러 관리 코드용
.NET Framework 4.6에는 64비트 JIT 컴파일러의 새 버전(원래 코드 이름이 RyuJIT)이 있습니다. 새로운 64비트 컴파일러는 이전 64비트 JIT 컴파일러보다 성능이 크게 향상되었습니다. 새 64비트 컴파일러는 .NET Framework 4.6을 기반으로 실행되는 64비트 프로세스에 대해 사용하도록 설정됩니다. 앱은 64비트 또는 AnyCPU로 컴파일되고 64비트 운영 체제에서 실행되는 경우 64비트 프로세스에서 실행됩니다. 새 컴파일러로의 전환을 가능한 한 투명하게 만들기 위해 주의를 기울이고 있지만 동작의 변경이 가능합니다.
새로운 64비트 JIT 컴파일러에는 System.Numerics 네임스페이스의 SIMD 사용 형식과 결합된 하드웨어 SIMD 가속 기능도 포함되어 있어 성능이 향상될 수 있습니다.
어셈블리 로더 개선
이제 어셈블리 로더는 해당 NGEN 이미지가 로드된 후 IL 어셈블리를 언로드하여 메모리를 보다 효율적으로 사용합니다. 이러한 변경으로 인해 가상 메모리가 감소하며, 특히 Visual Studio와 같은 대형 32비트 앱에 도움이 되며 실제 메모리도 저장됩니다.
기본 클래스 라이브러리 변경
주요 시나리오를 사용할 수 있도록 .NET Framework 4.6에 많은 새 API가 추가되었습니다. 여기에는 다음과 같은 변경 내용 및 추가가 포함됩니다.
IReadOnlyCollection<T> 구현
추가 컬렉션은 Queue<T> 및 Stack<T>와 같이 IReadOnlyCollection<T>를 구현합니다.
CultureInfo.CurrentCulture 및 CultureInfo.CurrentUICulture
이제 CultureInfo.CurrentCulture 및 CultureInfo.CurrentUICulture 속성이 읽기 전용이 아닌 읽기/쓰기가 가능합니다. 이러한 속성에 새 CultureInfo 개체를 할당하면
Thread.CurrentThread.CurrentCulture
속성으로 정의된 현재 스레드 문화권과Thread.CurrentThread.CurrentUICulture
속성에서 정의한 현재 UI 스레드 문화권도 변경됩니다.가비지 수집(GC) 향상
이제 GC 클래스에는 중요한 경로를 실행하는 동안 가비지 수집을 허용하지 않는 TryStartNoGCRegion 및 EndNoGCRegion 메서드가 포함됩니다.
GC.Collect(Int32, GCCollectionMode, Boolean, Boolean) 메서드의 새로운 오버로드를 사용하면 작은 개체 힙과 큰 개체 힙을 모두 정리하고 압축할지 아니면 단순히 정리할지만 제어할 수 있습니다.
SIMD 사용 형식
이제 System.Numerics 네임스페이스에는 Matrix3x2, Matrix4x4, Plane, Quaternion, Vector2, Vector3및 Vector4같은 여러 SIMD 사용 형식이 포함됩니다.
새로운 64비트 JIT 컴파일러에도 하드웨어 SIMD 가속 기능이 포함되어 있기 때문에 새로운 64비트 JIT 컴파일러와 함께 SIMD 사용 형식을 사용할 때 특히 성능이 크게 향상되었습니다.
암호화 업데이트
System.Security.Cryptography API는 Windows CNG 암호화 API지원하도록 업데이트되고 있습니다. 이전 버전의 .NET Framework는
구현의 기초로 이전 버전의 Windows Cryptography API에 전적으로 의존했습니다. CNG API는 특정 범주의 앱에 중요한 최신 암호화 알고리즘 지원하기 때문에 CNG API를 지원하라는 요청을 받았습니다. .NET Framework 4.6에는 Windows CNG 암호화 API를 지원하기 위한 다음과 같은 새로운 향상된 기능이 포함되어 있습니다.
가능한 경우 CAPI 기반 구현이 아닌 CNG 기반 구현을 반환하는 X509 인증서,
System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2)
및System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(System.Security.Cryptography.X509Certificates.X509Certificate2)
대한 확장 메서드 집합입니다. (일부 스마트 카드 등은 여전히 CAPI가 필요하며 API는 대체를 처리합니다).RSA 알고리즘의 CNG 구현을 제공하는 System.Security.Cryptography.RSACng 클래스입니다.
일반적인 작업에 더 이상 캐스팅이 필요하지 않도록 RSA API가 향상되었습니다. 예를 들어 X509Certificate2 개체를 사용하여 데이터를 암호화하려면 이전 버전의 .NET Framework에서 다음과 같은 코드가 필요합니다.
RSACryptoServiceProvider rsa = (RSACryptoServiceProvider)cert.PrivateKey; byte[] oaepEncrypted = rsa.Encrypt(data, true); byte[] pkcs1Encrypted = rsa.Encrypt(data, false);
Dim rsa As RSACryptoServiceProvider = CType(cert.PrivateKey, RSACryptoServiceProvider) Dim oaepEncrypted() As Byte = rsa.Encrypt(data, True) Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, False)
.NET Framework 4.6에서 새 암호화 API를 사용하는 코드를 다음과 같이 다시 작성하여 캐스트를 방지할 수 있습니다.
RSA rsa = cert.GetRSAPrivateKey(); if (rsa == null) throw new InvalidOperationException("An RSA certificate was expected"); byte[] oaepEncrypted = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1); byte[] pkcs1Encrypted = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1);
Dim rsa As RSA = cert.GetRSAPrivateKey() If rsa Is Nothing Then Throw New InvalidOperationException("An RSA certificate was expected") End If Dim oaepEncrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.OaepSHA1) Dim pkcs1Encrypted() As Byte = rsa.Encrypt(data, RSAEncryptionPadding.Pkcs1)
날짜 및 시간을 유닉스 시간으로 변환하기 위한 지원
Unix 시간으로 또는 Unix 시간에서 날짜 및 시간 값을 변환할 수 있도록 DateTimeOffset 구조에 다음과 같은 새로운 메서드가 추가되었습니다.
호환성 스위치
AppContext 클래스는 라이브러리 작성자가 사용자에게 새로운 기능을 위한 균일한 옵트아웃 메커니즘을 제공할 수 있도록 하는 새로운 호환성 기능을 추가합니다. 옵트아웃 요청을 전달하기 위해 구성 요소 간에 느슨하게 결합된 계약을 설정합니다. 이 기능은 일반적으로 기존 기능을 변경할 때 중요합니다. 반대로 새 기능에 대한 암시적 옵트인이 이미 있습니다.
AppContext사용하여 라이브러리는 호환성 스위치를 정의하고 노출하며, 라이브러리에 의존하는 코드는 해당 스위치를 설정하여 라이브러리 동작에 영향을 줄 수 있습니다. 기본적으로 라이브러리는 새 기능을 제공하며 스위치가 설정된 경우에만 변경합니다(즉, 이전 기능을 제공).
애플리케이션(또는 라이브러리)은 종속 라이브러리가 정의하는 스위치의 값(항상 Boolean 값)을 선언할 수 있습니다. 스위치는 암시적으로 항상
false
입니다. 스위치를true
설정하면 활성화됩니다. 스위치를false
으로 명시적으로 설정하면 새로운 동작이 활성화됩니다.AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", true);
AppContext.SetSwitch("Switch.AmazingLib.ThrowOnException", True)
라이브러리는 소비자가 스위치의 값을 선언했는지 확인한 다음 적절하게 조치해야 합니다.
if (!AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", out shouldThrow)) { // This is the case where the switch value was not set by the application. // The library can choose to get the value of shouldThrow by other means. // If no overrides nor default values are specified, the value should be 'false'. // A false value implies the latest behavior. } // The library can use the value of shouldThrow to throw exceptions or not. if (shouldThrow) { // old code } else { // new code }
If Not AppContext.TryGetSwitch("Switch.AmazingLib.ThrowOnException", shouldThrow) Then ' This is the case where the switch value was not set by the application. ' The library can choose to get the value of shouldThrow by other means. ' If no overrides nor default values are specified, the value should be 'false'. ' A false value implies the latest behavior. End If ' The library can use the value of shouldThrow to throw exceptions or not. If shouldThrow Then ' old code Else ' new code End If
스위치는 라이브러리에서 공개하는 공식 계약이므로 일관된 형식을 사용하는 것이 좋습니다. 다음은 두 가지 명백한 형식입니다.
스위치.네임스페이스. 스위치 이름
스위치.라이브러리.스위치 이름
작업 기반 비동기 패턴(TAP) 변경 사항
.NET Framework 4.6을 대상으로 하는 앱의 경우 Task 및 Task<TResult> 개체는 호출 스레드의 문화권 및 UI 문화권을 상속합니다. 이전 버전의 .NET Framework를 대상으로 하거나 특정 버전의 .NET Framework를 대상으로 하지 않는 앱의 동작은 영향을 받지 않습니다. 자세한 내용은 CultureInfo 클래스 항목의 "문화권 및 작업 기반 비동기 작업" 섹션을 참조하세요.
System.Threading.AsyncLocal<T> 클래스를 사용하면 지정된 비동기 제어 흐름(예:
async
메서드)에 로컬인 앰비언트 데이터를 나타낼 수 있습니다. 스레드 간에 데이터를 유지하는 데 사용할 수 있습니다. AsyncLocal<T>.Value 속성이 명시적으로 변경되었거나 스레드에서 컨텍스트 전환이 발생했기 때문에 앰비언트 데이터가 변경될 때마다 알림을 받을 콜백 메서드를 정의할 수도 있습니다.완료된 작업을 특정 상태로 반환하기 위해 tap(작업 기반 비동기 패턴)에 Task.CompletedTask, Task.FromCanceled및 Task.FromException세 가지 편리한 메서드가 추가되었습니다.
NamedPipeClientStream 클래스는 이제 새 ConnectAsync을 통해 비동기 통신을 지원합니다. 메서드.
EventSource는 이제 이벤트 로그 쓰기를 지원합니다.
이제 EventSource 클래스를 사용하여 머신에서 만든 기존 ETW 세션 외에도 관리 또는 운영 메시지를 이벤트 로그에 기록할 수 있습니다. 이전에는 이 기능에 Microsoft.Diagnostics.Tracing.EventSource NuGet 패키지를 사용해야 했습니다. 이 기능은 이제 .NET Framework 4.6에 기본 제공됩니다.
NuGet 패키지와 .NET Framework 4.6은 모두 다음 기능으로 업데이트되었습니다.
동적 이벤트
이벤트 메서드를 만들지 않고 "즉석에서" 정의된 이벤트를 허용합니다.
풍부한 탑재물
특수하게 특성이 지정된 클래스 및 배열과 기본 형식을 페이로드로 전달할 수 있습니다.
활동 추적
시작 및 중지 이벤트가 현재 활성화된 모든 활동을 나타내는 ID를 사용하여 이벤트 간에 태그를 지정하도록 합니다.
이러한 기능을 지원하기 위해 오버로드된 Write 메서드가 EventSource 클래스에 추가되었습니다.
Windows Presentation Foundation (WPF)
HDPI 개선 사항
이제 .NET Framework 4.6에서 WPF의 HDPI 지원이 향상되었습니다. 테두리가 있는 컨트롤에서 잘림 현상을 줄이기 위해 레이아웃 반올림이 변경되었습니다. 기본적으로 이 기능은 TargetFrameworkAttribute .NET Framework 4.6으로 설정된 경우에만 사용하도록 설정됩니다. 이전 버전의 프레임워크를 대상으로 하지만 .NET Framework 4.6에서 실행되는 애플리케이션은 app.config 파일의 <런타임> 섹션에 다음 줄을 추가하여 새 동작을 옵트인할 수 있습니다.
<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />
여러 모니터에 걸쳐 있고 다른 DPI 설정(다중 DPI 설정)을 사용하는 WPF 창은 이제 검은색으로 표시된 영역 없이 완전히 렌더링됩니다. 이 새 동작을 사용하지 않도록 설정하려면 app.config 파일의
<appSettings>
섹션에 다음 줄을 추가하여 이 동작을 옵트아웃할 수 있습니다.<add key="EnableMultiMonitorDisplayClipping" value="true"/>
DPI 설정에 따라 올바른 커서를 자동으로 로드하는 기능이 System.Windows.Input.Cursor에 추가되었습니다.
터치가 더 좋습니다
터치가 예측할 수 없는 동작을 생성하는 Connect 대한 고객 보고서는 .NET Framework 4.6에서 해결되었습니다. Windows 스토어 애플리케이션 및 WPF 애플리케이션에 대한 이중 탭 임계값은 이제 Windows 8.1 이상에서 동일합니다.
투명 자식 창 지원 기능
.NET Framework 4.6의 WPF는 Windows 8.1 이상에서 투명한 자식 창을 지원합니다. 이렇게 하면 최상위 창에서 직사각형이 아닌 투명한 자식 창을 만들 수 있습니다. HwndSourceParameters.UsesPerPixelTransparency 속성을
true
설정하여 이 기능을 사용하도록 설정할 수 있습니다.
WCF(Windows Communication Foundation)
SSL 지원
이제 WCF는 전송 보안 및 클라이언트 인증과 함께 NetTcp를 사용하는 경우 SSL 3.0 및 TLS 1.0 외에도 SSL 버전 TLS 1.1 및 TLS 1.2를 지원합니다. 이제 사용할 프로토콜을 선택하거나 보안이 낮은 이전 프로토콜을 사용하지 않도록 설정할 수 있습니다. 이 작업은 SslProtocols 속성을 설정하거나 구성 파일에 다음을 추가하여 수행할 수 있습니다.
<netTcpBinding> <binding> <security mode= "None|Transport|Message|TransportWithMessageCredential" > <transport clientCredentialType="None|Windows|Certificate" protectionLevel="None|Sign|EncryptAndSign" sslProtocols="Ssl3|Tls1|Tls11|Tls12"> </transport> </security> </binding> </netTcpBinding>
다른 HTTP 연결을 사용하여 메시지 보내기
이제 WCF를 통해 사용자는 다른 기본 HTTP 연결을 사용하여 특정 메시지를 보낼 수 있습니다. 이 작업을 수행하는 방법에는 두 가지가 있습니다.
연결 그룹 이름 접두사 사용
사용자는 WCF가 연결 그룹 이름의 접두사로 사용할 문자열을 지정할 수 있습니다. 서로 다른 접두사를 가진 두 메시지는 서로 다른 기본 HTTP 연결을 사용하여 전송됩니다. 메시지의 Message.Properties 속성에 키/값 쌍을 추가하여 접두사를 설정합니다. 키는 "HttpTransportConnectionGroupNamePrefix"입니다. 값은 원하는 접두사입니다.
다른 채널 팩터리 사용하기
사용자는 다른 채널 팩터리에서 만든 채널을 사용하여 보낸 메시지가 서로 다른 기본 HTTP 연결을 사용하도록 하는 기능을 사용하도록 설정할 수도 있습니다. 이 기능을 사용하려면 사용자가 다음을
appSetting
에서true
로 설정해야 합니다.<appSettings> <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true" /> </appSettings>
WWF(Windows Workflow Foundation)
이제 미해결 "비표준 프로토콜" 책갈피가 있는 경우, 요청이 시간 초과되기 전에 워크플로 서비스가 순서가 벗어난 작업 요청을 보류할 시간을 초 단위로 지정할 수 있습니다. "비 프로토콜" 책갈피는 미해결 수신 활동과 관련이 없는 책갈피입니다. 일부 활동은 구현 내에서 프로토콜이 아닌 책갈피를 만들므로 프로토콜이 아닌 책갈피가 존재하는 것은 분명하지 않을 수 있습니다. 여기에는 상태와 선택이 포함됩니다. 따라서 상태 머신으로 구현되었거나 Pick 작업을 포함하는 워크플로 서비스가 있는 경우, 비프로토콜 책갈피가 있을 가능성이 큽니다. app.config 파일의
appSettings
섹션에 다음과 같은 줄을 추가하여 간격을 지정합니다.<add key="microsoft:WorkflowServices:FilterResumeTimeoutInSeconds" value="60"/>
기본값은 60초입니다.
value
0으로 설정하면 다음과 같은 텍스트 오류가 있는 잘못된 요청이 즉시 거부됩니다.Operation 'Request3|{http://tempuri.org/}IService' on service instance with identifier '2b0667b6-09c8-4093-9d02-f6c67d534292' cannot be performed at this time. Please ensure that the operations are performed in the correct order and that the binding in use provides ordered delivery guarantees.
순서가 잘못된 작업 메시지가 수신되고 프로토콜이 아닌 책갈피가 없는 경우 받는 것과 동일한 메시지입니다.
FilterResumeTimeoutInSeconds
요소의 값이 0이 아니면 프로토콜이 아닌 책갈피가 있고 시간 제한 간격이 만료되면 시간 제한 메시지와 함께 작업이 실패합니다.트랜잭션
이제 TransactionException에서 파생된 예외가 발생한 트랜잭션에 대한 분산 트랜잭션 식별자를 포함할 수 있습니다. app.config 파일의
appSettings
섹션에 다음 키를 추가하여 이 작업을 수행합니다.<add key="Transactions:IncludeDistributedTransactionIdInExceptionMessage" value="true"/>
기본값은
false
.네트워킹
소켓 재사용
Windows 10에는 아웃바운드 TCP 연결을 위해 로컬 포트를 다시 사용하여 컴퓨터 리소스를 더 잘 사용할 수 있는 새로운 확장성 네트워킹 알고리즘이 포함되어 있습니다. .NET Framework 4.6은 새 알고리즘을 지원하여 .NET 앱이 새 동작을 활용할 수 있도록 합니다. 이전 버전의 Windows에서는 인위적인 동시 연결 제한(일반적으로 동적 포트 범위의 기본 크기인 16,384)이 있었는데, 이는 부하가 있을 때 포트 소모를 발생시켜 서비스의 확장성을 제한할 수 있었습니다.
.NET Framework 4.6에서는 포트 재사용을 활성화하기 위해 두 개의 API가 추가되어 동시 연결에서 64KB 제한을 효과적으로 제거합니다.
System.Net.Sockets.SocketOptionName 열거 값입니다.
기본적으로 ServicePointManager.ReusePort 속성은
false
이며, 이는HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
레지스트리 키의HWRPortReuseOnSocketBind
값을 0x1로 설정하지 않을 경우에만 그렇습니다. HTTP 연결에서 로컬 포트를 다시 사용하도록 설정하려면 ServicePointManager.ReusePort 속성을true
설정합니다. 이로 인해 HttpClient 및 HttpWebRequest의 모든 나가는 TCP 소켓 연결은 로컬 포트 재사용을 가능하게 하는 새 Windows 10 소켓 옵션 SO_REUSE_UNICASTPORT을 사용하게 됩니다.소켓 전용 애플리케이션을 작성하는 개발자는 바인딩하는 동안 아웃바운드 소켓이 로컬 포트를 다시 사용할 수 있도록 Socket.SetSocketOption 같은 메서드를 호출할 때 System.Net.Sockets.SocketOptionName 옵션을 지정할 수 있습니다.
국제 도메인 이름 및 PunyCode에 대한 지원
Windows Forms 컨트롤에서의 크기 조정
이 기능은 .NET Framework 4.6에서 확장되어 DomainUpDown, NumericUpDown, DataGridViewComboBoxColumn, DataGridViewColumn 및 ToolStripSplitButton 형식과 UITypeEditor그릴 때 사용되는 Bounds 속성에 지정된 사각형을 포함합니다.
이는 옵트인 기능입니다. 이를 활성화하려면 애플리케이션 구성(app.config) 파일에서
EnableWindowsFormsHighDpiAutoResizing
요소를true
으로 설정합니다.<appSettings> <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" /> </appSettings>
코드 페이지 인코딩에 대한 지원
.NET Core는 주로 유니코드 인코딩을 지원하며 기본적으로 코드 페이지 인코딩에 대한 제한된 지원을 제공합니다. .NET Framework에서 사용할 수 있지만 코드 페이지 인코딩을 Encoding.RegisterProvider 메서드에 등록하여 .NET Core에서 지원되지 않는 코드 페이지 인코딩에 대한 지원을 추가할 수 있습니다. 자세한 내용은 System.Text.CodePagesEncodingProvider참조하세요.
.NET 네이티브
C# 또는 Visual Basic으로 작성된 UWP(유니버설 Windows 플랫폼) 앱은 IL이 아닌 네이티브 코드로 앱을 컴파일하는 새로운 기술을 활용할 수 있습니다. 이 기술은 시작 및 실행 시간이 더 빠른 앱을 생성합니다. 자세한 내용은 .NET 네이티브로 앱 컴파일을 참조하세요. .NET Native 및 JIT 컴파일, NGEN과의 차이점과 이것이 코드에 미치는 영향을 살펴보는 개요는 .NET 네이티브 및 컴파일을 참조하세요.
앱은 Visual Studio 2015 이상을 사용하여 컴파일할 때 기본적으로 네이티브 코드로 컴파일됩니다. 자세한 내용은 .NET 네이티브 시작하기을 참조하세요.
.NET 네이티브 앱 디버깅을 지원하기 위해 관리되지 않는 디버깅 API에 많은 새 인터페이스와 열거형이 추가되었습니다. 자세한 내용은 디버깅(관리되지 않는 API 참조) 항목을 참조하세요.
오픈 소스 .NET Framework 패키지
변경할 수 없는 컬렉션, SIMD API및 System.Net.Http 네임스페이스에 있는 것과 같은 네트워킹 API와 같은 .NET Core 패키지는 이제 GitHub오픈 소스 패키지로 사용할 수 있습니다. 코드에 액세스하려면 .NET 을(를) GitHub에서 참조하세요. 이러한 패키지에 대한 자세한 정보와 기여 방법은 .NET 소개및 GitHub .NET 홈페이지를 참조하세요.
.NET Framework 4.5.2의 새로운 기능
ASP.NET 앱에 대한 새 API입니다. 새 HttpResponse.AddOnSendingHeaders 및 HttpResponseBase.AddOnSendingHeaders 메서드를 사용하면 응답이 클라이언트 앱으로 플러시될 때 응답 헤더 및 상태 코드를 검사하고 수정할 수 있습니다. PreSendRequestHeaders 및 PreSendRequestContent 이벤트 대신 이러한 메서드를 사용하는 것이 좋습니다. 더 효율적이고 신뢰할 수 있습니다.
HostingEnvironment.QueueBackgroundWorkItem 메서드를 사용하면 작은 백그라운드 작업 항목을 예약할 수 있습니다. ASP.NET 이러한 항목을 추적하고 모든 백그라운드 작업 항목이 완료될 때까지 IIS가 작업자 프로세스를 갑자기 종료하지 못하도록 합니다. 이 메서드는 ASP.NET 관리되는 앱 도메인 외부에서 호출할 수 없습니다.
새 HttpResponse.HeadersWritten 및 HttpResponseBase.HeadersWritten 속성은 응답 헤더가 작성되었는지 여부를 나타내는 부울 값을 반환합니다. 이러한 속성을 사용하여 헤더가 기록된 경우 예외를 throw하는 HttpResponse.StatusCode 같은 API 호출이 성공하도록 할 수 있습니다.
Windows Forms 컨트롤의 크기 조정 이 기능이 확장되었습니다. 이제 시스템 DPI 설정을 사용하여 다음 추가 컨트롤의 구성 요소 크기를 조정할 수 있습니다(예: 콤보 상자의 드롭다운 화살표).
이는 옵트인 기능입니다. 사용하도록 설정하려면 애플리케이션 구성(app.config) 파일에서
EnableWindowsFormsHighDpiAutoResizing
요소를true
로 설정합니다.<appSettings> <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" /> </appSettings>
새 워크플로 기능입니다. EnlistPromotableSinglePhase 메서드(따라서 IPromotableSinglePhaseNotification 인터페이스 구현)를 사용하는 리소스 관리자는 새 Transaction.PromoteAndEnlistDurable 메서드를 사용하여 다음을 요청할 수 있습니다.
트랜잭션을 MSDTC(Microsoft Distributed Transaction Coordinator) 트랜잭션으로 승격합니다.
IPromotableSinglePhaseNotification을 단일 단계 커밋을 지원하는 지속형 인리스트먼트인 ISinglePhaseNotification으로 대체합니다.
이 작업은 동일한 앱 도메인 내에서 수행할 수 있으며, 승격을 수행하기 위해 MSDTC와 상호 작용하기 위해 관리되지 않는 추가 코드가 필요하지 않습니다. System.Transactions에서 승격 가능한 인리스트먼트에서 구현된 IPromotableSinglePhaseNotification
Promote
메서드에 대한 미완료 호출이 있을 때만 새 메서드를 호출할 수 있습니다.프로파일링이 향상되었습니다. 다음과 같은 새로운 관리되지 않는 프로파일링 API는 보다 강력한 프로파일링을 제공합니다.
- COR_PRF_ASSEMBLY_REFERENCE_INFO 구조체
- COR_PRF_HIGH_MONITOR 열거형
- GetAssemblyReferences 메서드
- GetEventMask2 메서드
- SetEventMask2 메서드
- AddAssemblyReference 메서드
이전
ICorProfiler
구현은 종속 어셈블리의 지연 로드를 지원했습니다. 새 프로파일링 API는 앱이 완전히 초기화된 후 로드되는 대신 프로파일러에 의해 삽입된 종속 어셈블리를 즉시 로드할 수 있어야 합니다. 이 변경 내용은 기존ICorProfiler
API의 사용자에게 영향을 주지 않습니다.향상된 디버깅. 다음과 같은 새로운 관리되지 않는 디버깅 API는 프로파일러와 더 나은 통합을 제공합니다. 이제 프로파일러에서 삽입한 메타데이터와 덤프 디버깅 시 컴파일러 ReJIT 요청에 의해 생성된 로컬 변수 및 코드에 액세스할 수 있습니다.
이벤트 추적 변경사항 .NET Framework 4.5.2를 사용하면 더 넓은 표면적에 대해 프로세스 외부에서 ETW(Windows용 이벤트 추적) 기반 작업 추적을 사용할 수 있습니다. 이를 통해 APM(Advanced Power Management) 공급업체는 스레드 간 개별 요청 및 활동의 비용을 정확하게 추적하는 간단한 도구를 제공할 수 있습니다. 이러한 이벤트는 ETW 컨트롤러가 사용하도록 설정하는 경우에만 발생합니다. 따라서 변경 내용은 이전에 작성된 ETW 코드 또는 ETW를 사용하지 않도록 설정된 상태로 실행되는 코드에 영향을 주지 않습니다.
트랜잭션을 촉진하고 지속 가능한 참여로 전환함
Transaction.PromoteAndEnlistDurable .NET Framework 4.5.2 및 4.6에 추가된 새 API입니다.
[System.Security.Permissions.PermissionSetAttribute(System.Security.Permissions.SecurityAction.LinkDemand, Name = "FullTrust")] public Enlistment PromoteAndEnlistDurable(Guid resourceManagerIdentifier, IPromotableSinglePhaseNotification promotableNotification, ISinglePhaseNotification enlistmentNotification, EnlistmentOptions enlistmentOptions)
<System.Security.Permissions.PermissionSetAttribute(System.Security.Permissions.SecurityAction.LinkDemand, Name:="FullTrust")> public Function PromoteAndEnlistDurable(resourceManagerIdentifier As Guid, promotableNotification As IPromotableSinglePhaseNotification, enlistmentNotification As ISinglePhaseNotification, enlistmentOptions As EnlistmentOptions) As Enlistment
메서드는 ITransactionPromoter.Promote 메서드에 대한 응답으로 Transaction.EnlistPromotableSinglePhase에 의해 이전에 생성된 인리스트먼트에서 사용할 수 있습니다.
System.Transactions
에게 트랜잭션을 MSDTC 트랜잭션으로 승격하고 프로모터블 인리스트먼트를 지속 가능한 인리스트먼트로 "변환"하도록 요청합니다. 이 메서드가 성공적으로 완료되면System.Transactions
에 의해 참조되던 IPromotableSinglePhaseNotification 인터페이스는 더 이상 참조되지 않으며, 이후의 모든 알림은 제공된 ISinglePhaseNotification 인터페이스로 도착합니다. 문제의 인리스트먼트는 트랜잭션 로깅 및 복구를 지원하는 지속적인 인리스트먼트 역할을 해야 합니다. 자세한 내용은 Transaction.EnlistDurable 참조하세요. 또한 인리스트먼트는 ISinglePhaseNotification지원해야 합니다. 이 메서드는호출을 처리하는 동안 호출될 수 있습니다. 그렇지 않은 경우에는 TransactionException 예외가 발생합니다.
.NET Framework 4.5.1의 새로운 기능
2014년 4월 업데이트:
Visual Studio 2013 업데이트 2 이러한 시나리오를 지원하기 위한 이식 가능한 클래스 라이브러리 템플릿에 대한 업데이트가 포함되어 있습니다.
Windows 8.1, Windows Phone 8.1 및 Windows Phone Silverlight 8.1을 대상으로 하는 이식 가능한 라이브러리에서 Windows 런타임 API를 사용할 수 있습니다.
Windows 8.1 또는 Windows Phone 8.1을 대상으로 하는 경우 이식 가능한 라이브러리에 XAML(Windows.UI.XAML 형식)을 포함할 수 있습니다. 지원되는 XAML 템플릿은 빈 페이지, 리소스 사전, 템플릿 컨트롤 및 사용자 컨트롤입니다.
Windows 8.1 및 Windows Phone 8.1을 대상으로 하는 스토어 앱에서 사용할 이식 가능한 Windows 런타임 구성 요소(.winmd 파일)를 만들 수 있습니다.
이식 가능한 클래스 라이브러리와 같은 Windows 스토어 또는 Windows Phone 스토어 클래스 라이브러리의 대상을 변경할 수 있습니다.
이러한 변경 내용에 대한 자세한 내용은 이식 가능한 클래스 라이브러리참조하세요.
이제 .NET Framework 콘텐츠 집합에는 Windows 앱을 빌드하고 배포하기 위한 미리 컴파일 기술인 .NET Native에 대한 설명서가 포함되어 있습니다. .NET 네이티브는 성능을 향상하기 위해 IL(중간 언어)이 아닌 네이티브 코드로 직접 앱을 컴파일합니다. 자세한 내용은 .NET 네이티브를 사용하여 앱 컴파일을 참조하세요.
.NET Framework 참조 원본 새로운 검색 환경과 향상된 기능을 제공합니다. 이제 .NET Framework 소스 코드를 온라인으로 탐색하고, 오프라인 보기를 위해 참조를 다운로드하고, 디버깅 중에 소스 코드(패치 및 업데이트 포함)를 단계별로 확인할 수 있습니다. 자세한 내용은 블로그 항목 .NET 참조 원본대한 새 외관을 참조하세요.
.NET Framework 4.5.1의 기본 클래스의 새로운 기능 및 향상된 기능은 다음과 같습니다.
어셈블리에 대한 자동 바인딩 리디렉션입니다. Visual Studio 2013부터 .NET Framework 4.5.1을 대상으로 하는 앱을 컴파일할 때 앱 또는 해당 구성 요소가 동일한 어셈블리의 여러 버전을 참조하는 경우 바인딩 리디렉션이 앱 구성 파일에 추가될 수 있습니다. 이전 버전의 .NET Framework를 대상으로 하는 프로젝트에 대해 이 기능을 사용하도록 설정할 수도 있습니다. 자세한 내용은 방법: 자동 바인딩 리디렉션사용 및 비활성화를 참조하세요.
개발자가 서버 및 클라우드 애플리케이션의 성능을 향상시키는 데 도움이 되는 진단 정보를 수집하는 기능입니다. 자세한 내용은 EventSource 클래스의 WriteEventWithRelatedActivityId 및 WriteEventWithRelatedActivityIdCore 메서드를 참조하세요.
가비지 수집 중에 큰 개체 힙(LOH)을 명시적으로 압축할 수 있는 기능. 자세한 내용은 GCSettings.LargeObjectHeapCompactionMode 속성을 참조하세요.
.NET Framework 업데이트 후 ASP.NET 앱 일시 중단, 다중 코어 JIT 개선 및 빠른 앱 시작과 같은 추가 성능 향상 자세한 내용은 .NET Framework 4.5.1 공지 및 ASP.NET 앱 일시 중단 블로그 게시물을 참조하세요.
Windows Forms의 향상된 기능은 다음과 같습니다.
Windows Forms 컨트롤의 크기 조정 시스템 DPI 설정을 사용하여 앱에 대한 애플리케이션 구성 파일(app.config)의 항목을 옵트인하여 컨트롤 구성 요소(예: 속성 표에 나타나는 아이콘)의 크기를 조정할 수 있습니다. 이 기능은 현재 다음 Windows Forms 컨트롤에서 지원됩니다.
- PropertyGrid
- TreeView
의 몇 가지 측면(추가로 지원되는 컨트롤은 4.5.2의 새 기능 을 참조)
이 기능을 사용하려면 구성 파일(app.config)에 새 <appSettings> 요소를 추가하고
EnableWindowsFormsHighDpiAutoResizing
요소를true
설정합니다.<appSettings> <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" /> </appSettings>
Visual Studio 2013에서 .NET Framework 앱을 디버깅할 때 향상된 기능은 다음과 같습니다.
Visual Studio 디버거에서 값을 반환합니다. Visual Studio 2013에서 관리되는 앱을 디버그하면 자동 창에 메서드에 대한 반환 형식 및 값이 표시됩니다. 이 정보는 데스크톱, Windows 스토어 및 Windows Phone 앱에 사용할 수 있습니다. 자세한 내용은 메서드 호출의 반환 값 검사를 참조하세요.
64비트 앱용 편집 후 계속하기. Visual Studio 2013은 데스크톱, Windows 스토어 및 Windows Phone용 64비트 관리형 앱에 대한 편집 및 계속 기능을 지원합니다. 기존 제한 사항은 32비트 및 64비트 앱 모두에 적용됩니다(지원되는 코드 변경(C#) 문서의 마지막 섹션 참조).
비동기 인식 디버깅. Visual Studio 2013에서 비동기 앱을 더 쉽게 디버그할 수 있도록 호출 스택은 비동기 프로그래밍을 지원하기 위해 컴파일러에서 제공하는 인프라 코드를 숨기고 논리 프로그램 실행을 보다 명확하게 따를 수 있도록 논리적 부모 프레임에 체인을 추가합니다. 작업 창은 병렬 작업 창을 대체하고 특정 중단점과 관련된 작업을 표시하며, 현재 활성 상태이거나 앱에서 예약된 다른 작업도 표시합니다. 이 기능에 대한 내용은 .NET Framework 4.5.1 공지"비동기 인식 디버깅" 섹션에서 확인할 수 있습니다.
Windows 런타임 구성 요소에 대한 더 나은 예외 지원. Windows 8.1에서 Windows 스토어 앱에서 발생하는 예외는 언어 경계를 넘어 예외를 발생시킨 오류에 대한 정보를 유지합니다. 이 기능에 대한 내용은 .NET Framework 4.5.1 공지"Windows 스토어 앱 개발" 섹션에서 확인할 수 있습니다.
Visual Studio 2013부터 관리 프로필 기반 최적화 도구(Mpgo.exe) 사용하여 Windows 8.x 스토어 앱과 데스크톱 앱을 최적화할 수 있습니다.
ASP.NET 4.5.1의 새로운 기능은 ASP.NET 및 Web Tools for Visual Studio 2013 릴리스 정보참조하세요.
.NET Framework 4.5의 새로운 기능
기본 클래스
배포하는 동안 .NET Framework 4 애플리케이션을 검색하고 닫아 시스템 다시 시작을 줄일 수 있습니다. .NET Framework 4.5 설치 동안 시스템 다시 시작 줄이기을 참조하세요.
64비트 플랫폼에서 2GB(기가바이트)보다 큰 배열을 지원합니다. 이 기능은 애플리케이션 구성 파일에서 사용할 수 있습니다. 개체 크기 및 배열 크기에 대한 다른 제한 사항도 나열하는 <gcAllowVeryLargeObjects> 요소참조하세요.
서버에 대한 백그라운드 가비지 수집을 통한 성능 향상 .NET Framework 4.5에서 서버 가비지 수집을 사용하는 경우 백그라운드 가비지 수집이 자동으로 사용하도록 설정됩니다. 가비지 수집 항목의
기본 사항의 백그라운드 서버 가비지 수집 섹션을 참조하세요. 애플리케이션 성능을 향상시키기 위해 다중 코어 프로세서에서 선택적으로 사용할 수 있는 JIT(백그라운드 Just-In-Time) 컴파일입니다. ProfileOptimization을 참조하십시오.
정규식 엔진이 시간이 초과되기 전에 정규식을 확인하려고 시도하는 기간을 제한하는 기능입니다. Regex.MatchTimeout 속성을 참조하세요.
애플리케이션 도메인의 기본 문화권을 정의하는 기능입니다. CultureInfo 클래스를 참조하세요.
유니코드(UTF-16) 인코딩에 대한 콘솔 지원. Console 클래스를 참조하세요.
문화권 문자열 순서 지정 및 비교 데이터의 버전 관리 지원 SortVersion 클래스를 참조하세요.
리소스를 검색할 때 성능이 향상됩니다. 패키지 및리소스 배포를 참조하세요.
압축된 파일의 크기를 줄이기 위해 Zip 압축이 개선되었습니다. System.IO.Compression 네임스페이스를 참조하세요.
리플렉션 컨텍스트를 사용자 지정하여 CustomReflectionContext 클래스를 통해 기본 리플렉션 동작을 재정의하는 기능입니다.
Windows 8에서 System.Globalization.IdnMapping 클래스를 사용하는 경우 2008 버전의 IDNA(Internationalized Domain Names in Applications) 표준을 지원합니다.
Windows 8에서 .NET Framework를 사용하는 경우 유니코드 6.0을 구현하는 운영 체제에 대한 문자열 비교 위임입니다. 다른 플랫폼에서 실행하는 경우 .NET Framework에는 유니코드 5.x를 구현하는 자체 문자열 비교 데이터가 포함됩니다. String 클래스와 SortVersion 클래스의 비고 섹션을 참조하세요.
애플리케이션 도메인별로 문자열에 대한 해시 코드를 계산하는 기능입니다. 참조하세요 <UseRandomizedStringHashAlgorithm> 요소.
Type 및 TypeInfo 클래스 간에 형식 리플렉션 지원이 분할됩니다. Windows 스토어 앱용 .NET Framework
리플렉션을 참조하세요.
MEF(관리 확장성 프레임워크)
.NET Framework 4.5에서 MEF(Managed Extensibility Framework)는 다음과 같은 새로운 기능을 제공합니다.
제네릭 형식을 지원합니다.
특성이 아닌 명명 규칙에 따라 파트를 만들 수 있는 규칙 기반 프로그래밍 모델입니다.
여러 범위.
Windows 8.x 스토어 앱을 만들 때 사용할 수 있는 MEF의 하위 집합입니다. 이 하위 집합은 NuGet 갤러리에서 다운로드 가능한 패키지 사용할 수 있습니다. 패키지를 설치하려면 Visual Studio에서 프로젝트를 열고,
프로젝트 메뉴에서 NuGet 패키지 관리선택하고, 패키지를 온라인으로 검색합니다.
자세한 내용은 MEF(Managed Extensibility Framework)참조하세요.
비동기 파일 작업
.NET Framework 4.5에서는 새로운 비동기 기능이 C# 및 Visual Basic 언어에 추가되었습니다. 이러한 기능은 비동기 작업을 수행하기 위한 작업 기반 모델을 추가합니다. 이 새 모델을 사용하려면 I/O 클래스에서 비동기 메서드를 사용합니다. 비동기 파일 I/O를 참조하세요.
도구
.NET Framework 4.5에서 리소스 파일 생성기(Resgen.exe)를 사용하면 .NET Framework 어셈블리에 포함된 .resources 파일에서 Windows 8.x 스토어 앱에서 사용할 .resw 파일을 만들 수 있습니다. 자세한 내용은 Resgen.exe(리소스 파일 생성기)참조하세요.
관리 프로필 기반 최적화(Mpgo.exe)를 사용하면 네이티브 이미지 어셈블리를 최적화하여 애플리케이션 시작 시간, 메모리 사용률(작업 집합 크기) 및 처리량을 향상시킬 수 있습니다. 명령줄 도구는 네이티브 이미지 애플리케이션 어셈블리에 대한 프로필 데이터를 생성합니다. Mpgo.exe(관리 프로필 기반 최적화 도구)참조하세요. Visual Studio 2013부터 Mpgo.exe 사용하여 데스크톱 앱뿐만 아니라 Windows 8.x 스토어 앱을 최적화할 수 있습니다.
병렬 컴퓨팅
.NET Framework 4.5는 병렬 컴퓨팅을 위한 몇 가지 새로운 기능과 향상된 기능을 제공합니다. 여기에는 향상된 성능, 향상된 제어, 비동기 프로그래밍에 대한 향상된 지원, 새 데이터 흐름 라이브러리, 병렬 디버깅 및 성능 분석에 대한 향상된 지원이 포함됩니다. .NET을 사용한 병렬 프로그래밍 블로그의 .NET Framework 4.5 병렬 처리를 위한 새로운 기능
웹
ASP.NET 4.5 및 4.5.1에서는 Web Forms, WebSocket 지원, 비동기 처리기, 성능 향상 및 기타 여러 기능에 대한 모델 바인딩을 추가합니다. 자세한 내용은 다음 리소스를 참조하세요.
네트워킹
.NET Framework 4.5는 HTTP 애플리케이션에 대한 새로운 프로그래밍 인터페이스를 제공합니다. 자세한 내용은 새 System.Net.Http 및 System.Net.Http.Headers 네임스페이스를 참조하세요.
기존 HttpListener 및 관련 클래스를 사용하여 WebSocket 연결을 수락하고 상호 작용하기 위한 새로운 프로그래밍 인터페이스에 대한 지원도 포함됩니다. 자세한 내용은 새 System.Net.WebSockets 네임스페이스 및 HttpListener 클래스를 참조하세요.
또한 .NET Framework 4.5에는 다음과 같은 네트워킹 개선 사항이 포함되어 있습니다.
RFC 규격 URI 지원. 자세한 내용은 Uri 및 관련 클래스를 참조하세요.
국제화 도메인 이름 (IDN) 구문 분석 지원 자세한 내용은 Uri 및 관련 클래스를 참조하세요.
EAI(전자 메일 주소 국제화) 지원. 자세한 내용은 System.Net.Mail 네임스페이스를 참조하세요.
향상된 IPv6 지원. 자세한 내용은 System.Net.NetworkInformation 네임스페이스를 참조하세요.
듀얼 모드 소켓 지원. 자세한 내용은 Socket 및 TcpListener 클래스를 참조하세요.
WPF(Windows Presentation Foundation)
.NET Framework 4.5에서 WPF(Windows Presentation Foundation)에는 다음 영역의 변경 내용 및 개선 사항이 포함되어 있습니다.
새 Ribbon 컨트롤을 사용하면 빠른 실행 도구 모음, 애플리케이션 메뉴 및 탭을 호스트하는 리본 사용자 인터페이스를 구현할 수 있습니다.
동기 및 비동기 데이터 유효성 검사를 지원하는 새 INotifyDataErrorInfo 인터페이스입니다.
VirtualizingPanel 및 Dispatcher 클래스의 새로운 기능입니다.
그룹화된 큰 데이터 집합을 표시하고 UI가 아닌 스레드의 컬렉션에 액세스할 때 성능이 향상되었습니다.
정적 속성에 대한 데이터 바인딩, ICustomTypeProvider 인터페이스를 구현하는 사용자 지정 형식에 대한 데이터 바인딩 및 바인딩 식에서 데이터 바인딩 정보 검색
값이 변경되면 데이터의 위치를 변경합니다(라이브 셰이핑).
항목 컨테이너에 대한 데이터 컨텍스트의 연결이 끊어지는지 여부를 확인하는 기능입니다.
속성 변경 내용과 데이터 원본 업데이트 사이에 경과해야 하는 시간을 설정하는 기능입니다.
약한 이벤트 패턴 구현에 대한 지원이 향상되었습니다. 또한 이제 이벤트는 마크업 확장을 수락할 수 있습니다.
WCF(Windows Communication Foundation)
.NET Framework 4.5에서는 WCF(Windows Communication Foundation) 애플리케이션을 더 간단하게 작성하고 유지 관리할 수 있도록 다음과 같은 기능이 추가되었습니다.
생성된 구성 파일의 단순화입니다.
계약 우선 개발 지원.
ASP.NET 호환 모드를 보다 쉽게 구성할 수 있습니다.
기본 전송 속성 값을 변경하여 설정해야 할 가능성을 줄입니다.
XML 사전 판독기 할당량을 수동으로 구성해야 할 가능성을 줄이기 위해 XmlDictionaryReaderQuotas 클래스를 업데이트합니다.
애플리케이션을 실행하기 전에 구성 오류를 감지할 수 있도록 빌드 프로세스의 일부로 Visual Studio에서 WCF 구성 파일의 유효성을 검사합니다.
새로운 비동기 스트리밍 지원.
IIS(인터넷 정보 서비스)를 사용하여 HTTPS를 통해 엔드포인트를 더 쉽게 노출할 수 있도록 하는 새로운 HTTPS 프로토콜 매핑입니다.
서비스 URL에
?singleWSDL
추가하여 단일 WSDL 문서에서 메타데이터를 생성하는 기능입니다.Websockets는 TCP 전송과 유사한 성능 특성을 가진 포트 80 및 443을 통해 진정한 양방향 통신을 사용하도록 지원합니다.
코드에서 서비스 구성을 지원합니다.
XML 편집기 도구 설명입니다.
ChannelFactory 캐싱 지원.
이진 인코더 압축 지원.
개발자가 "fire and forget" 메시징을 사용하는 서비스를 작성할 수 있도록 하는 UDP 전송을 지원합니다. 클라이언트는 서비스에 메시지를 보내고 서비스에서 응답을 기대하지 않습니다.
HTTP 전송 및 전송 보안을 사용할 때 단일 WCF 엔드포인트에서 여러 인증 모드를 지원하는 기능.
IDN(국제화된 도메인 이름)을 사용하는 WCF 서비스를 지원합니다.
자세한 내용은 Windows Communication Foundation의 새로운 기능을 참조하세요.
WF(Windows Workflow Foundation)
.NET Framework 4.5에서는 다음을 비롯한 몇 가지 새로운 기능이 Windows WF(Workflow Foundation)에 추가되었습니다.
.NET Framework 4.0.1(.NET Framework 4 플랫폼 업데이트 1)의 일부로 처음 도입된 상태 컴퓨터 워크플로입니다. 이 업데이트에는 개발자가 상태 시스템 워크플로를 만들 수 있는 몇 가지 새로운 클래스 및 활동이 포함되어 있습니다. .NET Framework 4.5에서 다음을 포함하도록 이러한 클래스 및 활동이 업데이트되었습니다.
상태에 중단점을 설정하는 기능입니다.
워크플로 디자이너에서 전환을 복사하고 붙여넣는 기능입니다.
공유 트리거 전환 만들기에 대한 디자이너 지원.
StateMachine, State및 Transition를 포함하여 상태 머신 워크플로를 만들기 위한 활동입니다.
다음과 같은 향상된 워크플로 디자이너 기능:
빠른 찾기 및 파일
찾기를 포함하여 Visual Studio의 향상된 워크플로 검색 기능. 두 번째 자식 활동이 컨테이너 활동에 추가될 때, 시퀀스 활동을 자동으로 생성하고 두 활동 모두를 시퀀스 활동에 포함하는 기능입니다.
이동 지원- 스크롤 막대를 사용하지 않고 워크플로의 표시 부분을 변경할 수 있습니다.
트리 스타일 개요 보기에서 워크플로의 구성 요소를 표시하고 문서 개요 보기에서 구성 요소를 선택할 수 있는 새 문서 개요 보기입니다.
활동에 주석을 추가하는 기능입니다.
워크플로 디자이너를 사용하여 활동 위임자를 정의하고 사용하는 기능입니다.
상태 컴퓨터 및 순서도 워크플로의 활동 및 전환에 대한 자동 연결 및 자동 삽입
XAML 파일의 단일 요소에 있는 워크플로에 대한 뷰 상태 정보를 저장하므로 보기 상태 정보를 쉽게 찾아 편집할 수 있습니다.
NoPersistScope 컨테이너 활동을 통해 자식 활동이 지속되지 않도록 합니다.
C# 식 지원:
Visual Basic을 사용하는 워크플로 프로젝트는 Visual Basic 식을 사용하고 C# 워크플로 프로젝트는 C# 식을 사용합니다.
Visual Studio 2010에서 만들어졌으며 Visual Basic 식이 있는 C# 워크플로 프로젝트는 C# 식을 사용하는 C# 워크플로 프로젝트와 호환됩니다.
버전 관리 개선 사항:
지속형 워크플로 인스턴스와 해당 워크플로 정의 간의 매핑을 제공하는 새 WorkflowIdentity 클래스입니다.
WorkflowServiceHost포함하여 동일한 호스트에서 여러 워크플로 버전을 병렬로 실행합니다.
동적 업데이트에서 지속형 워크플로 인스턴스의 정의를 수정하는 기능입니다.
기존 서비스 계약과 일치하는 활동을 자동으로 생성하는 지원을 제공하는 계약 우선 워크플로 서비스 개발입니다.
자세한 내용은 Windows Workflow Foundation의 새로운 기능을 참조하세요.
Windows 8.x 스토어 애플리케이션용 .NET
Windows 8.x 스토어 앱은 특정 폼 팩터를 위해 설계되었으며 Windows 운영 체제의 기능을 활용합니다. .NET Framework 4.5 또는 4.5.1 하위 집합은 C# 또는 Visual Basic을 사용하여 Windows용 Windows 8.x 스토어 앱을 빌드하는 데 사용할 수 있습니다. 이 하위 집합은 Windows 8.x 스토어 앱용 .NET이라고 하며 개요에서 다룹니다.
이식 가능한 클래스 라이브러리
Visual Studio 2012 이상 버전의 이식 가능한 클래스 라이브러리 프로젝트를 사용하면 여러 .NET Framework 플랫폼에서 작동하는 관리형 어셈블리를 작성하고 빌드할 수 있습니다. 이식 가능한 클래스 라이브러리 프로젝트를 사용하여 대상으로 지정할 플랫폼(예: Windows Phone 및 Windows 8.x 스토어 앱용 .NET)을 선택합니다. 프로젝트에서 사용 가능한 형식 및 멤버는 이러한 플랫폼에서 공통 형식 및 멤버로 자동으로 제한됩니다. 자세한 내용은 이식 가능한 클래스 라이브러리을 참조하세요.
다음도 참조하십시오
- .NET Framework 및 대역 외 릴리스
- .NET Framework 접근성의 새로운 개선 사항
- Visual Studio 2019의 새로운 기능
- ASP.NET
- Visual Studio의 C++에서의 새로운 기능
- .NET SDK 다운로드
.NET