次の方法で共有

.NET Framework の新機能

  • [アーティクル]

手記

.NET Framework は、セキュリティと信頼性のバグ修正により、Windows 更新プログラムとは別に処理されます。 一般に、セキュリティ更新プログラムは四半期ごとにリリースされます。 .NET Framework は引き続き Windows に含まれており、削除する予定はありません。 .NET Framework アプリを移行する必要はありませんが、新しい開発では.NET 8 以降 使用。

この記事では、次のバージョンの .NET Framework の主な新機能と機能強化について説明します。

この記事では、各新機能に関する包括的な情報は提供せず、変更される可能性があります。 .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 は、Web インストーラーまたはオフライン インストーラーを使用してインストールできます。 ほとんどのユーザーに推奨される方法は、Web インストーラーを使用することです。

Visual Studio 2022 17.3 以降の .NET Framework 4.8.1 を対象とするには、.NET Framework 4.8.1 Developer Packをインストールします。

.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 では、ネイティブ Arm64 のサポートが .NET Framework ファミリに追加されます。 そのため、.NET Framework アプリとライブラリの膨大なエコシステムに投資することで、Arm64 でワークロードをネイティブに実行する利点を活用できるようになりました。つまり、Arm64 でエミュレートされた x64 コードを実行する場合と比べてパフォーマンスが向上します。

Microsoft は、すべての人が 製品とプラットフォームにアクセスできるように提供することに努めています。 .NET Framework 4.8.1 には 2 つの Windows UI 開発プラットフォームが用意されており、どちらも開発者がアクセス可能なアプリケーションを作成するために必要なサポートを提供します。 過去のいくつかのリリースで、Windows フォームと WPF の両方で新機能が追加され、アクセシビリティに関連する多数の信頼性の問題が修正されました。 各リリースで修正または追加された内容の詳細については、「.NET Frameworkのアクセシビリティの新機能」参照してください。

このリリースでは、Windows フォームと WPF の両方でツールヒントの処理が改善され、アクセシビリティが向上しました。 どちらの場合も、ツールチップは、ホバーまたはフォーカスガイダンスに基づくWCAG2.1コンテンツのガイドラインに準拠するようになりました。 ツールヒントの要件は次のとおりです。

  • ツールチップは、マウスのホバーやキーボード操作を使用してコントロールにアクセスすることで表示される必要があります。
  • ツールチップは閉じる必要があります。 つまり、Escのような単純なキーボードコマンドでツールヒントを閉じることができます。
  • ツールチップはホバー可能であるべきです。 ユーザーは、ツールチップの上にマウスカーソルを置くことができます。 これにより、拡大鏡を使用するなどのシナリオで、視覚の弱いユーザーのツールヒントを読み取ることができるようにすることができます。
  • ツールヒントは永続的である必要があります。 ツールヒントは、一定の時間が経過した後に自動的に消えるべきではありません。 代わりに、ユーザーがマウスを別のコントロールに移動するか、キーボード コマンドを使用してツールヒントを閉じる必要があります。

Windows フォームでは、このサポートは Windows 11 以降のオペレーティング システムでのみ使用できます。 Windows FormsはWindows APIの軽量なマネージドラッパーであり、新しいツールチップの動作はWindows 11でのみ利用可能になりました。 WPF には、アクセス可能なツールヒントのオペレーティング システムバージョンの依存関係はありません。

WPF では、.NET Framework 4.8 で WCAG2.1 に準拠したツールヒントのほとんどの要件が実装されていました。 このリリースでは、WPF は、Esc キー、Ctrl キー (単独)、または CtrlShiftF10の組み合わせを使用して、現在のウィンドウのツールヒントを簡単に閉じられるようにすることでエクスペリエンスを向上させました。 このリリースでは、現在のウィンドウにのみ適用されるように、エスケープ キーのスコープが縮小されました。 以前は、開いているアプリケーションのツールヒントに適用されました。

Windows フォームは、.NET Framework 用に作成された最初の Windows UI スタックでした。 そのため、もともとは、現在のアクセシビリティ要件を満たしていないレガシ アクセシビリティ テクノロジを利用するために作成されました。 このリリースでは、Windows フォームでさまざまな問題に対処しました。 アクセシビリティ関連の変更の完全な一覧については、「.NET Frameworkのアクセシビリティの新機能」を参照してください。

