次の方法で共有


.NET Framework の新機能

手記

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

この記事では、次のバージョンの .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、バージョン 21H2、Windows 10 Windows 10 バージョン 21H1、Windows 10 バージョン 20H2、および Windows Server 2022 以降の対応するサーバー プラットフォームにインストールできます。 Web インストーラーまたはオフライン インストーラーを使用して、.NET Framework 4.8.1 をインストールできます。 ほとんどのユーザーに推奨される方法は、Web インストーラーを使用することです。

.NET Framework 4.8.1 Visual Studio 2022 17.3 以降では、.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 フォームは、Windows API の軽量マネージドラッパーであり、新しいツールチップの動作はWindows 11でのみ利用可能になりました。 WPFには、アクセス可能なツールヒントのオペレーティング システムバージョンの依存関係はありません。

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

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

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

  • Text パターンのサポート – WINDOWS FORMS 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 Visual Studio 2012 以降では、.NET Framework 4.8 Developer Pack をインストールすることでターゲットにすることができます。

.NET Framework 4.8 の新機能

.NET Framework 4.8 では、次の領域に新機能が導入されています。

アプリケーションが支援技術のユーザーに適切なエクスペリエンスを提供できるようにするアクセシビリティの向上は、引き続き .NET Framework 4.8 の主要な焦点です。 .NET Framework 4.8 のアクセシビリティの向上については、「.NET Framework のアクセシビリティの新機能を参照してください。

基底クラス

暗号での FIPS への影響の低下。 以前のバージョンの .NET Framework では、SHA256Managed などのマネージド暗号化プロバイダー クラスは、システム暗号化ライブラリが "FIPS モード" で構成されている場合に、CryptographicException をスローします。 これらの例外がスローされるのは、暗号化プロバイダー クラスのマネージド バージョンは、システムの暗号化ライブラリとは異なり、FIPS (Federal Information Processing Standards) 140-2 の認定を受けていないためです。 開発用マシンを FIPS モードにしている開発者はほとんどいないため、本番環境では例外が発生します。

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

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

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

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

Windows Communication Foundation (WCF)

ServiceHealthBehavior の概要

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

ServiceHealthBehavior は、を拡張する WCF サービスの動作です。 コレクションに追加すると、サービスの動作によって次の処理が実行されます。

  • HTTP 応答コードを使用してサービスの正常性状態を返します。 HTTP/GET 正常性プローブ要求の HTTP 状態コードをクエリ文字列で指定できます。

  • サービス正常性に関する情報を公開します。 サービスの状態、スロットル数、容量などのサービス固有の詳細は、 クエリ文字列と共に 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>
    

サービスの正常性状態は、、、、) などのクエリ パラメーターを使用して照会でき、クエリ パラメーターごとに HTTP 応答コードを指定できます。 クエリ パラメーターに対して HTTP 応答コードを省略すると、既定で 503 HTTP 応答コードが使用されます。 例えば:

  • サービスエラー時:

    ServiceHost.State が より大きい場合、450 HTTP 応答状態コードが返されます。

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

  • OnDispatcherFailure:

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

  • OnListenerFailure:

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

  • スロットルパーセント超過時:

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

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

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

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

サービスの正常性状態は、 などのクエリ文字列を指定して HTML で表示するか、などのクエリ文字列を指定して XML で表示できます。 のようなクエリ文字列は、空の HTML ページを返します。

Windows Presentation Foundation (WPF)

高 DPI の機能強化

.NET Framework 4.8 では、WPFでは、Per-Monitor V2 DPI 認識と Mixed-Mode DPI スケーリングのサポートが追加されました。 高 DPI 開発の詳細については、「High DPI Desktop Application Development on Windows」を参照してください。

.NET Framework 4.8 では、Mixed-Mode DPI スケーリングをサポートするプラットフォーム (2018 年 4 月更新Windows 10以降) 上の 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 またはサード パーティのマルウェア対策ソフトウェアを使用して、ディスクから読み込まれたすべてのアセンブリをスキャンします。 ただし、 メソッドなど、他のソースから読み込まれたアセンブリはスキャンされず、検出されないマルウェアが含まれている可能性があります。 Windows 10で実行されている .NET Framework 4.8 以降、ランタイムは、Antimalware Scan Interface (AMSI) を実装するマルウェア対策ソリューションによるスキャンをトリガーします。

.NET Framework 4.7.2 の新機能

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

  • 基底クラス
  • ASP.NET
  • ネットワーク
  • SQL
  • WPF
  • ClickOnce

.NET Framework 4.7.2 の継続的な焦点は、アクセシビリティの向上です。これにより、アプリケーションは支援技術のユーザーに適切なエクスペリエンスを提供できます。 .NET Framework 4.7.2 のアクセシビリティの向上については、「 .NET Framework のアクセシビリティの新機能を参照してください。

基底クラス

.NET Framework 4.7.2 には、多数の暗号化拡張機能、ZIP アーカイブのより優れた展開サポート、および追加のコレクション API が用意されています。

RSA.Create および DSA.Create の新しいオーバーロード

メソッドと メソッドを使用すると、新しい または キーをインスタンス化するときにキー パラメーターを指定できます。 これにより、次のようなコードを置き換えることができます。

// 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

メソッドと メソッドを使用すると、特定のキー サイズで新しい または キーを生成できます。 例えば:

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 コンストラクターは、ハッシュ アルゴリズムの名前を受け入れる

クラスには、キーの派生時に使用する HMAC アルゴリズムを識別する パラメーターを持つ 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 インポートでは、必要に応じて、ハード ドライブをバイパスして、メモリから直接秘密キーを読み込むことができます。  コンストラクターまたは メソッドのいずれかのオーバーロードで新しい フラグを指定すると、秘密キーはエフェメラル キーとして読み込まれます。 これにより、キーがディスクに表示されなくなります。 しかし:

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

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

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

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

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

詳細とコード例については、.NET ブログの「PKCS#10 認定署名要求と X.509 公開キー証明書のプログラムによる作成」を参照してください。

