次の方法で共有

.NET Framework の新機能

  • [アーティクル]

Note

.NET Framework 4.8 は、.NET Framework の最新バージョンです。 .NET Framework は、セキュリティと信頼性に関するバグを修正して、毎月サービスが提供されます。 .NET Framework は Windows に引き続き含まれ、削除される予定はありません。 お使いの .NET Framework アプリは移行する必要はありませんが、新規開発においては .NET 5 以降をご利用ください。

この記事では、.NET Framework の次のバージョンにおける主な新機能と機能強化の概要を示します。

この記事は、各新機能の包括的な情報を説明するものではありません。また、この内容は変更される可能性があります。 .NET Framework の概要については、「.NET Framework の概要」をご覧ください。 サポートされているプラットフォームについては、「.NET Framework システム要件」を参照してください。 ダウンロード リンクとインストール手順については、「.NET Framework のインストール」を参照してください。

Note

また .NET Framework チームでは、プラットフォームのサポートの拡張と、新機能 (変更できないコレクションや SIMD 対応ベクター型など) を OOB で NuGet を使用してリリースしています。 詳細については、「追加のクラス ライブラリと API」および「.NET Framework および特別なリリース」を参照してください。 .NET Framework 用の NuGet パッケージの完全な一覧を参照してください。

.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 は、Web インストーラーまたはオフライン インストーラーを使用してインストールできます。 ほとんどのユーザーにお勧めする方法は、Web インストーラーの使用です。

.NET Framework 4.8 Developer Pack をインストールすれば、Visual Studio 2012 以降で、.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 (Federal Information Processing Standards) 140-2 の認定を受けていないためです。 開発用コンピューターを FIPS モードにしている開発者はほとんどいないため、例外は一般に運用システムでスローされます。

.NET Framework 4.8 を対象とするアプリケーションの既定の設定では、この場合に次のマネージド暗号化クラスで CryptographicException がスローされることはなくなりました。

代わりに、これらのクラスでは、暗号化操作はシステムの暗号化ライブラリにリダイレクトされます。 この変更により、開発者環境と運用環境での混乱を招く可能性のある違いは実質的になくなり、ネイティブ コンポーネントとマネージド コンポーネントは同じ暗号化ポリシーの下で動作するようになります。 これらの例外に依存するアプリケーションでは、AppContext スイッチ Switch.System.Security.Cryptography.UseLegacyFipsThrow を true に設定することで、以前の動作に戻すことができます。 詳しくは、「Managed cryptography classes do not throw a CryptographyException in FIPS mode (FIPS モードのマネージド暗号クラスで CryptographyException がスローされない)」をご覧ください。

ZLib の更新バージョンの使用

.NET Framework 4.5 以降の clrcompression.dll アセンブリでは、deflate アルゴリズムの実装を提供するため、データ圧縮用のネイティブ外部ライブラリである ZLib が使われています。 .NET Framework 4.8 バージョンの clrcompression.dll は、いくつかの重要な機能強化と修正を含む ZLib バージョン 1.2.11 を使用するように更新されています。

Windows Communication Foundation (WCF)

ServiceHealthBehavior の導入

正常性エンドポイントは、正常性の状態に基づいてサービスを管理するため、オーケストレーション ツールで広く使用されています。 正常性チェックは、サービスの可用性とパフォーマンスを追跡して通知を提供するため、監視ツールでも使用できます。

ServiceHealthBehavior は、IServiceBehavior を拡張する WCF サービスの動作です。 ServiceDescription.Behaviors コレクションに追加すると、サービスの動作は次のようになります。

  • HTTP 応答コードでサービスの正常性状態が返されます。 HTTP/GET 正常性プローブ要求に対する HTTP 状態コードを、クエリ文字列で指定できます。

  • サービスの正常性に関する情報が公開されます。 サービスの状態、スロットルの数、容量などのサービス固有の詳細を、?health クエリ文字列を含む HTTP/GET 要求を使用して表示できます。 動作がおかしい WCF サービスのトラブルシューティングを行うときは、このような情報に簡単にアクセスできることが重要です。

正常性エンドポイントを公開し、WCF サービスの正常性情報を公開するには、2 つの方法があります。

  • コードの使用。 次に例を示します。

    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 応答コードが既定で使われます。 次に例を示します。

クエリ パラメーターと例:

  • OnDispatcherFailure: https://contoso:81/Service1?health&OnDispatcherFailure=455

    いずれかのチャネル ディスパッチャーの状態が CommunicationState.Opened より大きい場合、455 HTTP 応答状態コードが返されます。

  • OnListenerFailure: https://contoso:81/Service1?health&OnListenerFailure=465

    いずれかのチャネル リスナーの状態が CommunicationState.Opened より大きい場合、465 HTTP 応答状態コードが返されます。

  • OnThrottlePercentExceeded: https://contoso:81/Service1?health&OnThrottlePercentExceeded= 70:350,95:500

    応答をトリガーする割合 {1 – 100} とその HTTP 応答コード {200 – 599} を指定します。 この例では、次のように記述されています。

    • 割合が 95 より大きい場合、500 HTTP 応答コードが返されます。

    • 割合が 70 から 95 の場合は、350 が返されます。

    • それ以外の場合は、200 が返されます。