.NET Framework 4.8.1 での Windows フォームの機能強化のハイライトは次のとおりです。

  • テキスト パターンのサポート– Windows フォームでは、UIA テキスト パターンのサポートが追加されました。 このパターンにより、支援技術は TextBox または同様のテキストベースのコントロールの内容を一文字ずつ移動できます。 コントロール内でテキストを選択して変更したり、カーソルに新しいテキストを挿入したりできます。 Windows フォームでは、TextBox、DataGridView セル、ComboBox コントロールなどのサポートが追加されました。

  • コントラストの問題に対処する – いくつかのコントロールで、Windows フォームでは、選択した四角形のコントラスト比が暗くなり、見えやすくなっています。

  • 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 は、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 アセンブリは、データ圧縮用のネイティブ外部ライブラリである ZLibを使用して、deflate アルゴリズムの実装を提供します。 clrcompression.dll の .NET Framework 4.8 バージョンが更新され、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

    応答とその HTTP 応答コード {200 – 599} をトリガーする割合 {1 ~ 100} を指定します。 この例では、次の操作を行います。

    • パーセンテージが 95 より大きい場合は、500 HTTP 応答コードが返されます。

    • パーセンテージが 70 ~ 95 の場合は、350 が返されます。

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

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

Windows Presentation Foundation (WPF)

高 DPI の機能強化

.NET Framework 4.8 では、WPF では、Per-Monitor V2 DPI 認識と Mixed-Mode DPI スケーリングのサポートが追加されています。 高 DPI 開発の詳細については、「Windows での高 DPI デスクトップ アプリケーション開発の 」を参照してください。

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