新しい SignerInfo メンバー

.NET Framework 4.7.2 以降では、SignerInfo クラスはシグネチャに関する詳細情報を公開します。 プロパティの値を取得して、署名者が使用する署名アルゴリズムを決定できます。 呼び出して、この署名者の暗号署名のコピーを取得できます。

CryptoStream が破棄された後にラップされたストリームを開いたままにする

.NET Framework 4.7.2 以降、CryptoStream クラスには、ラップされたストリームを閉じないようにDisposeを許可する追加のコンストラクターがあります。  インスタンスが破棄された後、ラップされたストリームを開いたままにするには、次のように新しい コンストラクターを呼び出します。

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 クラスでの展開操作の実装が変更されました。 通常、この結果、パフォーマンスが大幅に向上します。

Windows API を使用した展開のサポートは、.NET Framework 4.7.2 を対象とするアプリケーションに対して既定で有効になっています。 以前のバージョンの .NET Framework を対象としているが、.NET Framework 4.7.2 で実行されているアプリケーションは、次のAppContext スイッチをアプリケーション構成ファイルに追加することで、この動作をオプトインできます。

<AppContextSwitchOverrides value="Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=false" />

追加のコレクション API

.NET Framework 4.7.2 では、SortedSet<T> 型と HashSet<T> 型に多数の新しい API が追加されます。 次に示します。

  • メソッド。他のコレクション型で使用される try パターンをこれら 2 つの型に拡張します。 メソッドは次のとおりです。

    • public bool HashSetT.TryGetValue(T equalValue, out T actualValue)
    • public bool SortedSetT.TryGetValue(T equalValue, out T actualValue)
  • 拡張メソッド。コレクションを に変換します。

    • public static HashSetTSource ToHashSetTSource(この IEnumerableTSource ソース)
    • public static HashSetTSource ToHashSetTSource(this IEnumerableTSource source, IEqualityComparerTSource comparer)
  • コレクションの容量を設定できる新しい コンストラクター。これは、 のサイズが事前にわかっている場合にパフォーマンス上の利点をもたらします。

    • public HashSet(int capacity)
    • public ハッシュセット(int 容量, IEqualityComparerT 比較子)

クラスには、ディクショナリから値を取得するか、見つからない場合に追加するため、またはディクショナリに値を追加するか、既に存在する場合に更新するための、 メソッドと メソッドの新しいオーバーロードが含まれています。

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

SameSite Cookie のサポート

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

オブジェクトの 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 の と に 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 つは をスローしていました。 .NET Framework 4.7.2 では、これらのプロパティの実装が提供されるようになりました。 プロパティは次のとおりです。

SQLClient

Azure Active Directoryによるユニバーサル認証および多要素認証のサポート

コンプライアンスとセキュリティの需要が高まっている場合、多くのお客様が多要素認証 (MFA) を使用する必要があります。 さらに、現在のベスト プラクティスでは、ユーザー パスワードを接続文字列に直接含めずにすることをお勧めします。 これらの変更をサポートするために、.NET Framework 4.7.2 は、MFA と Azure AD Authentication< をサポートする既存の "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 名前空間に次の型とメンバーが追加されます。

  • 。エンクレーブ ベースの Always Encrypted の URI を指定します。

  • 。これは、すべてのエンクレーブ プロバイダーの派生元となる抽象クラスです。

  • 。特定のエンクレーブ セッションの状態をカプセル化します。

  • SqlEnclaveAttestationParameters。特定の構成証明プロトコルを実行するために必要な情報を取得するためにSQL Serverで使用される構成証明パラメーターを提供します。

アプリケーション構成ファイルは、エンクレーブ プロバイダーの機能を提供する抽象 クラスの具象実装を指定します。 例えば:

<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 における元のマークアップを編集する診断アシスタントは、新しい機能を使用してディクショナリを特定できます。 この機能は、新しい静的メソッドによって実装されます。 診断アシスタントは、次のコードに示すように、元のマークアップを識別する絶対 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"))

このメソッドは、 が有効で、 環境変数が設定されていない限り、空の列挙可能な値を返します。

ResourceDictionary の所有者を見つける

.NET Framework 4.7.2 以降では、診断アシスタントは特定の ResourceDictionary の所有者を見つけることができます。 (この機能は、運用アプリケーションではなく診断アシスタントで使用されます)。ResourceDictionaryに変更が加えられると、WPFは変更の影響を受ける可能性があるすべての DynamicResource 参照を自動的に検索します。

Visual Studioの "エディット コンティニュ" 機能などの診断アシスタントでは、これを拡張して、StaticResource 参照を処理できます。 このプロセスの最初の手順は、辞書の所有者を見つけることです。つまり、 プロパティがディクショナリを参照しているすべてのオブジェクトを検索します (直接、または プロパティを介して間接的に)。 System.Windows.Diagnostics.ResourceDictionaryDiagnostics クラスに実装された 3 つの新しい静的メソッド (Resources プロパティを持つ基本型ごとに 1 つ) は、この手順をサポートします。

これらのメソッドは、 が有効で、 環境変数が設定されていない限り、空の列挙可能な値を返します。

StaticResource 参照の検索

StaticResource 参照が解決されるたびに、診断アシスタントが通知を受信できるようになりました。 (この機能は、運用アプリケーションではなく、診断アシスタントで使用されます)。Visual Studioの "エディット コンティニュ" 機能などの診断アシスタントでは、ResourceDictionary の値が変更されたときに、リソースのすべての使用を更新できます。 WPFは、DynamicResource 参照に対して自動的にこれを行いますが、StaticResource 参照では意図的に行われません。 .NET Framework 4.7.2 以降では、診断アシスタントはこれらの通知を使用して、静的リソースの使用を特定できます。

通知は、新しい イベントによって実装されます。

public static event EventHandler<StaticResourceResolvedEventArgs> StaticResourceResolved;
Public Shared Event StaticResourceResolved As EventHandler(Of StaticResourceResolvedEventArgs)