サービスの正常性状態は、HTML (https://contoso:81/Service1?health のようなクエリ文字列を指定) または XML (https://contoso:81/Service1?health&Xml のようなクエリ文字列を指定) で表示できます。 https://contoso:81/Service1?health&NoContent のようなクエリ文字列では、空の HTML ページが返されます。

Windows Presentation Foundation (WPF)

高 DPI の機能強化

.NET Framework 4.8 では、WPF でモニターごとの V2 DPI の認識および混合モードの DPI スケーリングのサポートが追加されています。 高 DPI の開発に関する追加情報については、「High DPI Desktop Application Development on Windows (Windows での高 DPI デスクトップ アプリケーション開発)」をご覧ください。

.NET framework 4.8 では、混合モードの DPI スケーリングをサポートするプラットフォーム上の高 DPI WPF アプリケーションでのホステッド HWND と Windows フォームの相互運用のためのサポートが向上しています (Windows 10 April 2018 Update 以降)。 SetThreadDpiHostingBehavior および SetThreadDpiAwarenessContext を呼び出すことによって、ホステッド HWND または Windows フォームのコントロールを混合モードの DPI スケーリングされたウィンドウとして作成すると、それらはモニターごとの V2 WPF アプリケーション内でホストでき、適切にサイズ設定およびスケーリングされます。 そのようなホステッド コンテンツは、ネイティブ DPI ではレンダリングされず、代わりにオペレーティング システムによって適切なサイズにスケーリングされます。 モニターごとの v2 DPI 認識モードのサポートにより、高 DPI アプリケーションのネイティブ ウィンドウで WPF コントロールをホストする (つまり、子にする) こともできます。

混合モードの高 DPI スケーリングのサポートを有効にするには、アプリケーション構成ファイルで次の AppContext スイッチを設定します。

<runtime>
   <AppContextSwitchOverrides value = "Switch.System.Windows.DoNotScaleForDpiChanges=false; Switch.System.Windows.DoNotUsePresentationDpiCapabilityTier2OrGreater=false"/>
</runtime>

共通言語ランタイム

NET Framework 4.8 のランタイムには、次の変更と強化が含まれます。

JIT コンパイラの機能強化。 .NET Framework 4.8 の Just-In-Time (JIT) コンパイラは、.NET Core 2.1 の JIT コンパイラが基になっていいます。 .NET Core 2.1 の JIT コンパイラに対して行われた最適化の多くとすべてのバグ修正が、.NET Framework 4.8 の JIT コンパイラに含まれます。

NGEN の機能強化。 ランタイムでは、ネイティブ イメージ ジェネレーター (NGEN) のイメージに対するメモリ管理が改善され、NGEN イメージからマップされているデータがメモリに常駐しないようになっています。 これにより、実行されるメモリを変更することによって任意のコードを実行しようとする攻撃に利用可能な領域が減ります。

すべてのアセンブリに対するマルウェア対策スキャン。 以前のバージョンの .NET Framework のランタイムでは、Windows Defender またはサード パーティのマルウェア対策ソフトウェアを使用して、ディスクから読み込まれたすべてのアセンブリがスキャンされます。 しかし、Assembly.Load(Byte[]) メソッドなどの他のソースから読み込まれたアセンブリはスキャンされず、検出されていないマルウェアが含まれる可能性があります。 Windows 10 で実行される .NET Framework 4.8 以降のランタイムでは、Antimalware Scan Interface (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 クラスには、3 つの新しいコンストラクターがあり、キーを派生するときに使用する 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 ブログの「Programmatic creation of PKCS#10 certification signing requests and X.509 public key certificates」(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 でいくつかの新しい API が SortedSet<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 フォームでの依存関係挿入のサポート

依存性挿入 (DI) は、オブジェクトとその依存関係を分離し、依存関係の変更だけを理由としてオブジェクトのコードを変更する必要がないようにします。 .NET Framework 4.7.2 を対象とする ASP.NET アプリケーションを開発するときに次のことができます。

同じサイトの cookie のサポート

SameSite は、ブラウザーがサイト間の要求と共に cookie を送信するのを防ぎます。 .NET Framework 4.7.2 では、System.Web.SameSiteMode 列挙型のメンバーの値を持つ HttpCookie.SameSite プロパティが追加されました。 値が SameSiteMode.Strict または SameSiteMode.Lax の場合、ASP.NET は SameSite 属性を set-cookie ヘッダーに追加します。 SameSite のサポートは、HttpCookie オブジェクト、および FormsAuthentication と System.Web.SessionState cookie に適用されます。

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 cookie を構成することもできます。

<system.web>
   <httpCookies sameSite="Strict" />
</system.web>

web config ファイルを変更することによって、FormsAuthentication および System.Web.SessionState cookie の SameSite を追加することができます。

<system.web>
   <authentication mode="Forms">
      <forms cookieSameSite="Lax">
         <!-- ...   -->
      </forms>
   </authentication>
   <sessionState cookieSameSite="Lax"></sessionState>
</system.web>

ネットワーキング

HttpClientHandler プロパティの実装

.NET Framework 4.7.1 で 8 個のプロパティが、System.Net.Http.HttpClientHandler クラスに追加されました。 ただし、2 つは PlatformNotSupportedException をスローしていました。 .NET Framework 4.7.2 では、それらのプロパティの実装が提供されるようになりました。 次のプロパティです。

SQLClient

Azure Active Directory のユニバーサル認証と多要素認証のサポート

コンプライアンスとセキュリティのニーズが高まったために、多くのお客様が多要素認証 (MFA) を使用しています。 さらに、現在のベスト プラクティスでは、接続文字列内に直接ユーザーのパスワードを含めることは推奨されません。 これらの変更をサポートするため、.NET Framework 4.7.2 では SQLClient 接続文字列が拡張され、MFA および Azure AD Authentication をサポートするための既存の "Authentication" キーワードに新しい値 "Active Directory Interactive" が追加されています。 新しい対話型メソッドでは、ネイティブおよびフェデレーションの Azure AD ユーザーだけでなく Azure AD ゲスト ユーザーをサポートします。 このメソッドを使用する場合は、Azure AD によって課される MFA 認証が SQL データベースに対してサポートされます。 さらに、認証プロセスは、セキュリティのベスト プラクティスに準拠するためにユーザーのパスワードを要求します。

以前のバージョンの .NET Framework では、SQL 接続は、SqlAuthenticationMethod.ActiveDirectoryPassword と SqlAuthenticationMethod.ActiveDirectoryIntegrated のオプションのみがサポートされていました。 これらはどちらも非対話型の ADAL プロトコル の一部で、MFA はサポートされていません。 新しい SqlAuthenticationMethod.ActiveDirectoryInteractive オプションを使用して、SQL 接続は MFA および既存の認証方法 (パスワードや統合認証) をサポートします。これにより、ユーザーが接続文字列でパスワードを永続化せずに、対話形式でパスワードを入力することができます。

詳細および例については、.NET ブログの「SQL -- Azure AD Universal and Multi-factor Authentication Support」(SQL--Azure AD ユニバーサルおよび多要素認証のサポート) を参照してください。

Always Encrypted バージョン 2 のサポート

NET Framework 4.7.2 では、エンクレーブ ベースの Always Encrypted のサポートが追加されました。 Always Encrypted の元のバージョンは、暗号化キーがクライアントから離れないクライアント側暗号化テクノロジです。 エンクレーブ ベースの Always Encrypted では、クライアントが、オプションで暗号化キーをセキュアなエンクレーブに送信することができます。エンクレーブは、SQL Server の一部と見なされても SQL Server のコードを改ざんできないセキュアなコンピューティング エンティティです。 エンクレーブ ベースの Always Encrypted をサポートするために、.NET Framework 4.7.2 では、次の型とメンバーが System.Data.SqlClient 名前空間に追加されています。

アプリケーション構成ファイルで、エンクレーブ プロバイダーの機能を提供する抽象 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>

エンクレーブ ベースの Always Encrypted の基本的な流れを示します。

  1. ユーザーが、エンクレーブ ベースの Always Encrypted をサポートしていた SQL Server への AlwaysEncrypted 接続を作成します。 ドライバーが、構成証明サービスにアクセスし、正しいエンクレーブに接続されていることを確認します。

  2. エンクレーブが証明されると、ドライバーが、SQL Server でホストされているセキュリティで保護されたエンクレーブとのセキュリティで保護されたチャネルを確立します。

  3. ドライバーは、SQL 接続の間にセキュリティで保護されたエンクレーブとクライアントによって承認された暗号化キーを共有します。

Windows Presentation Foundation

ソースによる ResourceDictionaries の検索

.NET Framework 4.7.2 以降、特定のソース URI から作成された ResourceDictionaries を診断アシスタントが検出できるようになりました。  (この機能は、実稼働アプリケーションではなく診断アシスタントによって使用されます)。Visual Studio の "エディット コンティニュ" 機能などの診断アシスタントでは、ユーザーが、実行中のアプリケーションに変更を適用する目的で ResourceDictionary を編集できます。 これを実現するための 1 つの手順は、実行中のアプリケーションが編集されているディクショナリから作成したすべての 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 プロパティを使用して間接的に) 参照しているすべてのオブジェクトを見つけます。 System.Windows.Diagnostics.ResourceDictionaryDiagnostics クラスに実装された 3 つの新しい静的メソッドは、Resources プロパティを持つ各基本データ型ごとに 1 つずつあり、次の手順をサポートします。

これらのメソッドは、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

ClickOnce を使用して、Windows フォームの HDPI 対応アプリケーション、Windows Presentation Foundation (WPF)、および Visual Studio Tools for Office (VSTO) のすべてを配置できます。 次のエントリがアプリケーション マニフェストに見つかった場合、.NET Framework 4.7.2 で展開が成功します。

<windowsSettings>
   <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>

Windows フォーム アプリケーションの場合、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 Runtime and Compiler Features」(.NET Framework 4.7.1 ランタイムとコンパイラの機能) ブログ投稿の「BCL - .NET Standard 2.0 Support」(BCL - .NET Standard 2.0 のサポート) を参照してください。

構成ビルダーのサポート

構成ビルダーを使用して、開発者が、実行時にアプリケーションの構成設定を動的に注入およびビルドすることができます。 カスタム構成ビルダーを使用して、構成セクションの既存のデータを変更したり、最初から完全に構成セクション全体をビルドしたりすることができます。 構成ビルダーを使用しない場合は、構成ファイルは静的であり、それらの設定はアプリケーションが起動されるしばらく前に定義されます。

カスタム構成ビルダーを作成するには、抽象 ConfigurationBuilder クラスからビルダーを派生させ、その ConfigurationBuilder.ProcessConfigurationSection と ConfigurationBuilder.ProcessRawXml をオーバーライドします。 また、.config ファイルでもビルダーを定義します。 詳細については、「.NET Framework 4.7.1 ASP.NET and Configuration Features 」(.NET Framework 4.7.1 ASP.NET と構成機能) ブログ投稿の「Configuration Builders」(構成ビルダー) セクションを参照してください。

実行時の機能の検出

System.Runtime.CompilerServices.RuntimeFeature クラスは、コンパイル時または実行時に特定の .NET の実装上で事前に定義された機能がサポートされているかどうかを判断するためのメカニズムを提供します。 コンパイラは、コンパイル時に、指定されたフィールドが存在するかどうかを確認し、その機能がサポートされているかどうかを判断します。サポートされている場合は、その機能を利用するコードを生成できます。 実行時に、アプリケーションは、コードを生成する前に RuntimeFeature.IsSupported メソッドを呼び出すことができます。 詳細については、「Add helper method to describe features supported by the runtime」(ランタイムでサポートされる機能を記述するヘルパー メソッドを追加する) を参照してください。

値のタプル型はシリアル化できる

.NET Framework 4.7.1 以降、System.ValueTuple および関連するジェネリック型は、Serializable としてマークされ、バイナリのシリアル化ができるようになりました。 これにより、Tuple<T1,T2,T3> や Tuple<T1,T2,T3,T4> などのタプル型を簡単に値のタプル型に移行できます。 詳細については、「.NET Framework 4.7.1 Runtime and Compiler Features」(.NET Framework 4.7.1 ランタイムとコンパイラの機能) ブログ投稿の「Compiler -- ValueTuple is Serializable」(コンパイラ -- 値タプルはシリアル化できる) を参照してください。

読み取り専用の参照のサポート

.NET Framework 4.7.1 では、System.Runtime.CompilerServices.IsReadOnlyAttribute が追加されました。 この属性は、読み取り専用の ref 戻り値型またはパラメーターを持つメンバーをマークする言語コンパイラで使用します。 詳細については、「.NET Framework 4.7.1 Runtime and Compiler Features」(.NET Framework 4.7.1 ランタイムとコンパイラの機能) ブログ投稿の「Compiler - Support for ReadOnlyReferences」(コンパイラ - ReadOnlyReferences のサポート) を参照してください。 参照戻り値の詳細については、参照戻り値と参照ローカル変数 (C# Guide)および参照戻り値 (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 Runtime and Compiler Features」(.NET Framework 4.7.1 ランタイムとコンパイラの機能) ブログ投稿の「Runtime -- GC Performance Improvements」(ランタイム - GC のパフォーマンスの向上) セクションを参照してください。

ネットワーキング

Message.HashAlgorithm 用の SHA-2 のサポート

.NET Framework 4.7 およびそれ以前のバージョンの Message.HashAlgorithm プロパティでは、値 HashAlgorithm.Md5 および HashAlgorithm.Sha のみがサポートされていました。 .NET Framework 4.7.1 以降では、HashAlgorithm.Sha256、HashAlgorithm.Sha384、HashAlgorithm.Sha512 もサポートされます。 Message インスタンス自体は、ハッシュは行わず、MSMQ に値を渡すだけですなので、この値が実際に使用されるかどうかは MSMQ によって異なります。 詳細については、「.NET Framework 4.7.1 ASP.NET and Configuration Features 」(.NET Framework 4.7.1 ASP.NET と構成機能) ブログ投稿の「SHA-2 support for Message.HashAlgorithm」(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 and Configuration Features 」(.NET Framework 4.7.1 ASP.NET と構成機能) ブログ投稿の「ASP.NET Execution Step Feature」(ASP.NET 実行ステップの機能) を参照してください。

ASP.NET HttpCookie 解析

.NET Framework 4.7.1 には、新しいメソッド HttpCookie.TryParse が含まれています。これは、文字列から HttpCookie オブジェクトを作成し、有効期限日やパスなどの cookie の値を正確に割り当てるための標準化された方法を提供します。 詳細については、「.NET Framework 4.7.1 ASP.NET and Configuration Features 」(.NET Framework 4.7.1 ASP.NET と構成機能) ブログ投稿の「ASP.NET HttpCookie parsing」(ASP.NET HttpCookie の解析) を参照してください。

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 は既定のまま残り、Web 構成ファイルで既定以外のハッシュ アルゴリズムを定義することができます。 次に例を示します。

<system.web>
    <authentication mode="Forms">
        <forms loginUrl="~/login.aspx">
          <credentials passwordFormat="SHA512">
            <user name="jdoe" password="6D003E98EA1C7F04ABF8FCB375388907B7F3EE06F278DB966BE960E7CBBD103DF30CA6D61F7E7FD981B2E4E3A64D43C836A4BEDCA165C33B163E6BCDC538A664" />
          </credentials>
        </forms>
    </authentication>
</system.web>

.NET Framework 4.7 の新機能

.NET Framework 4.7 には、次の領域における新機能が含まれています。

.NET Framework 4.7 に追加された新しい API の一覧については、GitHub で .NET Framework 4.7 API の変更点に関するページをご覧ください。 .NET Framework 4.7 における機能の改善とバグ修正の一覧については、GitHub で「.NET Framework 4.7 List of Changes (.NET Framework 4.7 の変更点の一覧)」を参照してください。 詳細については、.NET のブログの .NET Framework 4.7 の発表に関するページを参照してください。

基底クラス

.NET Framework 4.7 では、DataContractJsonSerializer によるシリアル化が改善されています。

楕円曲線暗号 (ECC) による機能強化*

.NET Framework 4.7 では、ImportParameters(ECParameters) メソッドが ECDsa クラスと ECDiffieHellman クラスに追加され、既に確立されたキーをオブジェクトで表すことができるようになりました。 明示的な曲線パラメーターを使ってキーをエクスポートするための 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 プロトコルの既定のオペレーティング システム サポート*

System.Net.Security.SslStream および HTTP、FTP、SMTP などの上位スタック コンポーネントによって使われる TLS スタックにより、開発者はオペレーティング システムによってサポートされる既定の TLS プロトコルを使うことができます。 TLS バージョンをハード コーディングする必要はなくなりました。

ASP.NET

.NET Framework 4.7 の ASP.NET には、次の新機能が含まれます。

オブジェクト キャッシュの拡張性

.NET Framework 4.7 以降では、ASP.NET で追加された新しい API セットを使うことで、開発者は、メモリ内オブジェクト キャッシュとメモリ監視に関する既定の ASP.NET の実装を置き換えることができます。 ASP.NET の実装が適切ではない場合、次の 3 つのコンポーネントを置き換えることができるようになりました。

  • オブジェクト キャッシュ ストア。 新しいキャッシュ プロバイダー構成セクションを使うことで、開発者は、新しい ICacheStoreProvider インターフェイスを使って、ASP.NET アプリケーション用のオブジェクト キャッシュの新しい実装をプラグインできます。

  • メモリ監視。 ASP.NET の既定のメモリ モニターは、アプリケーションがプロセスに構成されているプライベート バイト制限に近づくと、またはコンピューターの使用可能な合計物理 RAM が低下すると、アプリケーションに通知します。 これらの制限に近づくと、通知が発生します。 一部のアプリケーションでは、通知の発生が構成されている制限に近すぎるため、有効な対応を取れません。 開発者は、ApplicationMonitors.MemoryMonitor プロパティを使用して既定値を置き換える独自のメモリ モニターを作成できるようになりました。

  • メモリ制限への対応。 既定では、プライベート バイト プロセス制限が近づくと、ASP.NET はオブジェクト キャッシュの削減を試み、GC.Collect を定期的に呼び出します。 アプリケーションによっては、GC.Collect の呼び出し頻度またはトリミングされるキャッシュ量が非効率になります。 開発者は、アプリケーションのメモリ モニターに IObserver の実装をサブスクライブすることにより、既定の動作を置換または補完できます。

Windows Communication Foundation (WCF)

Windows Communication Foundation (WCF) では以下の機能が追加または変更されました。

既定のメッセージ セキュリティ設定を TLS1.1 または TLS1.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) メソッドの呼び出し時のシリアル化操作の信頼性を向上しました。
  • ChannelSynchronizer.RemoveWaiter メソッドを呼び出して待機を削除するときの信頼性の向上。

Windows フォーム

.NET Framework 4.7 では、Windows フォームによる高 DPI モニターのサポートが向上しました。

高 DPI のサポート

.NET Framework 4.7 を対象とするアプリケーションで、Windows フォーム アプリケーションで高 DPI および動的 DPI がサポートされるようになりました。 高 DPI のサポートにより、フォームのレイアウトと外観および高 DPI モニターでのコントロールが向上します。 動的 DPI は、ユーザーが実行中のアプリケーションの DPI または表示倍率を変更すると、フォームのレイアウトと外観およびコントロールを変更します。

高 DPI のサポートはオプトイン機能であり、アプリケーション構成ファイルの <System.Windows.Forms.ConfigurationSection> セクションを定義することで構成します。 Windows フォーム アプリケーションへの高 DPI サポートおよび動的 DPI サポート追加の詳細については、「Windows フォームの高 DPI サポート」をご覧ください。

Windows Presentation Foundation (WPF)

.NET Framework 4.7 では、WPF の機能が次のように強化されています。

Windows WM_POINTER メッセージに基づくタッチ/スタイラス スタックのサポート

Windows Ink Services Platform (WISP) の代わりに WM_POINTER メッセージに基づいてタッチ/スタイラス スタックを使うオプションが追加されました。 これは、.NET Framework のオプトイン機能です。 詳細については、「アプリケーションの互換性」セクションを参照してください。

WPF 印刷 API の新しい実装

System.Printing.PrintQueue クラスの WPF 印刷 API は、非推奨になった XPS 印刷 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 Changes (.NET Framework 4.6.2 API の変更点)」をご覧ください。 .NET Framework 4.6.2 における機能の改善とバグ修正の一覧については、GitHub で「.NET Framework 4.6.2 List of Changes (.NET Framework 4.6.2 の変更点の一覧)」を参照してください。 詳細については、.NET ブログの「.NET Framework 4.6.2 の発表」を参照してください。

ASP.NET

.NET Framework 4.6.2 では、ASP.NET の機能が次のように強化されています。

データ注釈検証コントロールのローカライズされたエラー メッセージのサポート強化

データ注釈検証コントロールを使用して、1 つ以上の属性をクラス プロパティに追加して検証を行うことができます。 属性の ValidationAttribute.ErrorMessage 要素は、検証が失敗した場合にエラー メッセージのテキストを定義します。 .NET Framework 4.6.2 以降では、ASP.NET でエラー メッセージを簡単にローカライズできます。 エラー メッセージは次のような場合にローカライズされます。

  1. ValidationAttribute.ErrorMessage が検証属性で指定されている。

  2. リソース ファイルが App_LocalResources フォルダーに格納されている。

  3. ローカライズされたリソース ファイル名の形式が DataAnnotation.Localization.{名前}.resx (この名前は、languageCode-country/regionCode または languageCode 形式のカルチャ名) である。

  4. リソースのキー名が 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 の範囲である必要があります。 La note doit être comprise entre 1 et 10.

また、データ注釈ローカリゼーションを拡張することができます。 開発者は、IStringLocalizerProvider インターフェイスを実装してリソース ファイル以外の場所にローカリゼーション文字列を格納することで、独自の文字列ローカライザー プロバイダーにプラグインできます。

セッション状態ストア プロバイダーでの非同期サポート

ASP.NET では、セッション状態ストア プロバイダーでタスクを返すメソッドを使用できるようになりました。これにより、ASP.NET アプリで非同期のスケーラビリティのメリットが得られます。 セッション状態ストア プロバイダーでの非同期操作をサポートするために、ASP.NET には新しいインターフェイスである System.Web.SessionState.ISessionStateModule が含まれています。これは IHttpModule から継承され、開発者はこれを使用して独自のセッション状態モジュールと非同期セッション ストア プロバイダーを実装することができます。 このインターフェイスは次のように定義されます。

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 という 2 つの新しいメソッドが含まれています。これらを使用して、非同期操作をサポートできます。

出力キャッシュ プロバイダーの非同期サポート

.NET Framework 4.6.2 以降で、タスクを返すメソッドを出力キャッシュ プロバイダーで使って、非同期のスケーラビリティのメリットを得ることができます。 これらのメソッドを実装するプロバイダーは、Web サーバー上のスレッド ブロックを減らし、ASP.NET サービスのスケーラビリティを向上させます。

非同期出力キャッシュ プロバイダーをサポートするために、次の API が追加されました。

文字カテゴリ

.NET Framework 4.6.2 の文字は Unicode Standard バージョン 8.0.0 に基づいて分類されます。 .NET Framework 4.6 と .NET Framework 4.6.1 では、文字は Unicode 6.3 文字のカテゴリに基づいて分類されました。

Unicode 8.0 のサポートは、CharUnicodeInfo クラスによる文字列の分類およびそれに依存する型とメソッドに限定されます。 これらには、StringInfo クラス、オーバーロードされた Char.GetUnicodeCategory メソッド、および .NET Framework の正規表現エンジンによって認識される文字クラスが含まれます。 文字や文字列の比較と並べ替えは、この変更の影響を受けず、.NET Framework で提供される文字データについては、引き続き基となるオペレーティング システム (Windows 7 システム) に依存します。

Unicode 6.0 から Unicode 7.0 への文字カテゴリの変更については、Unicode Consortium Web サイトの Unicode Standard バージョン 7.0.0 に関する記述を参照してください。 Unicode 7.0 から Unicode 8.0 への変更については、Unicode Consortium の Web サイトの Unicode Standard バージョン 8.0.0 に関する記述を参照してください。

暗号

FIPS 186-3 DSA を含む X509 証明書のサポート

.NET Framework 4.6.2 で、FIPS 186-2 のキーに対する 1024 ビットの制限を超過するキーを使用できる DSA (Digital Signature Algorithm) 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 では、3 種類の KDF (キー派生関数) ルーチンによる Elliptic Curve Diffie-Hellman キー承諾のサポートが追加されました。 ルーチンへの入力、およびルーチン自体は ECDiffieHellmanCng オブジェクトのプロパティで構成されました。 しかし、すべてのルーチンですべての入力プロパティが読み取られるわけではないため、これまで開発者がよく混乱することがありました。

.NET Framework 4.6.2 ではこれに対処するために、次の 3 つのメソッドが 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 ハッシュの SignedXml サポート

.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 4.6.2 では、.NET Framework Data Provider for SQL Server (System.Data.SqlClient) に次の新機能があります。

Azure SQL Database への接続プールとタイムアウト

接続プールが有効な状態で、タイムアウトまたは他のログイン エラーが発生した場合は、例外がキャッシュされ、キャッシュされた例外は次の 5 秒から 1 分の間の後続の接続試行時にすべてスローされます。 詳しくは、「SQL Server の接続プール (ADO.NET)」をご覧ください。

通常は迅速に復旧される一時的なエラーで接続試行が失敗する可能性があるため、Azure SQL Database への接続時のこの動作は望ましくありません。 接続試行操作をより最適化するため、Azure SQL Database への接続が失敗した場合は、接続プールのブロック期間の動作は削除されます。

新しい PoolBlockingPeriod キーワードを追加することで、ご利用のアプリに最適なブロック期間を選択できます。 次の値が含まれます。

Auto

Azure SQL Database に接続しているアプリケーションの接続プールのブロック期間は無効になり、他のすべての SQL Server インスタンスに接続しているアプリケーションの接続プールのブロック期間が有効になります。 これが既定値です。 サーバー エンドポイント名の末尾が以下のいずれかである場合は、Azure SQL Database と見なされます。

  • .database.windows.net

  • .database.chinacloudapi.cn

  • .database.usgovcloudapi.net

  • .database.cloudapi.de

AlwaysBlock

接続プールのブロック期間は常に有効になります。

NeverBlock

接続プールのブロック期間は常に無効になります。

Always Encrypted の強化

SQLClient では、Always Encrypted の以下の 2 つの機能が強化されました。

  • 暗号化されたデータベースの列に対するパラメーター クエリのパフォーマンスを向上させるために、クエリ パラメーターの暗号化メタデータがキャッシュされるようになりました。 SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled プロパティが true (既定値) に設定されている状態で、同じクエリが複数回呼び出された場合、クライアントはサーバーからパラメーターのメタデータを 1 回だけ取得します。

  • キー キャッシュ内の列暗号化キー エントリは、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 ファイルの <runtime> セクションに次の行を追加することで、この機能を有効にできます。

<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 クラスで 1 つのタイム ゾーンに対して複数の調整規則がサポートされているかどうかを判別することができます。 これはオプトイン機能です。 これを有効にするには、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 に設定すれば、クライアントは常に最も一致するサービスに接続するようになります。

Note

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 が必要な場合は、以下の構成メカニズムのいずれかを使用して、ネゴシエートされたプロトコルの一覧に追加します。

Windows Presentation Foundation (WPF)

.NET Framework 4.6.2 では、Windows Presentation Foundation の次の領域の機能が強化されています。

グループの並べ替え

CollectionView オブジェクトを使用してデータをグループ化するアプリケーションは、グループを並べ替える方法を明示的に宣言できるようになりました。 明示的な並べ替えにより、アプリがグループを動的に追加または削除する場合や、グループ化に関連する項目のプロパティの値を変更する場合に発生する非直感的な順序付けの問題が解決されます。 また、グループ化プロパティの比較がコレクション全体の並べ替えからグループの並べ替えに変更されるため、グループ作成プロセスのパフォーマンスを向上させることができます。

グループの並べ替えをサポートするために、新しい GroupDescription.SortDescriptions および GroupDescription.CustomSort プロパティで、GroupDescription オブジェクトによって生成されるグループのコレクションを並べ替える方法が示されます。 これは、同じ名前の ListCollectionView プロパティでデータ項目を並べ替える方法を示すのと同様です。

PropertyGroupDescription クラスの新しい 2 つの静的プロパティである CompareNameAscending と CompareNameDescending は、最も一般的なケースで使用できます。

たとえば、次の XAML ではデータを年齢でグループ化し、年齢グループを昇順に並べ替え、各年齢グループ内の項目を姓でグループ化します。

<GroupDescriptions>
     <PropertyGroupDescription
         PropertyName="Age"
         CustomSort=
              "{x:Static PropertyGroupDescription.CompareNamesAscending}"/>
     </PropertyGroupDescription>
</GroupDescriptions>

<SortDescriptions>
     <SortDescription PropertyName="LastName"/>
</SortDescriptions>

タッチ キーボードのサポート

タッチ キーボードのサポートにより、WPF アプリケーションでのフォーカス追跡が可能になります。テキスト入力が可能なコントロールによってタッチ入力が受信されると、Windows 10 の新しいタッチ キーボードが自動的に起動および終了します。

.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 で実行されるアプリの場合、次のように、アプリケーションの構成ファイルの <runtime> セクションに構成ステートメントを追加して、WPF アプリでモニターごとの DPI 変更を無効にすることができます。

<runtime>
   <AppContextSwitchOverrides value="Switch.System.Windows.DoNotScaleForDpiChanges=false"/>
</runtime>

Windows Workflow Foundation (WF)

.NET Framework 4.6.2 では、Windows Workflow Foundation の次領域の機能が強化されています。

再ホストされた WF デザイナーにおける C# 式と IntelliSense のサポート

.NET Framework 4.5 以降では、WF によって、Visual Studio デザイナーとコード ワークフローの両方で C# 式がサポートされます。 再ホストされたワークフロー デザイナーは WF の主な機能です。これにより、ワークフロー デザイナーを Visual Studio の外部のアプリケーション (WPF など) で使用できるようになります。 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 ワークフロー デザイナーで動的更新を使用する場合のワークフローの改善

ワークフロー デザイナー、フローチャート アクティビティ デザイナー、およびその他のワークフロー アクティビティ デザイナーで、DynamicUpdateServices.PrepareForUpdate メソッドを呼び出した後に保存されたワークフローが正常に読み込まれ、表示されるようになりました。 .NET Framework 4.6.2 より前のバージョンの .NET Framework では、DynamicUpdateServices.PrepareForUpdate を呼び出した後に保存されたワークフローの XAML ファイルを Visual Studio で読み込むと、以下の問題が発生する場合がありました。

  • ワークフロー デザイナーで XAML ファイルが正しく読み込めない (行の末尾に ViewStateData.Id がある場合)。

  • フローチャート アクティビティ デザイナーまたは他のワークフロー アクティビティ デザイナーで、アタッチされるプロパティの値ではなく既定の場所にすべてのオブジェクトが表示される場合がある。

ClickOnce

ClickOnce が更新され、既にサポートされている 1.0 プロトコルに加え、TLS 1.1 と TLS 1.2 がサポートがサポートされるようになりました。 ClickOnce が必要なプロトコルを自動的に検出するため、TLS 1.1 と 1.2 のサポートを有効にするために、ClickOnce アプリケーション内での追加の手順は不要です。

Windows フォームおよび WPF アプリの UWP アプリへの変換

Windows では、WPF および Windows フォーム アプリを含む、既存の Windows デスクトップ アプリを UWP (ユニバーサル Windows プラットフォーム) で使用できるようになりました。 このテクノロジはブリッジとして機能し、既存のコード ベースを段階的に UWP に移行し、アプリをすべての Windows 10 デバイスで使用できるようにします。

変換後のデスクトップ アプリは UWP アプリのアプリ ID のようなアプリ ID を取得し、UWP API をアクセス可能にして、ライブ タイルや通知などの機能を有効にすることができます。 アプリは引き続き従来どおり動作し、完全信頼アプリとして実行されます。 アプリが変換されたら、アプリ コンテナー プロセスを既存の完全信頼プロセスに追加し、適応ユーザー インターフェイスを追加できます。 すべての機能がアプリ コンテナー プロセスに移行されたら、完全信頼プロセスを削除し、新しい UWP アプリをすべての Windows 10 デバイスで有効にすることができます。

デバッグの機能強化

.NET Framework 4.6.2 でアンマネージ デバッグ API が強化され、NullReferenceException がスローされたときに、ソース コードの単一行でどの変数が 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 (Elliptic Curve Digital Signature Algorithm: 楕円曲線デジタル署名アルゴリズム) 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 では、Always Encrypted 列 (常に暗号化される列) のマスター キーをハードウェア セキュリティ モジュール (HSM) に格納することが、ネイティブでサポートされるようになりました。 このサポートによって、ユーザーは、HSM に格納された非対称キーを利用できます。カスタムの列マスター キー ストア プロバイダーを作成してからアプリケーションに登録する必要はありません。

HSM に格納された列マスター キーで保護された Always Encrypted データにアクセスするには、HSM ベンダー提供の CSP プロバイダーまたは CNG キー ストア プロバイダーをアプリ サーバーまたはクライアント コンピューターにインストールする必要があります。

AlwaysOn に対する MultiSubnetFailover の接続動作の向上

SqlClient で、AlwaysOn 可用性グループ (AG) へのより高速な接続が自動的に提供されるようになりました。 SqlClient では、アプリケーションが別のサブネット上の AlwaysOn 可用性グループ (AG) に接続しているかどうかを自動的に検出し、現在のアクティブなサーバーを迅速に探索し、そのサーバーへの接続を提供します。 このリリースよりも前は、アプリケーションで接続文字列を設定し、"MultisubnetFailover=true" を含め、AlwaysOn 可用性グループに接続されていることを示す必要がありました。 true への接続キーワードを設定しないと、アプリケーションで AlwaysOn 可用性グループに接続中にタイムアウトが発生する可能性がありました。 このリリースを使用すれば、アプリケーションで MultiSubnetFailover を true に設定する必要がなくなります。 Always On 可用性グループの SqlClient サポートの詳細については、「高可用性障害復旧のための SqlClient サポート」をご覧ください。

Windows Presentation Foundation (WPF)

Windows Presentation Foundation には、さまざまな改善と変更が含まれています。

パフォーマンスの向上

.NET Framework 4.6.1 で、タッチ イベントの開始の遅延が修正されました。 また、RichTextBox コントロールの入力が高速入力時のレンダーのスレッドを停止させなくなりました。

スペル チェック機能の改善

WPF のスペル チェック機能が、追加の言語のスペル チェックのためにオペレーティング システムのサポートを利用するように、Windows 8.1 以降のバージョンで更新されました。 Windows 8.1 よりも前の Windows バージョンの機能の変更はありません。

TextBox コントロールまたは RichTextBox ブロックの言語は、以前のバージョンの .NET Framework と同様に、次の順序で情報を探し検出されます。

  • xml:lang (存在する場合)。

  • 現在の入力言語。

  • 現在のカルチャ。

WPF での言語サポートの詳細については、.NET Framework 4.6.1 機能に関する WPF ブログの記事を参照してください。

ユーザーごとのユーザー辞書の追加サポート

.NET Framework 4.6.1 では、WPF で、グローバルに登録されているユーザー辞書が認識されます。 この機能は、ユーザー辞書をコントロールごとに登録する機能に加えて使用できます。

以前のバージョンの WPF では、ユーザー辞書で除外された単語とオートコレクト リストが認識されませんでした。 %AppData%\Microsoft\Spelling\<language tag> ディレクトリに配置できるファイルの使用によって、これらが Windows 8.1 と Windows 10 でサポートされます。 これらのファイルには、次の規則が適用されます。

  • これらのファイルには、拡張子の .dic (追加された単語の場合)、.exc (除外された単語の場合)、または .acl (オートコレクトの場合) が付いている必要があります。

  • これらのファイルは、バイト オーダー マーク (BOM) で始まる UTF-16 LE プレーン テキストである必要があります。

  • それぞれの行は、1 つの単語 (追加および除外された単語の一覧内)、または単語が縦棒 ("|") で区切られたオートコレクトのペア (オートコレクトの単語の一覧内) で構成される必要があります。

  • これらのファイルは読み取り専用と見なされ、システムによって変更されることはありません。

Note

これらの新しいファイル形式は、WPF スペル チェック API で直接サポートされるわけではありません。また、アプリケーションで WPF に提供されるユーザー辞書では以前と同様に .lex ファイルを使用する必要があります。

サンプル

WPF のサンプルは、Microsoft/WPF サンプル GitHub リポジトリにいくつかあります。 プル要求を送信するか、またはGitHub issue (GitHub の問題) を開いて、これらのサンプルの改善にご協力ください。

DirectX の拡張機能

WPF には、DX10 および Dx11 のコンテンツとの相互運用を容易にする、D3DImage の新しい実装を提供する NuGet パッケージが含まれています。 このパッケージのコードはオープン ソース化されており、GitHub で入手できます。

Windows Workflow Foundation: トランザクション

Transaction.EnlistPromotableSinglePhase メソッドで、MSDTC 以外の分散トランザクション マネージャーを使用して、トランザクションをプロモート (昇格) できるようになりました。 このプロモートは、新しい Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) オーバーロードに GUID のトランザクション プロモーター識別子を指定することによって行います。 この操作が成功すると、そのトランザクションの機能に制限が加えられます。 MSDTC 以外のトランザクション プロモーターが登録される (参加する) と、次の各メソッドで MSDTC へのプロモートが必要になるため、これらのメソッドで TransactionPromotionException がスローされます。

MSDTC 以外のトランザクション プロモーターが登録されると、そのプロモーターで定義するプロトコルを使用することで、そのプロモーターをその後の永続参加リストに使用する必要があります。 トランザクション プロモーターの Guid は、PromoterType プロパティを使用して取得できます。 トランザクションがプロモートする際、トランザクション プロモーターによって、プロモート済みトークンを表す Byte 配列が提供されます。 アプリケーションで、MSDTC 以外のプロモート済みトランザクションのプロモート済みトークンを GetPromotedToken メソッドを使用して取得できます。

新しい Transaction.EnlistPromotableSinglePhase(IPromotableSinglePhaseNotification, Guid) オーバーロードのユーザーは、プロモーション操作が正常に完了するように、特定の呼び出しシーケンスに従う必要があります。 これらの規則は、メソッドのドキュメントに記載されています。

プロファイル

アンマネージド プロファイリング API が、次のように拡張されました。

  • ICorProfilerInfo7 インターフェイス内の PDB へのアクセスのサポートが向上。

    ASP.NET Core では、アセンブリがメモリ内で Roslyn によってコンパイルされることがよりいっそう一般的になっています。 プロファイル ツールを作成する開発者にとって、これは従来ディスクにシリアル化されていた PDB が存在しなくなる可能性があることを意味しています。 プロファイル ツールでは、多くの場合 PDB を使用して、コード カバレッジや 1 行単位のパフォーマンス分析などのタスクのソース行に、コードをマップし戻します。 ICorProfilerInfo7 インターフェイスは、メモリ内の PDB データにアクセスして、これらのプロファイル ツールを提供する 2 つの新しいメソッド、ICorProfilerInfo7::GetInMemorySymbolsLength と ICorProfilerInfo7::ReadInMemorySymbols を含むようになりました。これらの新しい API を使用すれば、プロファイラーでメモリ内の PDB の内容をバイト配列として取得してから、それを処理したり、ディスクにシリアル化したりできます。

  • ICorProfiler インターフェイスを使用したインストルメンテーションの改善。

    動的インストルメンテーションに ICorProfiler API ReJit 機能を使用しているプロファイラーで、いくつかのメタデータを変更できるようになりました。 従来、このようなツールでは、いつでも IL をインストルメント化できましたが、メタデータを変更できるのはモジュールを読み込む時だけでした。 IL はメタデータを参照するため、実行できるインストルメンテーションの種類が限られています。 モジュールの読み込み後のメタデータの編集のサブセットをサポートするために、ICorProfilerInfo7::ApplyMetaData メソッドを追加することで (特に新しい AssemblyRef、TypeRef、TypeSpec、MemberRef、MemberSpec、および UserString の各レコードを追加することで)、これらの制限の一部を解消しました。 この変更により、はるかに広範な実行時インストルメンテーションが可能になります。

ネイティブ イメージ ジェネレーター (NGEN) PDB

マシン間のイベント トレースを使用すれば、ユーザーはマシン A 上でプログラムをプロファイリングし、マシン B 上でソース行のマッピングを使用して、プロファイリング データを確認できます。以前のバージョンの .NET Framework で、ソースからネイティブへのマッピングを作成するには、ユーザーは、プロファイルされたコンピューターにあるすべてのモジュールとネイティブ イメージを、IL PDB が含まれた分析用コンピューターにコピーする必要がありました。 この処理は、Phone アプリケーションなどファイル サイズが比較的小さい場合には高速に実行されますが、これらのファイルのサイズがデスクトップ システム上で非常に大きくなる可能性があり、その場合コピーにかなりの時間を要する可能性があります。

NGen PDB を使用すれば、IL PDB に依存することなく、NGen で IL からネイティブへのマッピングが含まれた PDB を作成できます。 このマシン間のイベント トレース シナリオで必要なことは、コンピューター A で生成されたネイティブ イメージの PDB をコンピューター B にコピーすることと、Debug Interface Access API を使用して IL PDB のソースから 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 には、ASP.NET Core が含まれています。これは、最新のクラウド ベースのアプリを構築するのに効率的な .NET 実装です。 ASP.NET Core はモジュール形式であるため、ご利用のアプリケーションで必要な機能のみを含めることができます。 IIS でホストすることも、カスタムのプロセスでセルフホストすることもできます。さらに同じサーバー上のさまざまなバージョンの .NET Framework でアプリを実行することも可能です。 クラウド展開用に設計されている新たな環境構成システムが含まれています。

    MVC、Web API、および Web ページは、MVC 6 と呼ばれる 1 つのフレームワークに統合されています。 Visual Studio 2015 以降のツールで ASP.NET Core アプリをビルドします。 既存のアプリケーションは、この新しい .NET Framework で動作しますが、MVC 6 または SignalR 3 を使用するアプリをビルドするには Visual Studio 2015 以降のプロジェクト システムを使用する必要があります。

    詳細については、ASP.NET Core に関するページを参照してください。

  • ASP.NET の更新プログラム

    • 非同期応答フラッシュ用のタスク ベース API

      ASP.NET で、非同期応答フラッシュ用の単純なタスク ベース API である HttpResponse.FlushAsync が提供されるようになりました。これにより、言語の async/await サポートを使用して非同期的に応答をフラッシュできます。

    • モデル バインドによるタスクを返すメソッドのサポート

      .NET Framework 4.5 の ASP.NET に、Web フォーム ページやユーザー コントロールでの CRUD ベースのデータ操作で、拡張可能なコード中心のアプローチを可能にするモデル バインド機能が追加されました。 このモデル バインド システムで、Task を返すモデル バインド メソッドがサポートされるようになりました。 この機能により、Web フォーム開発者は 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 プロトコルの新しいバージョンで、接続の使用状況が (クライアントとサーバー間のラウンド トリップ数の減少により) 大幅に改善されて、ユーザーが Web ページを読み込むときの遅延が軽減されています。 このプロトコルは単一のエクスペリエンスの一部として要求さる複数の成果物のために最適化されているので、HTTP/2 が最も役立つのは (サービスではなく) web ページです。 .NET Framework 4.6 では、HTTP/2 のサポートが ASP.NET に追加されました。 ネットワーク機能は複数のレイヤーで存在するので、HTTP/2 を有効にするために、Windows、IIS、および ASP.NET で新機能が必要とされていました。 ASP.NET で HTTP/2 を使用するには、Windows 10 を実行している必要があります。

      HTTP/2 は、System.Net.Http.HttpClient API を使用する Windows 10 ユニバーサル Windows プラットフォーム (UWP) アプリでもサポートされ、既定で有効になります。

      ASP.NET アプリケーションで PUSH_PROMISE 機能を使用する手段を提供するために、PushPromise(String) と PushPromise(String, String, NameValueCollection) の 2 つのオーバーロードを持つ新しいメソッドが HttpResponse クラスに追加されました。

      Note

      ASP.NET Core では HTTP/2 がサポートされますが、PUSH PROMISE 機能のサポートはまだ追加されていません。

      ブラウザーと web サーバー (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 機能がサポートされました。 SQL Server は、Always Encrypted 機能を使用して、暗号化されたデータに対して操作を実行できます。特に、サーバー上ではなく、ユーザーが信頼している環境内にアプリケーションと共に暗号化キーを保存できるようになりました。 Always Encrypted でユーザー データが保護されるので、DBA はプレーン テキスト データにアクセスできません。 データの暗号化と復号化は、ドライバー レベルで透過的に行われるので、既存のアプリケーションに対する変更が最小限に抑えられます。 詳細については、「Always Encrypted (データベース エンジン)」および「Always Encrypted (クライアント開発)」を参照してください。

  • マネージド コードの JIT コンパイラ (64 ビット)

    .NET Framework 4.6 の特徴の 1 つとして、新しいバージョンの 64 ビット JIT コンパイラ (RyuJIT というコードネームで呼ばれていたもの) があります。 この新しい 64 ビット コンパイラは、これまでの 64 ビット JIT コンパイラよりもパフォーマンスが大幅に向上しています。 新しい 64 ビット コンパイラは、.NET Framework 4.6 上で実行される 64 ビット プロセスで有効になります。 64 ビットまたは AnyCPU としてコンパイルされ、64 ビット オペレーティング システム上で実行されるアプリは、64 ビットで動作します。 新しいコンパイラへの移行をできる限り透過的に行うように注意を払いましたが、動作の変更が発生する可能性があります。

    新しい 64 ビット JIT コンパイラには、ハードウェア SIMD アクセラレータ機能も含まれています。これを System.Numerics 名前空間の SIMD 対応の型と組み合わせると、パフォーマンスが大幅に向上する可能性があります。

  • アセンブリ ローダーの改善

    アセンブリ ローダーで、対応する NGEN イメージの読み込み後に IL アセンブリをアンロードすることにより、メモリがより効率的に使用されるようになりました。 この変更は、仮想メモリが減少するため、特に大規模な 32 ビット アプリ (Visual Studio など) で有益であり、物理メモリの節約にもなります。

  • 基本クラス ライブラリの変更点

    主なシナリオを利用できるようにするため、多くの新しい API が .NET Framework 4.6 に関連して追加されました。 変更点と追加点を以下に示します。

    • IReadOnlyCollection<T> の実装

      追加のコレクション IReadOnlyCollection<T> (Queue<T>、Stack<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 は、System.Security.Cryptography の実装の基礎として、それより前のバージョンの Windows 暗号化 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 の機能強化。 たとえば、以前のバージョンの .NET Framework で X509Certificate2 オブジェクトを使用してデータを暗号化するには、次のようなコードが必要です。

        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 で新しい暗号化を使用するコードは、次のように書き換えてキャストを回避することができます。

        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

      スイッチは、ライブラリによって公開される正式なコントラクトであるため、一貫性のある形式を使用することをお勧めします。 2 つの明確な形式を次に示します。

      • Switch.namespace.switchname

      • Switch.library.switchname

    • タスク ベースの非同期パターン (TAP) の変更点

      .NET Framework 4.6 をターゲットとするアプリでは、Task および Task<TResult> オブジェクトは、呼び出し元のスレッドのカルチャと UI カルチャを継承します。 以前のバージョンの .NET Framework をターゲットするとアプリまたは特定のバージョンの .NET Framework をターゲットとしないアプリの動作には影響はありません。 詳細については、CultureInfo クラスのトピックの「カルチャとタスク ベースの非同期の操作」セクションをご覧ください。

      System.Threading.AsyncLocal<T> クラスを使用すると、async メソッドなど、特定の非同期制御フローに対してローカルなアンビエント データを表すことができます。 これは、スレッド間でデータを保持するために使用できます。 AsyncLocal<T>.Value プロパティの明示的な変更やスレッドでのコンテキスト変換の発生などによってアンビエント データが変更されるたびに通知されるコールバック メソッドを定義することもできます。

      タスク ベースの非同期パターン (TAP) に、特定の状態で完了したタスクを返す 3 つの便利なメソッド Task.CompletedTask、Task.FromCanceled、および Task.FromException が追加されました。

      NamedPipeClientStream クラスで、新しい ConnectAsync メソッドによる非同期通信がサポートされるようになりました。 メソッドをオーバーライドします。

    • EventSource がイベント ログへの書き込みをサポート

      コンピューター上で作成された既存の ETW セッションに加えて、EventSource クラスを使用して管理または操作メッセージをイベント ログに記録できるようになりました。 以前は、この機能のために Microsoft.Diagnostics.Tracing.EventSource NuGet パッケージを使用する必要がありました。 この機能は .NET Framework 4.6 に組み込まれました。

      NuGet パッケージと .NET Framework 4.6 は、どちらも次の機能によって更新されています。

      • ダイナミック イベント

        イベント メソッドを作成せずに、実行時にイベントを定義できます。

      • リッチ ペイロード

        特別な属性が指定されたクラスや配列に加えて、プリミティブ型もペイロードとして渡すことができます。

      • アクティビティの追跡

        Start イベントと Stop イベントの間のイベントに、現在アクティブなすべてのアクティビティを表す ID が付けられます。

      これらの機能をサポートするため、EventSource クラスにオーバーロードされた Write メソッドが追加されました。

  • Windows Presentation Foundation (WPF)

    • HDPI の強化

      .NET Framework 4.6 の WPF で、HDPI のサポートが強化されました。 境界があるコントロールでのクリッピングの発生を減らすため、レイアウトの丸め処理が変更されました。 既定では、TargetFrameworkAttribute が .NET Framework 4.6 に設定されている場合にのみ、この機能が有効になります。 以前のバージョンの Framework を対象とするアプリケーションが .NET Framework 4.6 で実行される場合は、app.config ファイルの <runtime> セクションに次の行を追加することで、新しい動作を選択できます。

      <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 8.1 以降では、Windows ストア アプリケーションと WPF アプリケーションのダブルタップのしきい値が同じになりました。

    • 透過的な子ウィンドウのサポート

      .NET Framework 4.6 の WPF は、Windows 8.1 以降で、透過的な子ウィンドウをサポートしています。 これにより、最上位レベルのウィンドウ内に四角形でない透過的な子ウィンドウを作成できます。 この機能を有効にするには、HwndSourceParameters.UsesPerPixelTransparency プロパティを true に設定します。

  • Windows Communication Foundation (WCF)

    • SSL のサポート

      WCF で、NetTcp をトランスポート セキュリティおよびクライアント認証と共に使用する場合に、SSL のバージョンとして SSL 3.0 および TLS 1.0 に加えて 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 接続を使用して特定のメッセージを送信できるようになりました。 これには、2 つの方法があります。

      • 接続グループ名プレフィックスの使用

        ユーザーは、WCF で接続グループ名のプレフィックスとして使用される文字列を指定できます。 異なるプレフィックスを持つ 2 つのメッセージは、別の基になる HTTP 接続を使用して送信されます。 プレフィックスを設定するには、メッセージの Message.Properties プロパティにキー/値のペアを追加します。 キーは "HttpTransportConnectionGroupNamePrefix" で、値は使用するプレフィックスです。

      • 異なるチャネル ファクトリの使用

        ユーザーは、異なるチャネル ファクトリによって作成されたチャネルを使用して送信されるメッセージで別の基になる HTTP 接続を使用する機能を有効にすることもできます。 この機能を有効にするには、ユーザーが次の appSetting を true に設定する必要があります。

        <appSettings>
    <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true" />
</appSettings>

  • Windows Workflow Foundation (WWF)

    順序不定の操作要求がタイムアウトする前に未処理の "非プロトコル" ブックマークが存在する場合に、ワークフロー サービスが要求を保持する秒数を指定できるようになりました。 "非プロトコル" ブックマークとは、未処理の Receive アクティビティに関連付けられていないブックマークです。 一部のアクティビティはその実装内で非プロトコル ブックマークを作成するため、必ずしも非プロトコル ブックマークの存在が明らかにわかるとは限りません。 例として State や Pick などがあります。 ステート マシンを使用して実装されたワークフロー サービスや、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 要素の値がゼロ以外で、非プロトコル ブックマークが存在し、タイムアウト間隔が終了した場合、その操作は失敗し、タイムアウト メッセージが発生します。

  • トランザクション

    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 では、ポートの再利用を有効にする次の 2 つの API が追加され、コンカレント接続に対する 64 KB の制限が実質的になくなりました。

      既定では、HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 レジストリ キーの HWRPortReuseOnSocketBind の値が 0x1 に設定されないかぎり、ServicePointManager.ReusePort プロパティは false になります。 HTTP 接続でのローカル ポートの再利用を有効にするには、ServicePointManager.ReusePort プロパティを true に設定します。 これにより、HttpClient および HttpWebRequest からの外向きのすべての TCP ソケット接続で Windows 10 の新しいソケット オプション SO_REUSE_UNICASTPORT が使用されるようになるため、ローカル ポートの再利用が可能になります。

      ソケット専用のアプリケーションを作成する開発者は、Socket.SetSocketOption などのメソッドを呼び出すときに System.Net.Sockets.SocketOptionName オプションを指定することにより、送信ソケットでバインド中にローカル ポートを再利用できるようになります。

    • 国際ドメイン名と PunyCode のサポート

      Uri クラスに新しいプロパティ IdnHost が追加され、国際ドメイン名と PunyCode のサポートが強化されました。

  • Windows フォーム コントロールでのサイズ変更

    この機能が .NET Framework 4.6 にも拡張されました。DomainUpDown、NumericUpDown、DataGridViewComboBoxColumn、DataGridViewColumn、ToolStripSplitButton 型、および UITypeEditor を描画するときに使用する Bounds プロパティで指定される四角形も含まれるようになりました。

    これはオプトイン機能です。 この機能を有効にするには、アプリケーション構成 (app.config) ファイルで EnableWindowsFormsHighDpiAutoResizing 要素を true に設定します。

    <appSettings>
    <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
</appSettings>

  • コード ページのエンコーディングのサポート

    .NET Core は、本来 Unicode エンコードをサポートし、既定ではコード ページ エンコーディングに関するサポートは限定的です。 Encoding.RegisterProvider メソッドを使用してコード ページ エンコードを登録することで、.NET Framework では利用できるものの .NET Core ではサポートされていないコード ページ エンコードのサポートを追加できます。 詳細については、「System.Text.CodePagesEncodingProvider」を参照してください。

  • .NET ネイティブ

C# または Visual Basic で作成されている ユニバーサル Windows プラットフォーム (UWP) アプリは、IL ではなくネイティブ コードにアプリをコンパイルする新しい技術を活用できます。 このテクノロジにより、起動時間と実行時間が短縮されたアプリが生成されます。 詳しくは、「.NET ネイティブによるアプリのコンパイル」をご覧ください。 JIT コンパイルと NGEN による結果の違い、およびコードにおけるその影響の概要については、「.NET ネイティブとコンパイル」をご覧ください。

ご利用のアプリは、Visual Studio 2015 以降でコンパイルするときに、既定でネイティブ コードにコンパイルされます。 詳しくは、「.NET ネイティブの概要」をご覧ください。

.NET ネイティブ アプリのデバッグをサポートするため、アンマネージ デバッグ APIに対して数多くの新しいインターフェイスと列挙型が追加されました。 詳しくは、「デバッグ (アンマネージ API リファレンス)」をご覧ください。

  • オープン ソースの .NET Framework パッケージ

    .NET Core のパッケージ (変更できないコレクションなど)、SIMD API、およびネットワーク API (System.Net.Http 名前空間に含まれるものなど) は、GitHub でオープンソース パッケージとして入手できるようになりました。 このコードにアクセスするには、GitHub 上の .NET をご覧ください。 これらのパッケージの詳細、および投稿方法については、「.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 プロパティは、応答ヘッダーが書き込まれたかどうかを示すブール値を返します。 これらのプロパティを使用して、HttpResponse.StatusCode (ヘッダーが書き込まれた場合に例外をスローする) などの API への呼び出しが成功することを確認できます。

  • Windows フォーム コントロールでのサイズ変更。 この機能が拡張されました。 これにより、システム DPI 設定を使用して、次の追加コントロールのコンポーネント (例: コンボ ボックスのドロップダウン矢印) をサイズ変更できます。

    これはオプトイン機能です。 この機能を有効にするには、アプリケーション構成 (app.config) ファイルで EnableWindowsFormsHighDpiAutoResizing 要素を true に設定します。

    <appSettings>
    <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
</appSettings>

  • 新しいワークフロー機能。 EnlistPromotableSinglePhase メソッドを使用している (および、結果として IPromotableSinglePhaseNotification インターフェイスを実装している) リソース マネージャーは、新しい Transaction.PromoteAndEnlistDurable メソッドを使用して、次の事柄を要求できます。

    • トランザクションを Microsoft 分散トランザクション コーディネーター (MSDTC) トランザクションに昇格する。

    • IPromotableSinglePhaseNotification を ISinglePhaseNotification (単一フェーズのコミットをサポートする永続的登録リスト) に置き換えます。

    これは同じアプリ ドメイン内で実行でき、MSDTC とやり取りして昇格を実行するためにアンマネージ コードを追加する必要はありません。 System.Transactions から昇格可能な登録リストにより実装された IPromotableSinglePhaseNotificationPromote メソッドへの未処理の呼び出しがある場合のみ、この新しいメソッドを呼び出すことができます。

  • プロファイリングの機能強化。 次の新しいアンマネージ プロファイリング API により、さらに信頼性の高いプロファイリングを提供します。

    以前の ICorProfiler の実装は、依存アセンブリの遅延読み込みをサポートしていました。 新しいプロファイリング API では、プロファイラーにより挿入される依存アセンブリを、アプリの完全な初期化後に読み込むのではなく、すぐに読み込む必要があります。 この変更は、既存の ICorProfiler API のユーザーには影響しません。

  • デバッグの機能強化。 次の新しいアンマネージド デバッグ API により、プロファイラーとの統合性が向上しました。 これにより、ダンプのデバッグ時にコンパイラ ReJIT 要求により作成されたローカル変数やコードだけでなく、プロファイラーにより挿入されたメタデータにアクセスできます。

  • イベント トレーシングの変更。 .NET Framework 4.5.2 では、より大きなサーフェイス領域において、アウトプロセスの Windows イベント トレーシング (ETW) に基づくアクティビティ トレーシングができるようになりました。 これにより、アドバンスト パワー マネージメント (APM) ベンダーは、スレッドを越えた個々の要求とアクティビティのコストを正確に追跡する軽量ツールを提供できます。 これらのイベントは、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 トランザクションに昇格させ、昇格可能参加リストを永続参加リストに "変換" するように要求します。 このメソッドが正常に完了すると、IPromotableSinglePhaseNotification インターフェイスが System.Transactions から参照されなくなり、その後の通知は指定された ISinglePhaseNotification インターフェイスに到着します。 問題の参加リストは、永続参加リストとして機能し、トランザクションのログ記録と復旧をサポートする必要があります。 詳細については、Transaction.EnlistDurable を参照してください。 さらに、この参加リストは ISinglePhaseNotification もサポートする必要があります。 このメソッドは、ITransactionPromoter.Promote の呼び出しの処理中にのみ呼び出すことができます。 そうでない場合は、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 テンプレートとして空白ページ、リソース ディクショナリ、template 宣言されたコントロール、およびユーザー コントロールがサポートされています。

    • Windows 8.1 および Windows Phone 8.1 を対象とするストア アプリで使用するためにポータブル Windows ラインタイム コンポーネント (.winmd ファイル) を作成できます。

    • ポータブル クラス ライブラリのような Windows ストアまたは Windows Phone ストア クラス ライブラリを再ターゲットできます。

    これらの変更の詳細については、ポータブル クラス ライブラリに関するページを参照してください。

  • .NET Framework のコンテンツ セットには、Windows アプリをビルドして配置するためのプリコンパイル テクノロジである .NET Native のドキュメントが含まれます。 .NET Native は、中間言語 (IL) ではなくネイティブ コードへアプリを直接コンパイルすることにより、パフォーマンスを向上させます。 詳しくは、「.NET ネイティブによるアプリのコンパイル」をご覧ください。

  • .NET Framework Reference Source で、新しい参照エクスペリエンスと強化された機能が提供されます。 これにより、.NET Frameworkのソース コードをオンラインで参照したり、リファレンスをダウンロードしてオフラインで表示したりできます。さらに、デバッグ中にソース (パッチや更新を含む) をステップ実行できます。 詳細については、ブログ記事「A new look for .NET Reference Source (.NET Reference Source の新しい外観)」を参照してください。

.NET Framework 4.5.1 の基底クラスの新機能と機能強化には次が含まれます。

  • アセンブリの自動バインディング リダイレクト。 .NET Framework 4.5.1 を対象とするアプリをコンパイルする場合、お使いのアプリまたはそのコンポーネントが同じアセンブリの複数バージョンを参照している場合、Visual Studio 2013 以降ではバインディング リダイレクトがアプリの構成ファイルに追加される場合があります。 この機能は、.NET Framework の以前のバージョンを対象とするプロジェクトでも有効にできます。 詳細については、「方法:自動バインディング リダイレクトを有効/無効にする」をご覧ください。

  • 開発者がサーバーおよびクラウド アプリケーションのパフォーマンスを向上するために役立つ診断情報を収集する機能。 詳細については、WriteEventWithRelatedActivityId クラスの WriteEventWithRelatedActivityIdCore メソッドと EventSource メソッドを参照してください。

  • ガベージ コレクション中に大きなオブジェクト ヒープ (LOH) を圧縮する機能。 詳細については、GCSettings.LargeObjectHeapCompactionMode プロパティを参照してください。

  • その他のパフォーマンス向上 (ASP.NET アプリの中断、マルチコア JIT の改良、.NET Framework 更新後のアプリ起動時間の短縮など)。 詳細については、ブログ記事「.NET Framework 4.5.1 announcement」(.NET Framework 4.5.1 についてのお知らせ) および「ASP.NET app suspend」 (ASP.NET アプリケーションの中断) を参照してください。

Windows フォームの機能強化には次が含まれます。

  • Windows フォーム コントロールでのサイズ変更。 アプリのアプリケーション構成ファイル (app.config) 内のエントリで有効にすることにより、システム DIP 設定を使用してコントロールのコンポーネント (例: プロパティ グリッドに表示されるアイコン) をサイズ変更できます。 現在、この機能は次の Windows フォーム コントロールでサポートされています。

    この機能を有効にするには、構成ファイル (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 ビット アプリの両方でまだ有効です (「Supported Code Changes (C#)」(サポートされているコードの変更 (C#)) の記事の最後のセクションを参照してください)。

  • 非同期対応のデバッグ。 Visual Studio 2013 で非同期アプリを簡単にデバッグするために、呼び出し履歴には、非同期プログラミングをサポートするためにコンパイラに用意されているインフラストラクチャ コード、および論理上の親フレーム内のチェーンが表示されません。これにより、論理的なプログラムの実行をよりわかりやすく行うことができます。 [タスク] ウィンドウが [並列タスク] ウィンドウに代わって使用され、特定のブレークポイントに関連するタスクが表示されます。また、現在アクティブなタスクやアプリでスケジュールされているタスクなども表示されます。 この機能については、「.NET Framework 4.5.1 announcement」(.NET Framework 4.5.1 についてのお知らせ) の「Async-aware debugging」(非同期対応のデバッグ) セクションを参照してください。

  • Windows ランタイム コンポーネント向けのより適切な例外処理のサポート。 Windows 8.1 では、言語の種類に関係なく、Windows ストア アプリから発生する例外には、例外を発生させたエラーに関する情報が保持されます。 この機能については、「.NET Framework 4.5.1 announcement」(.NET Framework 4.5.1 についてのお知らせ) の「Windows Store app development」(Windows ストア アプリ開発) のセクションを参照してください。

Visual Studio 2013 以降では、Mpgo.exe (マネージド プロファイル ガイド付き最適化ツール) を使って、Windows 8.x ストア アプリとデスクトップ アプリを最適化することができます。

ASP.NET 4.5.1 の新機能については、「ASP.NET and Web Tools for Visual Studio 2013 のリリース ノート」を参照してください。

.NET Framework 4.5 の新機能

基底クラス

  • 配置時に .NET Framework 4 アプリケーションを検出して終了することにより、システムの再起動を減らす機能。 「.NET Framework 4.5 のインストール中のシステム再起動の削減」をご覧ください。

  • 64 ビット プラットフォームでの 2 ギガバイト (GB) を超える配列のサポート。 この機能は、アプリケーション構成ファイルで有効にすることができます。 「<gcAllowVeryLargeObjects> 要素」も参照してください。オブジェクト サイズと配列サイズに関する他の制限も記載されています。

  • サーバーのガベージ コレクションをバックグラウンドで行うことにより、パフォーマンスを改善します。 .NET Framework 4.5 でサーバーのガベージ コレクションを使うと、バックグラウンド ガベージ コレクションが自動的に有効になります。 「ガベージ コレクションの基礎」(ガベージ コレクションの基礎) トピックの「バックグラウンド サーバー ガベージ コレクション」というセクションをご覧ください。

  • マルチコア プロセッサでオプションで使用できるバックグラウンドの Just-in-time (JIT) コンパイルを使用すると、アプリケーションのパフォーマンスが向上します。 「ProfileOptimization」を参照してください。

  • 正規表現エンジンがタイムアウトする前に、正規表現の解決を試みる時間に制限を設ける機能。Regex.MatchTimeout プロパティを参照してください。

  • アプリケーション ドメインの既定のカルチャを定義する機能。 詳細については、CultureInfo クラスのトピックを参照してください。

  • Unicode UTF-16 エンコードのコンソール サポート。 詳細については、Console クラスのトピックを参照してください。

  • カルチャに従った文字列の順序のバージョン指定と比較データのサポート。 詳細については、SortVersion クラスのトピックを参照してください。

  • リソースを取得するときのパフォーマンスを改善します。 リソースをパッケージ化して配置するに関するページを参照してください。

  • Zip 圧縮の機能強化により、圧縮ファイルのサイズが小さくなりました。 System.IO.Compression 名前空間を参照してください。

  • CustomReflectionContext クラスを使用して、既定のリフレクションの動作をオーバーライドするリフレクション コンテキストをカスタマイズできる機能。

  • System.Globalization.IdnMapping クラスを Windows 8 で使用した場合の Internationalized Domain Names in Applications (IDNA) 規格の 2008 バージョンのサポート。

  • オペレーティング システムへの文字列比較の処理代行。 .NET Framework を Windows 8 で使ったときに、Unicode 6.0 が実装されます。 他のプラットフォームで実行されている場合、.NET Framework には、Unicode 5.x. を実装する独自の文字列比較データが含まれています。 String クラスおよび SortVersion クラスの「コメント」セクションを参照してください。

  • アプリケーション ドメインごとに文字列のハッシュ コードを計算する機能。 「<UseRandomizedStringHashAlgorithm> 要素」をご覧ください。

  • Type クラスと TypeInfo クラスで、タイプ リフレクションのサポートが分割されました。 「Windows ストア アプリのための .NET Framework のリフレクション」をご覧ください。

MEF (Managed Extensibility Framework)

.NET Framework 4.5 の MEF (Managed Extensibility Framework) には、次の新機能があります。

  • ジェネリック型のサポート。

  • 属性ではなく命名規則に基づいてパーツを作成できるようにする、規則ベースのプログラミング モデル。

  • 複数のスコープ。

  • Windows 8.x ストア アプリを作成するときに使うことができる MEF のサブセット。 このサブセットは、ダウンロード可能パッケージとして NuGet ギャラリーから入手できます。 パッケージをインストールするには、Visual Studio でプロジェクトを開き、 [プロジェクト] メニューの [NuGet パッケージの管理] をクリックし、Microsoft.Composition パッケージをオンラインで検索します。

詳しくは、「Managed Extensibility Framework (MEF)」を参照してください。

非同期のファイル操作

.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 以降では、Windows 8.x ストア アプリおよびデスクトップ アプリを最適化するために、Mpgo.exe を使うことができます。

並列コンピューティング

.NET Framework 4.5 には、並列計算用の新機能と機能強化がいくつかあります。 パフォーマンスの向上、コントロールの強化、非同期プログラミングのサポートの改善、新しいデータフロー ライブラリ、並列デバッグとパフォーマンス分析のためのサポートの強化などが挙げられます。 .NET での並列プログラミングに関するブログの「What’s New for Parallelism in .NET 4.5」(.NET 4.5 での並列処理の新機能) を参照してください。

Web

ASP.NET 4.5 および 4.5.1 では、Web フォーム モデルのバインディング、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: Internationalized Domain Name) による解析のサポート。 詳細については、Uri および関連クラスを参照してください。

  • 電子メール アドレスの国際化 (EAI) のサポート。 詳細については、「System.Net.Mail」を参照してください。

  • 強化された IPv6 サポート。 詳細については、「System.Net.NetworkInformation」を参照してください。

  • デュアル モードのソケットのサポート。 詳細については、Socket クラスおよび TcpListener クラスを参照してください。

Windows Presentation Foundation (WPF)

.NET Framework 4.5 の WPF (Windows Presentation Foundation) には、次の領域で機能変更および強化があります。

  • クイック アクセス ツール バー、アプリケーション メニューおよびタブをホストするリボン ユーザー インターフェイスを実装できる新しい Ribbon コントロール。

  • 同期および非同期のデータ検証をサポートする新しい INotifyDataErrorInfo インターフェイス。

  • VirtualizingPanel および Dispatcher クラスの新しい機能。

  • グループ化された大量のデータを表示するときに、非 UI スレッドのコレクションにアクセスすることによってパフォーマンスを向上。

  • 静的プロパティへのデータ バインディング、ICustomTypeProvider インターフェイスを実装するカスタム型へのデータ バインディング、およびバインディング式からのデータ バインディング情報の取得。

  • 値の変更に伴うデータの再配置 (ライブ形成)。

  • 項目コンテナーのデータ コンテキストを切断するかどうかをチェックする機能。

  • プロパティの変更とデータ ソースの更新までの経過時間を設定する機能。

  • 弱いイベント パターン実装時のサポートの強化。 また、イベントでマークアップ拡張機能を使用することもできるようになりました。

Windows Communication Foundation (WCF)

.NET Framework 4.5 では、Windows Communication Foundation (WCF) アプリケーションの記述と保守を簡単にするため、次の機能が追加されました。

  • 生成された構成ファイルの簡略化。

  • コントラクト優先開発のサポート。

  • ASP.NET 互換モードをより簡単に構成できる機能。

  • 既定のトランスポート プロパティ値に変更を加え、設定しなければならない可能性を低減しました。

  • XmlDictionaryReaderQuotas クラスを更新して、XML ディクショナリ リーダーのクォータを手動で構成する手間を省けるようにしました。

  • ビルド処理の一部として Visual Studio による WCF 構成ファイルを検証することで、アプリケーションを実行する前に構成エラーを検出できます。

  • 新しい非同期ストリーミングのサポート。

  • Internet Information Services (IIS) での HTTPS 上のエンドポイントを公開しやすくする新しい HTTPS プロトコル マッピング。

  • ?singleWSDL をサービス URL に追加して 1 つの WSDL ドキュメントのメタデータを生成する機能。

  • TCP トランスポートと同様のパフォーマンス特性を持つポート 80 と 443 で真の双方向通信を可能にする Websockets のサポート。

  • コード内の構成サービスのサポート。

  • XML エディターのツール ヒント。

  • ChannelFactory キャッシュのサポート。

  • バイナリ エンコーダーの圧縮サポート。

  • 開発者が「ファイア アンド フォーゲット (撃ち放し)」メッセージングを使用するサービスを作成できるようにする UDP トランスポートのサポート。 クライアントは、サービスにメッセージを送信しますが、サービスからの応答を期待しません。

  • HTTP トランスポートとトランスポート セキュリティを使用したときに、単一の WCF エンドポイントで複数の認証モードをサポートする機能。

  • 国際化ドメイン名 (IDN: Internationalized Domain Name) を使用する WCF サービスのサポート。

詳細については、「Windows Communication Foundation 4.5 の新機能」を参照してください。

Windows Workflow Foundation (WF)

.NET Framework 4.5 では、次に示すいくつかの新機能が Windows Workflow Foundation (WF) に追加されています。

  • 最初に .NET Framework 4.0.1 (.NET Framework 4 Platform Update 1) の一部として導入された、ステート マシンのワークフロー。 この更新プログラムには、開発者がステート マシン ワークフローを作成できるようにする新しいクラスとアクティビティが複数含まれていました。 .NET Framework 4.5 では、これらのクラスとアクティビティが、次を含むように更新されています。

    • 状態でブレークポイントを設定する機能。

    • ワークフロー デザイナーで遷移をコピーして貼り付ける機能。

    • 共有されるトリガーの遷移作成のデザイナー サポート。

    • StateMachine、 State、および Transition などのようにステート マシン ワークフローを作成する機能。

  • 次のようなワークフロー デザイナーの機能が強化されました。

    • [クイック検索] や [フォルダーを指定して検索] など、Visual Studio で強化されたワークフロー検索機能。

    • 2 番目の子アクティビティがコンテナー アクティビティに追加されたときに、自動的にシーケンス アクティビティを作成し、両方のアクティビティをシーケンス アクティビティに含める機能。

    • スクロール バーを使用せずに変更されるワークフローの表示部分を変更できるようにするパン サポート。

    • ツリー スタイルのアウトライン ビューでワークフローのコンポーネントを表示し、 [ドキュメント アウトライン] ビューでコンポーネントを選択できるようにする新しい [ドキュメント アウトライン] ビュー。

    • アクティビティに注釈を追加できる機能。

    • ワークフロー デザイナーでアクティビティ デリゲートを定義および使用する機能。

    • ステート マシンのアクティビティと遷移、およびフローチャート ワークフローの自動接続と自動挿入。

  • ワークフローのビュー状態情報を XAML ファイルの 1 つの要素に保管して、ビュー状態情報を簡単に見つけ、編集できるようにします。

  • 子アクティビティの永続化を防ぐ NoPersistScope コンテナー アクティビティ。

  • C# 式のサポート:

    • Visual Basic を使用するワークフロー プロジェクトは、Visual Basic 式を使用し、C# ワークフロー プロジェクトは C# 式を使用します。

    • Visual Studio 2010 で作成され、Visual Basic 式が使用されている C# ワークフロー プロジェクトは、C# 式を使用する C# ワークフロー プロジェクトと互換性があります。

  • バージョン管理機能の強化

    • 永続化されたワークフロー インスタンスとワークフロー定義間のマッピングを提供する新しい WorkflowIdentity クラス。

    • WorkflowServiceHost を含む同じホスト内の複数のワークフローのバージョンの並列実行。

    • 動的更新プログラムで、永続化されたワークフロー インスタンスの定義を変更する機能。

  • 既存のサービス コントラクトに合わせて自動的にアクティビティを生成するサポートが提供されるコントラクト優先のワークフロー サービス開発。

詳細については、「.NET 4.5 での 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 など) を選択できます。 プロジェクトで使用できる型およびメンバーは、自動的にこれらのプラットフォーム間で共通の型とメンバーに制限されます。 詳細については、ポータブル クラス ライブラリに関するページを参照してください。

関連項目