混合モードの高 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 イメージからマップされたデータがメモリ常駐でないように、Native Image Generator (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 パラメーターを持つ 3 つの新しいコンストラクターがあります。 次の例に示すように、開発者は 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 インポートでは、必要に応じて、ハード ドライブをバイパスして、メモリから直接秘密キーを読み込むことができます。 X509Certificate2 コンストラクターまたは X509Certificate2.Import メソッドのいずれかのオーバーロードで新しい X509KeyStorageFlags.EphemeralKeySet フラグを指定すると、秘密キーはエフェメラル キーとして読み込まれます。 これにより、キーがディスクに表示されなくなります。 しかし：

  • キーはディスクに保持されないため、このフラグを使用して読み込まれた証明書は、X509Store に追加するのに適した候補ではありません。

  • この方法で読み込まれたキーは、ほとんどの場合、Windows CNG 経由で読み込まれます。 そのため呼び出し元は、cert.GetRSAPrivateKey() などの拡張メソッドを呼び出すことによって秘密キーにアクセスする必要があります。 X509Certificate2.PrivateKey プロパティは機能しません。

  • レガシ X509Certificate2.PrivateKey プロパティは証明書では機能しないため、開発者はエフェメラル キーに切り替える前に厳格なテストを実行する必要があります。

PKCS#10 証明書署名要求と X.509 公開キー証明書のプログラムによる作成

.NET Framework 4.7.2 以降では、ワークロードで証明書署名要求 (CSP) を生成できます。これにより、証明書要求の生成を既存のツールにステージングできます。 これは、テスト シナリオでよく役立ちます。

詳細とコード例については、.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 以降、Dispose がラップされたストリームを閉じないようにするための追加のコンストラクターが CryptoStream クラスに追加されました。 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 以降では、既定でネイティブ Windows API を使用するように、DeflateStream クラスでの展開操作の実装が変更されました。 通常、この結果、パフォーマンスが大幅に向上します。

.NET Framework 4.7.2 を対象とするアプリケーションでは、Windows API を使用した展開のサポートが既定で有効になっています。 以前のバージョンの .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 が追加されています。 次に示します。

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 アプリケーションを開発する場合は、次のことができます。

  • ハンドラーとモジュールの、Page インスタンスの、および ASP.NET Web アプリケーション プロジェクトの ユーザー コントロールの で、セッターベース、インターフェイス ベース、コンストラクターベースの挿入を使用します。

  • ASP.NET Web サイト プロジェクトの ハンドラーとモジュール、Page インスタンス、およびユーザー コントロール において、セッターベースおよびインターフェースベースの挿入を使用します。

  • 異なる依存関係挿入フレームワークをプラグインします。

SameSite Cookie のサポート

SameSite では、ブラウザーがクロスサイト要求と共に Cookie を送信できなくなります。 .NET Framework 4.7.2 では、値が System.Web.SameSiteMode 列挙メンバーである HttpCookie.SameSite プロパティが追加されます。 値が SameSiteMode.Strict または SameSiteMode.Laxの場合、ASP.NET は set-cookie ヘッダーに SameSite 属性を追加します。 SameSite のサポートは、HttpCookie オブジェクトだけでなく、cookie の 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 Cookie を構成することもできます。

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

Web 構成ファイルを変更することで、Cookie の 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 つのプロパティが追加されました。 ただし、2 つは PlatformNotSupportedException をスローしていました。 .NET Framework 4.7.2 では、これらのプロパティの実装が提供されるようになりました。 プロパティは次のとおりです。

SQLClient

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

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

以前のバージョンの .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 では、エンクレーブベースの 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 の "Edit-and-Continue" 機能などの診断アシスタントは、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

Windows フォーム、Windows Presentation Foundation (WPF)、Visual Studio Tools for Office (VSTO) 用の HDPI 対応アプリケーションはすべて、ClickOnce を使用して配置できます。 アプリケーション マニフェストで次のエントリが見つかった場合、.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 ランタイムおよびコンパイラ機能のブログ記事の「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 とそれに関連付けられているジェネリック型は、シリアル化可能なとしてマークされます。これにより、バイナリ シリアル化が可能になります。 これにより、タプル型 (Tuple<T1,T2,T3> や Tuple<T1,T2,T3,T4>など) を値のタプル型に簡単に移行できるようになります。 詳細については、.NET Framework 4.7.1 ランタイムおよびコンパイラ機能のブログ記事の「コンパイラ -- ValueTuple はシリアル化可能」 参照してください。

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

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

ネットワーキング

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 もサポートされています。 この値が実際に使用されるかどうかは MSMQ によって異なります。Message インスタンス自体はハッシュを行わず、単に 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 オブジェクトを作成し、有効期限やパスなどの Cookie 値を正確に割り当てる標準化された方法を提供する新しいメソッド HttpCookie.TryParseが含まれています。 詳細については、.NET Framework 4.7.1 ASP.NET および構成機能 ブログ記事の「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 構成ファイルで定義できます。

重要

Microsoft では、使用可能な最も安全な認証フローを使用することをお勧めします。 Azure SQL に接続する場合は、Azure リソースのマネージド ID を使用することが推奨される認証方法です。

.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 の変更点の一覧 を参照してください。 詳細については、.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 ファクトリ メソッドを使用して作成しやすいように定義済みの定義が追加されました。

.NET Framework 4.7 暗号化の機能強化の 例を GitHub で 確認できます。

DataContractJsonSerializer による制御文字のサポートの向上

.NET Framework 4.7 では、DataContractJsonSerializer クラスは ECMAScript 6 標準に準拠して制御文字をシリアル化します。 この動作は、.NET Framework 4.7 を対象とするアプリケーションでは既定で有効になっており、.NET Framework 4.7 で実行されているが、以前のバージョンの .NET Framework を対象とするアプリケーションのオプトイン機能です。 詳細については、「アプリケーションの互換性」セクションを参照してください。

ネットワーキング

.NET Framework 4.7 では、次のネットワーク関連機能が追加されています。

TLS プロトコルの既定のオペレーティング システムのサポート*

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

ASP.NET

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

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

.NET Framework 4.7 以降では、ASP.NET は、開発者がメモリ内オブジェクトのキャッシュとメモリ監視の既定の ASP.NET 実装を置き換えることができる新しい API のセットを追加します。 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) では、次の機能と変更が追加されます。

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) メソッドを呼び出すときのシリアル化操作の信頼性が向上しました。
  • ChannelSynchronizer.RemoveWaiter メソッドを呼び出すことで、待機者を削除するときの信頼性が向上しました。