このイベントは、ランタイムが StaticResource 参照を解決するたびに発生します。  引数は解決を記述し、StaticResource 参照をホストするオブジェクトとプロパティ、および解決に使用される とキーを示します。

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

が有効で、 環境変数が設定されていない限り、イベントは発生しません (およびその アクセサーは無視されます)。

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 には、次の領域の新機能が含まれています。

  • 基底クラス
  • 共通言語ランタイム (CLR)
  • ネットワーク
  • ASP.NET

さらに、.NET Framework 4.7.1 の主な焦点はアクセシビリティの向上です。これにより、アプリケーションは支援技術のユーザーに適切なエクスペリエンスを提供できます。 .NET Framework 4.7.1 のアクセシビリティの向上については、「 .NET Framework のアクセシビリティの新機能を参照してください。

基底クラス

Support for .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 から欠落している ababout 200 API を追加します。 (これらのバージョンの .NET Framework では、追加の .NET Standard サポート ファイルがターゲット システムにも展開されている場合にのみ、Standard 2.0 .NETがサポートされることに注意してください)。詳細については、.NET Framework 4.7.1 ランタイムおよびコンパイラ機能ブログ記事の「BCL - .NET Standard 2.0 サポート」を参照してください。

構成ビルダーのサポート

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

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

ランタイム機能の検出

System.Runtime.CompilerServices.RuntimeFeature クラスは、コンパイル時または実行時に特定の.NET実装で定義済みの機能がサポートされているかどうかを判断するためのメカニズムを提供します。 コンパイル時に、コンパイラは、指定されたフィールドが存在するかどうかを確認して、機能がサポートされているかどうかを判断できます。その場合は、その機能を利用するコードを出力できます。 実行時に、アプリケーションは実行時にコードを出力する前に メソッドを呼び出すことができます。 詳細については、「ヘルパー メソッドを追加する」を参照して、ランタイムでサポートされる機能について説明します。

値のタプル型はシリアル化が可能

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

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

.NET Framework 4.7.1 では、System.Runtime.CompilerServices.IsReadOnlyAttributeが追加されます。 この属性は、読み取り専用 ref 戻り値の型またはパラメーターを持つメンバーをマークするために、言語コンパイラによって使用されます。 詳細については、ブログ記事「.NET Framework 4.7.1 ランタイムおよびコンパイラ機能のコンパイラ -- ReadOnlyReferences のサポートを参照してください。 ref 戻り値の詳細については、「Ref 戻り値およびref locals および 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.Md5HashAlgorithm.Sha の値のみがサポートされています。 .NET Framework 4.7.1 以降では、HashAlgorithm.Sha256HashAlgorithm.Sha384、および HashAlgorithm.Sha512 もサポートされています。 この値が実際に使用されるかどうかは MSMQ によって異なります。 インスタンス自体はハッシュを行わず、単に MSMQ に値を渡すだけなのでです。 詳細については、ブログ記事「.NET Framework 4.7.1 ASP.NET および構成機能の「Message.HashAlgorithm の SHA-2 サポート」セクションを参照してください。

ASP.NET

ASP.NET アプリケーションの実行手順

ASP.NET は、23 個のイベントを含む定義済みのパイプラインで要求を処理します。 ASP.NET は、各イベント ハンドラーを実行ステップとして実行します。 .NET Framework 4.7 までのバージョンの ASP.NET では、ネイティブ スレッドとマネージド スレッドの切り替えにより、ASP.NET は実行コンテキストをフローできません。 ASP.NET は、HttpContext のみを選択的に転送します。 .NET Framework 4.7.1 以降では、HttpApplication.OnExecuteRequestStep(Action<HttpContextBase,Action>) メソッドを使用して、モジュールでアンビエント データを復元することもできます。 この機能は、アプリケーションの実行フローを考慮する、トレース、プロファイリング、診断、またはトランザクションなどに関連するライブラリを対象とします。 詳細については、.NET Framework 4.7.1 ASP.NET および構成機能ブログ記事の「ASP.NET 実行ステップ機能」を参照してください。

ASP.NET HttpCookie 解析

.NET Framework 4.7.1 には、文字列から HttpCookie.TryParse オブジェクトを作成し、有効期限やパスなどの Cookie 値を正確に割り当てるための標準化された方法を提供する、HttpCookie という新しいメソッドが含まれています。 詳細については、ブログ記事「.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 ブログの「Announcing .NET Framework 4.7 を参照してください。

基底クラス

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

楕円曲線暗号 (ECC) を使用した機能の強化

.NET Framework 4.7 では、ImportParameters(ECParameters) メソッドが ECDsa クラスと ECDiffieHellman クラスに追加され、オブジェクトが既に確立されているキーを表せるようにしました。 明示的な曲線パラメーターを使用してキーをエクスポートするための メソッドも追加されました。

.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 プロトコルの既定のオペレーティング システムのサポート

TLS スタックは、HTTP、FTP、SMTP などの コンポーネントとアップスタック コンポーネントによって使用され、開発者はオペレーティング システムでサポートされている既定の 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 の合計で不足している場合に通知します。 これらの制限に近づいた場合は、通知が送信されます。 一部のアプリケーションでは、通知が構成された制限にあまりにも近すぎて、有用な反応が困難になります。 開発者は、独自のメモリ モニターを作成して、 プロパティを使用して既定値を置き換えることができるようになりました。

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

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の呼び出しで非同期コードと同期コードを混在させるサポートが強化されました。
  • と DuplexChannelBinder との接続を中止するときの信頼性が向上しました。
  • メソッドを呼び出すときのシリアル化操作の信頼性が向上しました。
  • 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 サポートを追加する方法の詳細については、「high DPI support in Windows フォーム」を参照してください。

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 ブログの「Announcing .NET Framework 4.6.2 を参照してください。

ASP.NET

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

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

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

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

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

  3. ローカライズされたリソース ファイルの名前には、という形式があります。ここで、 は、languageCodecountry/regionCode または languageCode形式のカルチャ名です。

  4. リソースのキー名は、 属性に割り当てられた文字列であり、その値はローカライズされたエラー メッセージです。

たとえば、次のデータ注釈属性は、無効な評価の既定のカルチャのエラー メッセージを定義します。

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 を作成できます。このファイルのキーはエラー メッセージ文字列であり、その値はローカライズされたエラー メッセージです。 ファイルは、 フォルダーに存在する必要があります。 たとえば、ローカライズされたフランス語 (fr) 言語のエラー メッセージのキーとその値を次に示します。

名前 価値
評価は 1 から 10 の間である必要があります。 評価は1から10の間でなければなりません。

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

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

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

さらに、 クラスには、非同期操作をサポートするために使用できる 2 つの新しいメソッド ( と ) が含まれています。

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

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

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

  • クラス。 から継承され、開発者は非同期出力キャッシュ プロバイダーを実装できます。

  • クラス。出力キャッシュを構成するためのヘルパー メソッドを提供します。

  • クラスの 18 個の新しいメソッド。 これには、、、、、、、、、、、、、、、および が含まれます。

  • クラスの 2 つの新しいメソッド: と 。

  • クラスの 2 つの新しいメソッド: と 。

  • クラスの 2 つの新しいメソッド: と 。

  • クラスでは、 メソッド。

  • の メソッド。

文字カテゴリ

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

.NET Framework 4.6 の RSA クラスと、.NET Framework 4.6.1 の ECDsa クラスに対する最近の変更に合わせて、.NET Framework 4.6.2 の DSA 抽象基底クラスには、呼び出し元がこの機能をキャストせずに使用できるようにする追加のメソッドがあります。 次の例に示すように、 拡張メソッドを呼び出してデータに署名できます。

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

また、次の例に示すように、 拡張メソッドを呼び出して、署名されたデータを確認できます。

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 キー アグリーメントのサポートが追加されました。 ルーチンとルーチン自体への入力は、 オブジェクトのプロパティを使用して構成されました。 しかし、すべてのルーチンがすべての入力プロパティを読み取るわけではないため、開発者の過去に混乱を招く余地は十分ありました。

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

ECDiffieHellman メソッド 説明
DeriveKeyFromHash(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[]) 数式を使用してキー マテリアルを派生させる

HASH(secretPrepend || x || secretAppend)

HASH(secretPrepend または x または secretAppend)

ここで、x は EC Diffie-Hellman アルゴリズムの計算結果です。
DeriveKeyFromHmac(ECDiffieHellmanPublicKey, HashAlgorithmName, Byte[], Byte[], Byte[]) 数式を使用してキー マテリアルを派生させる

HMAC(hmacKey, secretPrepend || x ||secretAppend)

HMAC(hmacKey, シークレットプレペンド OrElse x OrElse シークレットアペンド)

ここで、x は EC Diffie-Hellman アルゴリズムの計算結果です。
DeriveKeyTls(ECDiffieHellmanPublicKey, Byte[], Byte[]) TLS 擬似ランダム関数 (PRF) 派生アルゴリズムを使用してキー マテリアルを派生させます。

永続化キー対称暗号化 のサポート

Windows暗号化ライブラリ (CNG) では、永続化された対称キーの格納と、ハードウェアに格納された対称キーの使用のサポートが追加され、.NET Framework 4.6.2 により、開発者はこの機能を利用できるようになりました。 キー名とキー プロバイダーの概念は実装固有であるため、この機能を使用するには、推奨されるファクトリ アプローチ (の呼び出しなど) ではなく、具象実装型のコンストラクターを使用する必要があります。

AES () アルゴリズムと 3DES () アルゴリズムには、永続化キー対称暗号化のサポートが存在します。 例えば:

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 フィールド 定数
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"

これらのアルゴリズムのサポートを追加するためにカスタム ハンドラーを に登録したプログラムは、これまでと同様に機能し続けますが、プラットフォームの既定値が表示されるため、 の登録は不要になりました。

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 データベースに接続する場合、通常は迅速に復旧される一時的なエラーで接続試行が失敗する可能性があるため、この動作は望ましくありません。 接続の再試行エクスペリエンスをより適切に最適化するために、Azure SQL データベースへの接続が失敗すると、接続プールのブロック期間の動作が削除されます。

新しい キーワードを追加すると、アプリに最適なブロック期間を選択できます。 値は次のとおりです。

Auto

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

  • .database.windows.net

  • .database.chinacloudapi.cn

  • .database.usgovcloudapi.net

  • .database.cloudapi.de

AlwaysBlock

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

NeverBlock

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

Always Encrypted の強化

SQLClient では、Always Encrypted に次の 2 つの機能強化が導入されています。

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

  • キー キャッシュ内の列暗号化キー エントリは、 プロパティを使用して設定された構成可能な時間間隔の後に削除されるようになりました。

Windows Communication Foundation

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

CNG を使用して格納された証明書に対する WCF トランスポートセキュリティサポート

WCF トランスポート セキュリティでは、Windows暗号化ライブラリ (CNG) を使用して格納された証明書がサポートされます。 .NET Framework 4.6.2 では、このサポートは、32 ビット以下の指数を持つ公開キーを持つ証明書の使用に限定されます。 アプリケーションが Framework 4.6.2 .NETターゲットの場合、この機能は既定でオンになっています。

.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 クラス による複数の夏時間調整規則のサポートが向上しました

お客様は、アプリケーション構成設定を使用して、 クラスが 1 つのタイム ゾーンに対して複数の調整規則をサポートしているかどうかを判断できます。 これはオプトイン機能です。 有効にするには、app.config ファイルに次の設定を追加します。

<runtime>
     <AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseTimeZoneInfo=false" />
</runtime>

この機能を有効にすると、 オブジェクトは 型ではなく 型を使用して日付と時刻のデータを逆シリアル化します。 では複数の調整ルールがサポートされているため、履歴タイム ゾーン データを操作できます。 されません。

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

NetNamedPipeBinding の最適な一致