Windows フォーム

.NET Framework 4.7 では、Windows フォームでは高 DPI モニターのサポートが強化されています。

高 DPI サポート

.NET Framework 4.7 を対象とするアプリケーション以降、.NET Framework は 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 の新しい実装

クラスの WPF の印刷 API は、非推奨の XPS Print APIではなく、Windows Print Document Package 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 には次の機能強化が含まれています。

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

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

  1. ValidationAttribute.ErrorMessage は検証属性で提供されます。

  2. リソース ファイルは、App_LocalResources フォルダーに格納されます。

  3. ローカライズされたリソース ファイルの名前には、名という形式があります。ここで、名 は、languageCodecountry/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 の間である必要があります。 評価は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 クラスには、非同期操作をサポートするために使用できる 2 つの新しいメソッド (IsSessionStateReadOnly と IsSessionStateRequired) が含まれています。

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

.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 クラスによる文字の分類と、それに依存する型とメソッドに限定されます。 これには、 クラス、オーバーロードされた メソッド、および .NET Framework 正規表現エンジンによって認識 文字クラスが含まれます。 文字と文字列の比較と並べ替えは、この変更の影響を受けず、基になるオペレーティング システムまたは Windows 7 システムでは、.NET Framework によって提供される文字データに依存し続けます。

Unicode 6.0 から Unicode 7.0 への文字カテゴリの変更については、Unicode コンソーシアム Web サイト Unicode 標準バージョン 7.0.0 を参照してください。 Unicode 7.0 から Unicode 8.0 への変更については、Unicode コンソーシアム Web サイトの Unicode 標準バージョン 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 では、3 つの異なるキー派生関数 (KDF) ルーチンを使用して、楕円曲線 Diffie-Hellman キー アグリーメントのサポートが追加されました。 ルーチンとルーチン自体への入力は、ECDiffieHellmanCng オブジェクトのプロパティを使用して構成されました。 しかし、すべてのルーチンがすべての入力プロパティを読み取るわけではないため、開発者の過去に混乱を招く余地は十分ありました。

.NET Framework 4.6.2 でこれに対処するために、これらの KDF ルーチンとその入力をより明確に表すために、次の 3 つのメソッドが ECDiffieHellman 基底クラスに追加されました。

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 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 キーワードを追加すると、アプリに最適なブロック期間を選択できます。 値は次のとおりです。

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 ファイルの <ランタイム> セクションに次の行を追加します。

<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 されません。

構造とタイム ゾーン調整の詳細については、「タイム ゾーンの概要を参照してください。

NetNamedPipeBinding の最適な一致

WCF には、クライアント アプリケーションで設定できる新しいアプリ設定があり、要求した URI に最も一致する 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 が必要な場合は、次のいずれかの構成メカニズムを使用して、ネゴシエートされたプロトコルの一覧に追加します。

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>

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

タッチ キーボードのサポートにより、テキスト入力を受け取ることができるコントロールがタッチ入力を受け取ったときに、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>

Windows Workflow Foundation (WF)

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

リホスト WF デザイナー での C# 式と IntelliSense のサポート

.NET Framework 4.5 以降、WF は Visual Studio Designer とコード ワークフローの両方で 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 ワークフロー デザイナーで動的更新を使用する場合のワークフローの機能強化を

ワークフロー デザイナー、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 フォームと WPF アプリを UWP アプリに変換する

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

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

デバッグの機能強化

.NET Framework 4.6.2 では、アンマネージド デバッグ API が強化され、NullReferenceException がスローされたときに追加の分析が実行され、ソース コードの 1 行でどの変数が 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 では、Always Encrypted 列マスター キーをハードウェア セキュリティ モジュール (HSM) にネイティブに格納できるようになりました。 このサポートにより、お客様は、カスタム列マスター キー ストア プロバイダーを記述してアプリケーションに登録しなくても、HSM に格納されている非対称キーを利用できます。

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

AlwaysOn の MultiSubnetFailover 接続動作が改善されました