WCF には、クライアント アプリケーションで設定できる新しいアプリ設定があり、要求した URI に最も一致する URI をリッスンしているサービスに常に接続するようにします。 このアプリ設定を (既定値) に設定すると、 を使用するクライアントは、要求された URI の部分文字列である URI でリッスンしているサービスへの接続を試みることができる可能性があります。

たとえば、クライアントは、でリッスンしているサービスに接続しようとしますが、管理者特権で実行されているそのマシン上の別のサービスは、でリッスンしています。 このアプリ設定を に設定すると、クライアントは間違ったサービスへの接続を試みます。 アプリ設定を に設定すると、クライアントは常に最適なサービスに接続します。

手記

を使用するクライアントは、完全なエンドポイント アドレスではなく、サービスのベース アドレス (存在する場合) に基づいてサービスを検索します。 この設定が常に機能するように、サービスは一意のベース アドレスを使用する必要があります。

この変更を有効にするには、クライアント アプリケーションの App.config または Web.config ファイルに次のアプリ設定を追加します。

<configuration>
    <appSettings>
        <add key="wcf:useBestMatchNamedPipeUri" value="true" />
    </appSettings>
</configuration>

SSL 3.0 は既定のプロトコル ではありません

トランスポート セキュリティと資格情報の種類の証明書で NetTcp を使用する場合、SSL 3.0 はセキュリティで保護された接続のネゴシエートに使用される既定のプロトコルではなくなりました。 TLS 1.0 は NetTcp のプロトコル一覧に含まれているため、ほとんどの場合、既存のアプリに影響はありません。 既存のすべてのクライアントは、少なくとも TLS 1.0 を使用して接続をネゴシエートできる必要があります。 Ssl3 が必要な場合は、次のいずれかの構成メカニズムを使用して、ネゴシエートされたプロトコルの一覧に追加します。

  • プロパティ

  • プロパティ

  • netTcpBinding セクションの transport セクション

  • customBinding セクションの sslStreamSecurity セクション

Windows Presentation Foundation (WPF)

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

グループの並べ替え

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

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

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

たとえば、次の 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 で実行されているアプリの場合は、次のように、アプリケーション構成ファイルの <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 ワークフロー デザイナーで動的更新を使用するときのワークフローの機能強化

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

  • ワークフロー デザイナーで XAML ファイルを正しく読み込めませんでした ( が行の末尾にある場合)。

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

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 デバイスで使用できるようになります。

デバッグの機能強化

管理されていないデバッグ API は、.NET Framework 4.6.2 で強化され、NullReferenceException がスローされたときに追加の分析を実行し、ソース コードの 1 行のどの変数が null であるかを判断できるようにしました。 このシナリオをサポートするために、次の API がアンマネージド デバッグ API に追加されています。

  • ICorDebugCode4ICorDebugVariableHome、およびマネージド変数のネイティブ ホームを公開する ICorDebugVariableHomeEnum インターフェイス 。 これにより、デバッガーは、 が発生したときにコード フロー分析を実行し、後方に動作して、されたネイティブの場所に対応するマネージド変数を特定できます。

  • 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 キー ストア プロバイダーをアプリ サーバーまたはクライアント コンピューターにインストールする必要があります。

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

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

Windows Presentation Foundation (WPF)

Windows Presentation Foundationには、多くの機能強化と変更が含まれています。

パフォーマンスの向上

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

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

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

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

  • (存在する場合)。

  • 現在の入力言語。

  • 現在のカルチャ。

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サンプルがあります。 プル要求を送信するか、GitHubの問題を開くことで、サンプルの改善に役立ちます。

DirectX 拡張機能

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

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

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

MSDTC 以外のトランザクション プロモーターが登録されると、定義されているプロトコルに従って、将来の永続的な登録にも使用しなければなりません。 トランザクションプロモーターの は、 プロパティを使用することによって得ることができる。 トランザクションが昇格されると、トランザクション プロモーターは昇格されたトークンを表す 配列を提供します。 アプリケーションは、 メソッドを使用して、MSDTC 以外の昇格されたトランザクションの昇格されたトークンを取得できます。

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

プロファイリング

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

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

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

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

    動的インストルメンテーションに API ReJit 機能を使用しているプロファイラーで、一部のメタデータを変更できるようになりました。 以前は、このようなツールはいつでも IL をインストルメント化できましたが、メタデータはモジュールの読み込み時にのみ変更できました。 IL はメタデータを参照するため、実行できるインストルメンテーションの種類が制限されます。 これらの制限の一部を解除するには、モジュールの読み込み後にメタデータ編集のサブセットをサポートする ICorProfilerInfo7::ApplyMetaData メソッドを追加しました。特に、新しい 、、、、、および レコードを追加します。 この変更により、より広範なオンザフライ インストルメンテーションが可能になります。

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

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

Ngen PDB を使用すると、NGen は IL PDB に依存することなく、IL からネイティブへのマッピングを含む PDB を作成できます。 マシン間イベント トレース シナリオでは、マシン A によって生成されたネイティブ イメージ PDB をマシン B にコピーし、デバッグ インターフェイス アクセス API を使用して IL PDB のソースto-IL マッピングとネイティブ イメージ PDB の IL からネイティブ へのマッピングを読み取る必要があります。 両方のマッピングを組み合わせると、ソースからネイティブへのマッピングが提供されます。 ネイティブ イメージ PDB は、すべてのモジュールとネイティブ イメージよりもはるかに小さいため、マシン A からマシン B にコピーするプロセスははるかに高速です。

.NET 2015 の新機能

.NET 2015 では、.NET Framework 4.6 と .NET Core が導入されています。 一部の新機能は両方に適用され、その他の機能は .NET Framework 4.6 または .NET Core に固有です。

  • ASP.NET Core

    .NET 2015 には 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 Updates

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

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

    • モデル バインドでは、タスクを返すメソッドがサポート

      .NET Framework 4.5 では、ASP.NET Web フォーム ページとユーザー コントロールでの CRUD ベースのデータ操作に対して、拡張可能なコードに重点を置いたアプローチを有効にするモデル バインド機能を追加しました。 モデル バインド システムでは、-returning モデル バインド メソッドがサポートされるようになりました。 この機能を使用すると、Web フォーム開発者は、Entity Framework を含む新しいバージョンの ORM を使用するときに、データ バインディング システムを簡単に使用して非同期のスケーラビリティの利点を得ることができます。

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

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

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

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

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

      <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 コンパイラには、 名前空間で SIMD 対応型と組み合わせたときのハードウェア SIMD アクセラレーション機能も含まれており、パフォーマンスが向上する可能性があります。

  • アセンブリ ローダーの機能強化

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

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

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

    • IReadOnlyCollectionT 実装

      その他のコレクションは、 や などの を実装します。

    • CultureInfo.CurrentCulture と CultureInfo.CurrentUICulture

      プロパティと プロパティは、読み取り専用ではなく、読み取り/書き込み可能になりました。 これらのプロパティに新しい オブジェクトを割り当てると、 プロパティで定義されている現在のスレッド カルチャと、 プロパティで定義されている現在の UI スレッド カルチャも変更されます。

    • ガベージ コレクション (GC) の機能強化

      クラスには、クリティカル パスの実行中にガベージ コレクションを許可しない メソッドと メソッドが含まれるようになりました。

      メソッドの新しいオーバーロードを使用すると、小さなオブジェクト ヒープと大きなオブジェクト ヒープの両方をスイープして圧縮するか、スイープのみを実行するかを制御できます。

    • SIMD 対応型

      名前空間には、、、、、、、など、多くの SIMD 対応型が含まれるようになりました。

      新しい 64 ビット JIT コンパイラにはハードウェア SIMD アクセラレーション機能も含まれているため、新しい 64 ビット JIT コンパイラで SIMD 対応型を使用すると、特にパフォーマンスが大幅に向上します。

    • 暗号化の更新

      System.Security.Cryptography API は、Windows CNG 暗号化 API をサポートするように更新されています。 以前のバージョンの .NET Framework は、実装の基礎として完全に以前のバージョンの Windows 暗号化 API に依存していました。 CNG API は、特定のカテゴリのアプリにとって重要な 最新の暗号アルゴリズムをサポートしているため、CNG API をサポートする要求がありました。

      .NET Framework 4.6 には、Windows CNG 暗号化 API をサポートするための次の新しい機能強化が含まれています。

      • 可能な限り CAPI ベースの実装ではなく、CNG ベースの実装を返す X509 証明書、、および の拡張メソッドのセット。 (一部のスマートカードなどでは引き続き CAPI が必要であり、API はフォールバックを処理します)。

      • rsa アルゴリズムの CNG 実装を提供する クラス。

      • 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 時刻との間での日付と時刻の値の変換をサポートするために、 構造体に追加されました。

    • 互換性スイッチ

      クラスは、ライブラリ ライターがユーザーの新機能に対して統一されたオプトアウト メカニズムを提供できるようにする新しい互換性機能を追加します。 オプトアウト要求を通信するために、コンポーネント間で疎結合コントラクトを確立します。 この機能は、通常、既存の機能に変更が加えられた場合に重要です。 逆に、新しい機能の暗黙的なオプトインが既に存在します。

      では、ライブラリは互換性スイッチを定義して公開しますが、それらに依存するコードは、ライブラリの動作に影響を与えるスイッチを設定できます。 既定では、ライブラリは新しい機能を提供し、スイッチが設定されている場合にのみ変更します (つまり、以前の機能を提供します)。

      アプリケーション (またはライブラリ) は、依存ライブラリが定義するスイッチ (常に 値) の値を宣言できます。 スイッチは常に暗黙的に です。 スイッチを に設定すると有効になります。 スイッチを明示的に に設定すると、新しい動作が提供されます。

      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 を対象としていないアプリの動作は影響を受けません。 詳細については、「 クラス」トピックの「カルチャとタスクベースの非同期操作」セクションを参照してください。

      クラスを使用すると、特定の非同期制御フローに対してローカルなアンビエント データ ( メソッドなど) を表すことができます。 これを使用して、スレッド間でデータを保持できます。 プロパティが明示的に変更されたか、スレッドでコンテキスト遷移が発生したためにアンビエント データが変更されるたびに通知されるコールバック メソッドを定義することもできます。

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

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

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

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

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

      • 動的イベント

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

      • リッチ ペイロード

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

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

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

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

  • Windows Presentation Foundation (WPF)

    • HDPI 機能強化

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

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

      異なる DPI 設定 (マルチ DPI セットアップ) を持つ複数のモニターにまたがるWPFウィンドウが、領域を黒くせずに完全にレンダリングされるようになりました。 この動作を無効にするには、app.config ファイルの セクションに次の行を追加して、この新しい動作を無効にします。

      <add key="EnableMultiMonitorDisplayClipping" value="true"/>
      

      DPI 設定に基づいて右カーソルを自動的に読み込むためのサポートが System.Windows.Input.Cursor に追加されました。

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

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

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

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

  • Windows Communication Foundation (WCF)

    • SSL のサポート

      WCF では、トランスポート セキュリティとクライアント認証で NetTcp を使用する場合、SSL 3.0 と TLS 1.0 に加えて、SSL バージョン TLS 1.1 と TLS 1.2 がサポートされるようになりました。 使用するプロトコルを選択したり、古い安全性の低いプロトコルを無効にしたりできるようになりました。 これを行うには、 プロパティを設定するか、構成ファイルに次を追加します。

      <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 接続を使用して送信されます。 プレフィックスを設定するには、メッセージの プロパティにキーと値のペアを追加します。 キーは "HttpTransportConnectionGroupNamePrefix" です。値は目的のプレフィックスです。

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

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

        <appSettings>
            <add key="wcf:httpTransportBinding:useUniqueConnectionPoolPerFactory" value="true" />
        </appSettings>
        
  • Windows Workflow Foundation (WWF)

    未処理の "非プロトコル" ブックマークがある場合に、要求をタイムアウトする前に、ワークフロー サービスが順不同の操作要求を保持する秒数を指定できるようになりました。 "プロトコル以外" のブックマークは、未処理の受信アクティビティに関連しないブックマークです。 一部のアクティビティでは、実装内にプロトコル以外のブックマークが作成されるため、プロトコル以外のブックマークが存在することは明らかでない場合があります。 これらには、ステートとピックが含まれます。 そのため、ステート マシンで実装されているワークフロー サービスや Pick アクティビティを含むワークフロー サービスがある場合は、プロトコル以外のブックマークが作成される可能性が高くなります。 間隔を指定するには、app.config ファイルの セクションに次のような行を追加します。

    <add key="microsoft:WorkflowServices:FilterResumeTimeoutInSeconds" value="60"/>
    

    既定値は 60 秒です。 が 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.
    

    これは、順不同の操作メッセージが受信され、プロトコル以外のブックマークがない場合に受信するメッセージと同じです。

    要素の値が 0 以外で、プロトコル以外のブックマークがあり、タイムアウト間隔が経過すると、操作はタイムアウト メッセージで失敗します。

  • トランザクション

    から派生した例外がスローされる原因となったトランザクションに、分散トランザクション識別子を含めることができるようになりました。 これを行うには、app.config ファイルの セクションに次のキーを追加します。

    <add key="Transactions:IncludeDistributedTransactionIdInExceptionMessage" value="true"/>
    

    既定値は です。

  • ネットワーク

    • ソケットの再利用

      Windows 10には、送信 TCP 接続用にローカル ポートを再利用することで、コンピューター リソースをより適切に使用する、スケーラビリティの高い新しいネットワーク アルゴリズムが含まれています。 .NET Framework 4.6 では、新しいアルゴリズムがサポートされているため、.NET アプリで新しい動作を利用できます。 以前のバージョンのWindowsでは、人為的な同時接続の制限 (通常は動的ポート範囲の既定のサイズである 16,384) がありました。これは、負荷がかかっているときにポート枯渇を引き起こすことによってサービスのスケーラビリティを制限する可能性がありました。

      .NET Framework 4.6 では、ポートの再利用を有効にするために 2 つの API が追加されています。これにより、同時接続の 64 KB の制限が実質的に削除されます。

      • 列挙型値。

      • プロパティ。

      既定では、 レジストリ キーの 値が 0x1 に設定されていない限り、 プロパティは されます。 HTTP 接続でローカル ポートの再利用を有効にするには、 プロパティを に設定します。 これにより、HttpClient および HttpWebRequest からのすべての送信 TCP ソケット接続で、ローカル ポートの再利用を可能にする新しい Windows 10 ソケット オプション SO_REUSE_UNICASTPORT が使用されます。

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

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

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

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

    この機能は、DomainUpDownNumericUpDownDataGridViewComboBoxColumnDataGridViewColumnToolStripSplitButton 型を含むように .NET Framework 4.6 で拡張されました。また、UITypeEditor を描画する際に使用される Bounds プロパティで指定された四角形も含まれています。

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

    <appSettings>
        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
    </appSettings>
    
  • コード ページ エンコードのサポート

    .NET Core は主に Unicode エンコードをサポートしており、既定ではコード ページ エンコードのサポートが制限されています。 Encoding.RegisterProvider メソッドを使用してコード ページ エンコードを登録することで、.NET Framework で使用できるが、.NET Core ではサポートされていないコード ページ エンコードのサポートを追加できます。 詳細については、を参照してください。

  • .NET Native