SqlClient では、AlwaysOn 可用性グループ (AG) への高速な接続が自動的に提供されるようになりました。 アプリケーションが別のサブネット上の AlwaysOn 可用性グループ (AG) に接続しているかどうかを透過的に検出し、現在のアクティブなサーバーをすばやく検出し、サーバーへの接続を提供します。 このリリースの前は、アプリケーションが AlwaysOn 可用性グループに接続していることを示すために、"MultisubnetFailover=true" を含むように接続文字列を設定する必要がありました。 接続キーワードを 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 の機能に変更はありません。

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

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

  • 現在の入力言語。

  • 現在のカルチャ。

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

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

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

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

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

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

  • 各行は、(追加および除外された単語リスト内の) 単語、または縦棒 ("|") で区切られた単語を含むオートコレクトペアで構成されている必要があります。(オートコレクトの単語リスト内)。

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

手記

これらの新しいファイル形式は、WPF スペル チェック API では直接サポートされておらず、アプリケーションで WPF に提供されるユーザー辞書では引き続き .lex ファイルを使用する必要があります。

サンプル

Microsoft/WPF-Samples GitHub リポジトリには、多数の WPF サンプルがあります。 pull-request を送信するか、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 配列を提供します。 アプリケーションは、GetPromotedToken メソッドを使用して、MSDTC 以外の昇格されたトランザクションの昇格されたトークンを取得できます。

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

プロファイリング

アンマネージド プロファイリング API は、次のように強化されています。

  • ICorProfilerInfo7 インターフェイス内の PDB へのアクセスのサポートが強化されました。

    ASP.NET Core では、アセンブリが Roslyn によってメモリ内でコンパイルされるのがより一般的になっています。 プロファイリング ツールを作成する開発者にとって、これは、以前はディスク上でシリアル化されていた PDB が存在しなくなった可能性があることを意味します。 プロファイラー ツールは、コードカバレッジや行ごとのパフォーマンス分析などのタスクのために、コードをソース行にマッピングする際に、しばしば PDB を使用します。 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 を含む分析マシンにすべてのモジュールとネイティブ イメージをコピーして、ソースからネイティブへのマッピングを作成します。 このプロセスは、電話アプリケーションなどのファイルが比較的小さい場合に適していますが、デスクトップ システムではファイルが非常に大きく、コピーにかなりの時間が必要になる可能性があります。

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 には、ASP.NET Core が含まれています。これは、最新のクラウドベースのアプリを構築するための無駄のない .NET 実装です。 ASP.NET Core はモジュール式であるため、アプリケーションに必要な機能のみを含めることができます。 IIS でホストすることも、カスタム プロセスでセルフホステッドすることもできます。また、異なるバージョンの .NET Framework を持つアプリを同じサーバー上で実行することもできます。 これには、クラウドデプロイ用に設計された新しい環境構成システムが含まれています。

    MVC、Web API、および Web ページは、MVC 6 と呼ばれる単一のフレームワークに統合されます。 ASP.NET Core アプリは、Visual Studio 2015 以降のツールを使用して構築します。 既存のアプリケーションは、新しい .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 フォーム ページとユーザー コントロールの CRUD ベースのデータ操作に対して、コードに重点を置いた拡張可能なアプローチを可能にするモデル バインド機能を追加しました。 モデル バインド システムでは、Task-returning モデル バインド メソッドがサポートされるようになりました。 この機能を使用すると、Web フォーム開発者は、Entity Framework を含む新しいバージョンの ORM を使用するときに、データ バインディング システムを簡単に使用して非同期のスケーラビリティの利点を得ることができます。

      非同期モデル バインドは、aspnet:EnableAsyncModelBinding 構成設定によって制御されます。

      <appSettings>
    <add key=" aspnet:EnableAsyncModelBinding" value="true|false" />