C# または Visual Basic で記述されたユニバーサル Windows プラットフォーム (UWP) アプリは、IL ではなくネイティブ コードにアプリをコンパイルする新しいテクノロジを利用できます。 このテクノロジにより、起動時間と実行時間が短縮されるアプリが生成されます。 詳細については、「ネイティブを使用したアプリ.NETのコンパイル」を参照してください。 JIT コンパイルと NGEN の両方との違い、およびコードの意味を調べる .NET Native の概要については、「.NET Native と Compilationを参照してください。

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

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

  • Open-source .NET Framework パッケージ

    .NET不変コレクション、SIMD APISystem.Net.Http 名前空間にあるようなネットワーク API などのコア パッケージは、GitHub でオープンソース パッケージとして使用できるようになりました。 コードにアクセスするには、GitHub の .NET を参照してください。 これらのパッケージに貢献する方法についての詳細は、はじめに.NETおよびGitHub上の.NETホームページを参照してください。

.NET Framework 4.5.2 の新機能

  • ASP.NET アプリ用の新しい API。 新しい メソッドと メソッドを使用すると、応答がクライアント アプリにフラッシュされるときに、応答ヘッダーと状態コードを検査および変更できます。 イベントや イベントの代わりに、これらのメソッドを使用することを検討してください。より効率的で信頼性の高い製品です。

    メソッドを使用すると、小さなバックグラウンド作業項目をスケジュールできます。 ASP.NET は、これらの項目を追跡し、すべてのバックグラウンド作業項目が完了するまで IIS がワーカー プロセスを突然終了するのを防ぎます。 このメソッドは、ASP.NET マネージド アプリ ドメインの外部では呼び出すことはできません。

    新しい プロパティと プロパティは、応答ヘッダーが書き込まれたかどうかを示すブール値を返します。 これらのプロパティを使用して、 (ヘッダーが書き込まれた場合に例外をスローする) などの API の呼び出しが成功することを確認できます。

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

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

    <appSettings>
        <add key="EnableWindowsFormsHighDpiAutoResizing" value="true" />
    </appSettings>
    
  • 新しいワークフロー機能。 メソッドを使用している (そのため、 インターフェイスを実装する) リソース マネージャーは、新しい メソッドを使用して次を要求できます。

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

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

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

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

    • COR_PRF_ASSEMBLY_REFERENCE_INFO 構造体
    • COR_PRF_HIGH_MONITOR 列挙型
    • GetAssemblyReferences メソッド
    • GetEventMask2 メソッド
    • SetEventMask2 メソッド
    • AddAssemblyReference メソッド

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

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

    • SetWriteableMetadataUpdateMode メソッド
    • EnumerateLocalVariablesEx メソッド
    • GetLocalVariableEx メソッド
    • GetCodeEx メソッド
    • GetActiveReJitRequestILCode メソッド
    • GetInstrumentedILMap メソッド
  • イベント トレースの変更。 .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
    

    このメソッドは、 メソッドに応答して によって以前に作成された参加リストで使用できます。 トランザクションを MSDTC トランザクションに昇格させ、昇格可能な参加リストを永続的な参加リストに "変換" するように に要求します。 このメソッドが正常に完了すると、 インターフェイスは によって参照されなくなり、今後の通知は提供された インターフェイスに到着します。 当該の登録は、永続的な登録として機能し、トランザクションのログ記録と回復をサポートする必要があります。 詳細については、 を参照してください。 さらに、この参加リストは もサポートする必要があります。 このメソッドは、 の呼び出しの処理中に呼び出すことができます。 そうでない場合は、 例外がスローされます。

.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 を使用できます。

    • ポータブルライブラリに XAML 型 (Windows.UI.XAML 型) を含めることができるのは、ターゲットが Windows 8.1 または Windows Phone 8.1 の場合です。 次の XAML テンプレートがサポートされています:空白ページ、リソース ディクショナリ、テンプレート コントロール、およびユーザー コントロール。

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

    • ポータブル クラス ライブラリのように、Windows ストアまたは Windows Phone ストアのクラス ライブラリをターゲットの変更が可能です。

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

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

  • .NET Framework リファレンス ソースは、新しい閲覧エクスペリエンスと強化された機能を提供します。 これで、.NET Framework のソース コードをオンラインで参照し、デバッグ中にソース(パッチや更新プログラムを含む)をステップ実行し、参照用にダウンロードしてオフラインで閲覧できるようになりました。 詳細については、ブログ エントリ 参照ソースを参照してください。

.NET Framework 4.5.1 の基底クラスの新機能と機能強化は次のとおりです。

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

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

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

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

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

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

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

    この機能を有効にするには、構成ファイル (app.config) に新しい 要素を追加し、 要素を に設定します。

    <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) を超える配列のサポート。 この機能は、アプリケーション構成ファイルで有効にすることができます。 要素を参照してください。この要素には、オブジェクト サイズと配列サイズに関するその他の制限も示されています。

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

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

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

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

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

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

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

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

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

  • Windows 8でSystem.Globalization.IdnMappingクラスを使用する際の、2008年版の国際化ドメイン名 (IDNA) 標準への対応。

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

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

  • 型リフレクションでは、 クラスと クラス間の分割がサポートされます。 Windows ストア アプリ用 .NET Framework のReflectionを参照してください。

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

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

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

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

  • 複数のスコープ。

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

詳細については、「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ブログの「並列プログラミング」を参照してください。

Web

ASP.NET 4.5 および 4.5.1 では、Web フォーム、WebSocket のサポート、非同期ハンドラー、パフォーマンスの強化、およびその他の多くの機能のモデル バインドが追加されます。 詳細については、次のリソースを参照してください。

ネットワーク

.NET Framework 4.5 には、HTTP アプリケーション用の新しいプログラミング インターフェイスが用意されています。 詳細については、新しい と 名前空間を参照してください。

既存の および関連クラスを使用して WebSocket 接続を受け入れて対話するための新しいプログラミング インターフェイスのサポートも含まれています。 詳細については、新しい 名前空間と クラスを参照してください。

さらに、.NET Framework 4.5 には、次のネットワークの機能強化が含まれています。

  • RFC 準拠 URI のサポート。 詳細については、 および関連クラスを参照してください。

  • 国際化ドメイン名 (IDN) 解析のサポート。 詳細については、 および関連クラスを参照してください。

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

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

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

Windows Presentation Foundation (WPF)

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

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

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

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

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

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

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

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

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

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

Windows Communication Foundation (WCF)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 開発者が "ファイア アンド フォーゲット" メッセージングを使用するサービスを記述できるようにする 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 プラットフォーム更新プログラム 1) の一部として初めて導入されました。 この更新プログラムには、開発者がステート マシン ワークフローを作成できる新しいクラスとアクティビティがいくつか含まれていました。 .NET Framework 4.5 では、次のクラスとアクティビティが更新されました。

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

    • ワークフロー デザイナーで画面切り替えをコピーして貼り付ける機能。

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

    • ステート マシン ワークフローを作成するためのアクティビティ(、、など)。

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

    • Quick FindFind in Files など、Visual Studioのワークフロー検索機能が強化されました。

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

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

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

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

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

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

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

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

  • C# 式のサポート:

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

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

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

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

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

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

  • コントラクト優先のワークフロー サービス開発。既存のサービス コントラクトに一致するアクティビティを自動的に生成するためのサポートを提供します。

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

.NET を使用した Windows 8.x ストア アプリ

Windows 8.x ストア アプリは、特定のフォーム ファクター用に設計されており、Windows オペレーティング システムの機能を活用します。 .NET Framework 4.5 または 4.5.1 のサブセットは、C# またはVisual Basicを使用してWindows用の Windows 8.x ストア アプリを構築するために使用できます。 このサブセットは、Windows 8.x ストア アプリの.NETと呼ばれ、overview で説明されています。

ポータブルクラスライブラリ

Visual Studio 2012 (以降のバージョン) のポータブル クラス ライブラリ プロジェクトを使用すると、複数の .NET Framework プラットフォームで動作するマネージド アセンブリを作成およびビルドできます。 ポータブル クラス ライブラリ プロジェクトを使用して、ターゲットにするプラットフォーム (Windows Phone や Windows 8.x ストア アプリの.NETなど) を選択します。 プロジェクトで使用可能な型とメンバーは、これらのプラットフォーム全体で共通の型とメンバーに自動的に制限されます。 詳細については、「ポータブル クラス ライブラリ」を参照してください。

関連項目