</appSettings>

      ターゲット .NET Framework 4.6 のアプリでは、既定で trueになります。 以前のバージョンの .NET Framework を対象とする .NET Framework 4.6 で実行されているアプリでは、既定で false。 構成設定を trueに設定することで有効にできます。

    • HTTP/2 サポート (Windows 10)

      HTTP/2 は、接続使用率が大幅に向上する HTTP プロトコルの新しいバージョンです (クライアントとサーバー間のラウンドトリップが少なくなります)。その結果、ユーザーの Web ページの読み込みの待機時間が短縮されます。 1 つのエクスペリエンスの一部として要求される複数の成果物に対してプロトコルが最適化されるため、(サービスではなく) Web ページは HTTP/2 のメリットが最も高まります。 .NET Framework 4.6 の ASP.NET に HTTP/2 のサポートが追加されました。 ネットワーク機能は複数のレイヤーに存在するため、Windows、IIS、および HTTP/2 を有効にする ASP.NET で新機能が必要でした。 ASP.NET で HTTP/2 を使用するには、Windows 10 で実行している必要があります。

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

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

      手記

      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 機能がサポートされるようになりました。 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 アセンブリをアンロードすることで、アセンブリ ローダーがメモリをより効率的に使用できるようになりました。 この変更により、仮想メモリが減少します。これは、大規模な 32 ビット アプリ (Visual Studio など) に特に役立ち、物理メモリも節約します。

  • 基底クラス ライブラリの変更

    主要なシナリオを有効にするために、多くの新しい API が .NET Framework 4.6 に追加されました。 これには、次の変更と追加が含まれます。

    • IReadOnlyCollection<T> implementations

      その他のコレクションは、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

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

      • スイッチ.名前空間.スイッチ名

      • スイッチ。ライブラリ。スイッチ名

    • タスク ベースの非同期パターン (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の 3 つの便利なメソッドが追加され、特定の状態で完了したタスクが返されました。

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

    • EventSource でイベント ログ への書き込みがサポートされるようになりました

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

      NuGet パッケージと .NET Framework 4.6 の両方が、次の機能で更新されました。

      • 動的イベント

        イベント メソッドを作成せずに"オンザフライ" に定義されたイベントを許可します。

      • リッチ ペイロード

        特別に属性付きのクラスと配列、およびプリミティブ型をペイロードとして渡すことができます

      • アクティビティの追跡。

        Start イベントと Stop イベントの間のイベントに、現在アクティブなすべてのアクティビティを表す 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に追加されました。

    • タッチの方が優れています

      .NET Framework 4.6 では、タッチによって予期しない動作が発生する Connect に関する顧客レポートが取り上げられます。 Windows ストア アプリケーションと WPF アプリケーションのダブル タップしきい値は、Windows 8.1 以降で同じになりました。

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

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

  • Windows Communication Foundation (WCF)

    • 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 接続を使用して特定のメッセージを確実に送信できるようになりました。 これを行うには、次の 2 つの方法があります。

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

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

      • さまざまなチャネル ファクトリを使用する

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

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

  • Windows Workflow Foundation (WWF)

    未処理の "非プロトコル" ブックマークがある場合に、要求をタイムアウトする前に、ワークフロー サービスが順不同の操作要求を保持する秒数を指定できるようになりました。 "プロトコル以外" のブックマークは、未処理の受信アクティビティに関連しないブックマークです。 一部のアクティビティでは、実装内にプロトコル以外のブックマークが作成されるため、プロトコル以外のブックマークが存在することは明らかでない場合があります。 これらには、ステートとピックが含まれます。 そのため、ステート マシンで実装されているワークフロー サービスや 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 では、ポートの再利用を有効にするために 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 のサポート

      国際ドメイン名と PunyCode をより適切にサポートするために、Uri クラスに新しいプロパティ IdnHostが追加されました。

  • Windows フォーム コントロールでのサイズ調整。

    この機能は、.NET Framework 4.6 で拡張され、UITypeEditorの描画時に使用される Bounds プロパティで指定された DomainUpDown、NumericUpDown、DataGridViewComboBoxColumn、DataGridViewColumn、ToolStripSplitButton の型、および四角形が含まれています。

    これはオプトイン機能です。 これを有効にするには、EnableWindowsFormsHighDpiAutoResizing 要素をアプリケーション構成 (app.config) ファイルに 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 Nativeを使用したアプリのコンパイル」を参照してください。 .NET Native が JIT コンパイルおよび NGEN とどのように異なり、それがコードにどのように影響するかについての概要については、「.NET ネイティブとコンパイル」を参照してください。

アプリは、Visual Studio 2015 以降でコンパイルすると、既定でネイティブ コードにコンパイルされます。 詳細については、「.NET Native入門」を参照してください。

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

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

    .NET Core パッケージのうち、たとえば不変コレクション、SIMD API、 名前空間にあるネットワーク API などは、現在 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 設定を使用して、次の追加コントロール (コンボ ボックスのドロップダウン矢印など) のコンポーネントのサイズを変更できるようになりました。

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

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

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

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

    • IPromotableSinglePhaseNotification を ISinglePhaseNotificationに置き換えます。これは、単一フェーズコミットをサポートする永続的な参加リストです。

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

  • プロファイリングの機能強化。 次の新しいアンマネージド プロファイリング API は、より堅牢なプロファイリングを提供します。

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

  • デバッグの機能強化。 次の新しいアンマネージド デバッグ API は、プロファイラーとのより優れた統合を提供します。 プロファイラーによって挿入されたメタデータと、ダンプ デバッグ時にコンパイラの ReJIT 要求によって生成されたローカル変数とコードにアクセスできるようになりました。

  • イベント トレースの変更。 .NET Framework 4.5.2 を使用すると、アウトプロセスの Event Tracing for Windows (ETW) ベースのアクティビティ トレースを使用して、より大きな領域を実現できます。 これにより、Advanced Power Management (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 によって以前に作成された参加リストで使用できます。 トランザクションを MSDTC トランザクションに昇格させ、昇格可能な参加リストを永続的な参加リストに "変換" するように System.Transactions に要求します。 このメソッドが正常に完了すると、IPromotableSinglePhaseNotification インターフェイスは System.Transactionsによって参照されなくなり、今後の通知は提供された ISinglePhaseNotification インターフェイスに到着します。 当該の登録は、永続的な登録として機能し、トランザクションのログ記録と回復をサポートする必要があります。 詳細については、Transaction.EnlistDurable を参照してください。 さらに、この参加リストは ISinglePhaseNotification もサポートする必要があります。 このメソッドは、ITransactionPromoter.Promote の呼び出しの処理中にのみ呼び出すことができます。 そうでない場合は、TransactionException 例外がスローされます。

.NET Framework 4.5.1 の新機能

2014年4月の更新:

  • Visual Studio 2013 Update 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 Native は、パフォーマンスを向上させるために、中間言語 (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 プロパティを参照してください。

  • ASP.NET アプリの中断、マルチコア JIT の改善、.NET Framework の更新後のアプリの起動の高速化など、パフォーマンスが向上しました。 詳細については、.NET Framework 4.5.1 のお知らせ を参照してください。ASP.NET アプリはブログ投稿 中断します。

Windows フォームの機能強化は次のとおりです。

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

    • PropertyGrid
    • TreeView
    • の一部の側面 (サポートされる追加のコントロールについては、4.5.2 の新機能 参照)

    この機能を有効にするには、新しい <appSettings> 要素を構成ファイル (app.config) に追加し、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 以降では、Managed Profile Guided Optimization Tool (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 ビット プラットフォームでの 2 ギガバイト (GB) を超える配列のサポート。 この機能は、アプリケーション構成ファイルで有効にすることができます。 gcAllowVeryLargeObjects 要素を参照してください。また、オブジェクト サイズと配列サイズに関するその他の制限も示します。

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

  • バックグラウンド Just-In-Time (JIT) コンパイル。必要に応じて、アプリケーションのパフォーマンスを向上させるためにマルチコア プロセッサで使用できます。 ProfileOptimizationを参照してください。

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

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

  • Unicode (UTF-16) エンコードのコンソール サポート。 Console クラスを参照してください。

  • カルチャ文字列の順序付けと比較データのバージョン管理のサポート。 SortVersion クラスを参照してください。

  • リソースを取得するときのパフォーマンスが向上します。 「パッケージ化してリソースをデプロイする」を参照してください。

  • 圧縮ファイルのサイズを小さくするための Zip 圧縮の機能強化。 System.IO.Compression 名前空間を参照してください。

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

  • Windows 8 で System.Globalization.IdnMapping クラスを使用する場合の、2008 バージョンのアプリケーションでの国際化ドメイン名 (IDNA) 標準のサポート。

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

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

  • 型リフレクションでは、Type クラスと TypeInfo クラス間の分割がサポートされます。 「Reflection in the .NET Framework for Windows Store Apps」(Windows ストア アプリのための .NET Framework のリフレクション) をご覧ください。

Managed Extensibility Framework (MEF、管理可能な拡張性のフレームワーク)

.NET Framework 4.5 では、Managed Extensibility Framework (MEF) に次の新機能が用意されています。

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

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

  • 複数のスコープ。

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

詳細については、「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 以降では、Mpgo.exe を使用して Windows 8.x ストア アプリとデスクトップ アプリを最適化できます。

並列コンピューティング

.NET Framework 4.5 には、並列コンピューティングに関するいくつかの新機能と機能強化が用意されています。 これには、パフォーマンスの向上、制御の強化、非同期プログラミングのサポートの強化、新しいデータフロー ライブラリ、並列デバッグとパフォーマンス分析のサポートの強化が含まれます。 .NET Framework 4.5 の並列処理の新機能 「.NET を使用した並列プログラミング」ブログのエントリを参照してください。

ウェブ

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) 解析のサポート。 詳細については、Uri および関連クラスを参照してください。

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

  • IPv6 のサポートが強化されました。 詳細については、System.Net.NetworkInformation 名前空間を参照してください。

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

Windows Presentation Foundation (WPF)

.NET Framework 4.5 では、Windows Presentation Foundation (WPF) に次の領域の変更と機能強化が含まれています。

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

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

  • VirtualizingPanel クラスと Dispatcher クラスの新機能。

  • 多数のグループ化されたデータセットを表示する場合や、UI 以外のスレッドでコレクションにアクセスする場合のパフォーマンスが向上しました。

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

  • 値の変化に応じてデータの位置を変更する (ライブ シェイプ)。

  • 項目コンテナーのデータ コンテキストが切断されているかどうかを確認する機能。

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

  • 弱いイベント パターンを実装するためのサポートが改善されました。 また、イベントはマークアップ拡張を受け入れることができるようになりました。

Windows Communication Foundation (WCF)

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

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

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

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

  • 既定のトランスポート プロパティ値を変更して、設定する必要がある可能性を減らします。

  • XML ディクショナリ リーダーのクォータを手動で構成する必要が生じる可能性を減らすために、XmlDictionaryReaderQuotas クラスを更新します。

  • ビルド プロセスの一環として Visual Studio による WCF 構成ファイルの検証が行われます。そのため、アプリケーションを実行する前に構成エラーを検出できます。

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

  • インターネット インフォメーション サービス (IIS) を使用して HTTPS 経由でエンドポイントを公開しやすくするための新しい HTTPS プロトコル マッピング。

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

  • Websocket では、TCP トランスポートと同様のパフォーマンス特性を持つポート 80 および 443 経由で真の双方向通信を有効にできます。

  • コードでサービスを構成するためのサポート。

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

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

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

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

  • HTTP トランスポートおよびトランスポート セキュリティを使用する場合に、1 つの WCF エンドポイントで複数の認証モードをサポートする機能。

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

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

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 番目の子アクティビティがコンテナー アクティビティに追加されたときに Sequence アクティビティを自動的に作成し、シーケンス アクティビティに両方のアクティビティを含める機能。

    • パンニングサポートにより、スクロールバーを使用せずにワークフローの表示範囲を変更できます。

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

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

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

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

  • ワークフローのビュー ステート情報を XAML ファイル内の 1 つの要素に格納して、ビュー ステート情報を簡単に見つけて編集できるようにします。

  • 子アクティビティの永続化を防ぐ 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 や .NET for Windows 8.x ストア アプリなど) を選択します。 プロジェクトで使用可能な型とメンバーは、これらのプラットフォーム全体で共通の型とメンバーに自動的に制限されます。 詳細については、「ポータブル クラス ライブラリ」を参照してください。

関連項目