このたび、.NET Framework 4.6.2 がリリースされました。今回の変更点の多くは、UserVoice (英語) や Connect (英語) などに寄せられた皆様からのフィードバックを反映したものです。皆様の継続的なご支援とご協力に感謝いたします。
このリリースでは、以下の分野で多数の機能強化が実施されました。
すべての変更点の一覧については、.NET Framework 4.6.2 の変更リスト (英語) および API の差分 (英語) をご確認ください。
今すぐダウンロード
.NET Framework 4.6.2 は以下のリンクからダウンロード可能です。
基本クラス ライブラリ (BCL)
BCL では、以下の機能強化が実施されています。
長いパスのサポート (MAXPATH)
System.IO API において、最長 260 文字 (MAXPATH) というファイル名の文字数制限 (英語) が修正されました。この問題については、UserVoice に 4,500 を超える投票がありました。
この制限は通常、コンシューマー向けアプリケーションでは問題になりません (マイ ドキュメント フォルダーからファイルを読み込む場合など)。しかし、開発者のマシンで深くネストされたソース ツリーを構築したり、(長いパスが一般的に使用される) Unix でも動作する特別なツールを使用したりする場合には、この制限の影響を受ける可能性があります。
この新機能は、ターゲット フレームワークが .NET Framework 4.6.2 (またはそれ以降) のアプリケーションで有効化されます。アプリケーションの構成によって .NET Framework 4.6.2 をターゲットに指定するには、app.config または web.config 構成ファイルで以下のように設定します。
以前のバージョンの .NET Framework をターゲットとするアプリケーションでこの機能を使用するには、以下の構成ファイルのように AppContext スイッチを設定します。このスイッチは、アプリケーションが .NET Framework 4.6.2 (またはそれ以降) で実行される場合にのみ適用されます。
.NET Framework 4.6.2 をターゲットに指定していない場合や AppContext スイッチを設定していない場合は、MAXPATH より長いパスは使用できないという従来の動作になります。この動作は、既存のアプリケーションとの下位互換性を保持するために有効化されています。
長いパスを有効にするために、以下の点が強化されました。
- 260 文字 (MAX_PATH) を超えるパスの許可: BCL で MAX_PATH (英語) より長いパスが許可されます。BCL API は、基盤となる Win32 ファイルの API を使用して制限のチェックを行います。
- 拡張パス構文およびファイル名前空間 (\\?\、\\.\) の有効化: Windows では、拡張パス構文などの代替パス スキーマを可能にする複数のファイル名前空間 (英語) が提供されており、32,000 文字強のパスを使用できます。今回、そのようなパス (\\?\very long path など) が BCL でサポートされました。.NET Framework では、有効なパスを誤ってブロックすることがないように、パスの正規化に主に Windows API を使用し、“真の情報源” として扱っています。拡張パス構文は、通常の形式 (“C:\very long path” など) の長いパスをサポートしないバージョンの Windows では便利な回避策となります。
- パフォーマンスの強化: Windows のパス正規化を導入し、BCL に含まれる類似のロジックを減らしたことで、ファイル パスに関するロジック全体のパフォーマンスが向上しました。また、この他にもパフォーマンスを高めるための機能強化がいくつか実施されています。
今回の変更の詳細については、Jeremy Kuhne のブログ (英語) をご覧ください。
X509 証明書で FIPS 186-3 デジタル署名アルゴリズムをサポート
.NET Framework 4.6.2 では、FIPS 186-3 (英語) デジタル署名アルゴリズム (DSA) のサポートが追加されました。FIPS 186-3 では、キーのサイズが 1,024 ビットを超える X509 証明書がサポートされるほか、SHA-2 ファミリのハッシュ アルゴリズム (SHA256、SHA384、SHA512) による署名の計算が可能になります。
.NET Framework 4.6.1 では FIPS 186-2 (英語) をサポートします。FIPS 186-2 では、キーのサイズが最大 1,024 ビットに制限されます。
FIPS 186-3 のサポートを利用するには、以下の例のように、新しい DSACng クラスを使用します。
また、DSA 基本クラスも更新され、新しい DSACng クラスにキャストしなくても FIPS 186-3 のサポートを利用できるようになりました。これは、.NET Framework の前々回および前回のリリースでそれぞれ RSA と ECDsa の実装が更新されたときと同じアプローチです。
楕円曲線 Diffie-Hellman のキー派生ルーチンをより使いやすく
ECDiffieHellmanCng クラスがより使いやすくなりました。.NET Framework の ECDH (楕円曲線 Diffie-Hellman) キー合意の実装には 3 種類の KDF (キー派生関数) ルーチンが含まれます。以下の例のように、これらの KDF ルーチンが 3 種類のメソッドで表現およびサポートされるようになりました。
以前のバージョンの .NET Framework では、この 3 種類の各ルーチンについて、ECDiffieHellmanCng クラスに設定するプロパティのサブセットを把握しておく必要がありました。
永続化されたキーによる対称暗号化をサポート
Windows の暗号化ライブラリ (CNG) では、永続化された対称キーのソフトウェアとハードウェア デバイスでの格納がサポートされています。以下の例のように、.NET Framework 4.6.2 でもこの CNG 機能が提供されるようになりました。
キー名とキー プロバイダーは実装ごとに異なるため、この新機能を使用するには、一般的に使用されるファクトリの手法 (Aes.Create() など) ではなく、具体的な実装クラス (AesCng など) を使用する必要があります。
永続化されたキーによる対称暗号化は、AES アルゴリズム (AesCng クラス) および 3DES アルゴリズム (TripleDESCng クラス) に追加されています。
SignedXml で SHA-2 ハッシュをサポート
.NET Framework SignedXml 実装では、以下の SHA-2 ハッシュ アルゴリズムが新たにサポートされました。
以下の例では、XML の署名に SHA-256 を使用しています。
新しい SignedXML URI 定数は新しい SignedXml フィールドとして追加されています。新しいフィールドは以下に示すとおりです。
これまでカスタムの SignatureDescription ハンドラーを CryptoConfig に登録してこれらのアルゴリズムをサポートしていたプログラムは、すべて従来どおりに動作します。しかし、プラットフォームによって既定でサポートされるようになったため、CryptoConfig への登録は不要になります。
共通言語ランタイム (CLR)
CLR では、以下の機能強化が実施されています。
NullReferenceException の機能強化
NullReferenceException が発生し、その原因を調査した経験がある方は多いでしょう。.NET Framework チームは現在 Visual Studio チームと協力し、Visual Studio の今後のリリースで null 参照をデバッグしやすくするための取り組みを行っています。
Visual Studio でのデバッグ処理は、作成されたコードとの下層レベルでの対話に共通言語ランタイムのデバッグ API を使用します。現在、Visual Studio で NullReferenceException が発生した場合には以下のようなメッセージが表示されます。
![null_ref]()
今回のリリースでは、CLR のデバッグ API が強化され、NullReferenceException の発生時にデバッガーがより多くの情報を要求し、より詳細な分析を行うようになりました。デバッガーは取得した情報を基に null である参照を判断し、その情報を提示するため、デバッグ処理が簡単になります。
ClickOnce
ClickOnce では、以下の機能強化が実施されています。
Transport Layer Security (TLS) 1.1 および 1.2 のサポート
.NET Framework バージョン 4.6.2、4.6.1、4.6、4.5.2 の ClickOnce に TLS 1.1 および 1.2 プロトコルのサポートが追加されました。UserVoice (英語) で投票してくださった皆様にお礼を申し上げます。ClickOnce は、実行時にどの TLS プロトコルが必要であるかを自動的に検出するため、TLS 1.1 または 1.2 プロトコルのサポートを有効化するために必要な操作は特にありません。
Secure Sockets Layer (SSL) および TLS 1.0 は現在、一部の組織で非推奨またはサポート対象外となっています。たとえば、PCI SSC (Payment Card Industry Security Standards Council) では、オンライン取引の仕様を満たすために TLS 1.1 以降の義務化 (英語) を進めています。
ClickOnce では、アプリケーションをアップグレードできない場合にも互換性を維持できるように引き続き TLS 1.0 をサポートしますが、SSL および TLS 1.0 を使用しているすべてのアプリケーションを調査することをお勧めします。.NET Framework の修正プログラムをダウンロードするリンクについては、サポート技術情報の記事 (バージョン 4.6、4.6.1 (英語)、4.5.2) を参照してください。
クライアント証明書のサポート
SSL が有効化され、クライアント証明書が要求される仮想ディレクトリで ClickOnce アプリケーションをホストできるようになりました。このような構成の場合、エンド ユーザーがアプリケーションにアクセスすると、証明書の選択を求めるメッセージが表示されます。[Client Certificates] が “Ignore” に設定されている場合には、証明書を求めるメッセージは表示されません。
以前のバージョンでは、アプリケーションがこのような構成でホストされる場合、ClickOnce による展開を実行すると、アクセス拒否エラーが発生して終了します。
![clickonce_ssl]()
ASP.NET
ASP.NET では、以下の機能強化が実施されています。ASP.NET Core の機能強化については、ASP.NET Core 1.0 の発表 (英語) に関するブログ記事をご覧ください。
DataAnnotation のローカライズ
モデル バインディングと DataAnnotation による検証を使用する場合のローカライズが非常に簡単になりました。ASP.NET では、DataAnnotation 検証メッセージを格納する resx リソース ファイルについて、以下のようなわかりやすい規則を採用しています。
- App_LocalResources フォルダーに配置する。
- DataAnnotation.Localization.{locale}.resx という命名規則に従う。
.NET Framework 4.6.2 を使用する場合、ローカライズされていないアプリケーション (英語) と同じように、DataAnnotation 属性をモデル ファイルで指定します。ErrorMessage には、以下の例のように、resx ファイルで使用する名前を指定します。
![asp.net_dataAnnotation_localization]()
以下の例に示すように、ローカライズされた resx ファイルは新しい規則に従って App_LocalResources フォルダーに配置されます。
![asp.net_dataAnnotation]()
独自の文字列ローカライズ プロバイダーを組み込み、ローカライズした文字列を別の場所や別の種類のファイルに格納することもできます。
以前のバージョンの .NET Framework では、以下の例のように、ErrorMessageResourceType と ErrorMessageResourceName の値を指定する必要がありました。
非同期処理の機能強化
SessionStateModule と OutputCache モジュールの強化により、非同期シナリオがサポートされました。現在、各モジュールの非同期バージョンを NuGet からリリースできるように作業を進めています。これらの NuGet パッケージは、既存プロジェクトにインポートする必要があり、数週間以内のリリースを予定しています。リリース時にはこの記事を更新します。
SessionStateModule インターフェイス
Session State を使用すると、ユーザーが ASP.NET サイト内を移動するときに、ユーザーのセッション データを格納および取得できます。今回、新しい ISessionStateModule インターフェイスを使用して、独自の非同期の SessionStateModule 実装を作成できるようになりました。これにより、セッション データを独自の方法で格納したり、非同期メソッドを使用したりできます。
OutputCache モジュール
出力キャッシュ (英語) を使用すると、コントローラーのアクションから返された結果がキャッシュされ、すべての要求に対して同一のコンテンツが不必要に生成されなくなるため、ASP.NET アプリケーションのパフォーマンスが大幅に向上します。
今回、OutputCacheProviderAsync という新しいインターフェイスが実装され、出力キャッシュに非同期 API を使用できるようになりました。これにより、Web サーバーでのスレッドのブロックが減り、ASP.NET サービスのスケーラビリティが向上します。
SQL
SQL クライアントでは、以下の機能強化が実施されています。
Always Encrypted の強化
Always Encrypted は、データベースに格納されたクレジット カード番号や身分登録番号などの機密データを保護するために設計された機能です。 Always Encrypted を使用すると、クライアントはデータベース エンジンに暗号化キーを開示することなく、クライアント アプリケーション内の機密データを暗号化することができます。結果として、Always Encrypted ではデータの所有者 (閲覧できるユーザー) とデータの管理者 (アクセス許可は付与しないユーザー) を区別できます。
.NET Framework Data Provider for SQL Server (System.Data.SqlClient) では、Always Encrypted のパフォーマンスとセキュリティの 2 点について重要な機能強化が行われました。
パフォーマンス
暗号化されたデータベース列に対するパラメーター化クエリのパフォーマンス向上のために、クエリ パラメーターの暗号化メタデータがキャッシュされるようになりました。SqlConnection::ColumnEncryptionQueryMetadataCacheEnabled (英語) プロパティが true (既定値) に設定されている場合には、同じクエリが複数回呼び出されても、データベース クライアントがサーバーからパラメーターのメタデータを取得するのは 1 回だけで済みます。
セキュリティ
キー キャッシュに格納された列暗号化キーのエントリは、設定した時間の経過後に消去されるようになりました。消去されるまでの時間は、SqlConnection::ColumnEncryptionKeyCacheTtl (英語) プロパティを使用して設定できます。
Windows Communication Foundation (WCF)
WCF では、以下の機能強化が実施されています。
NetNamedPipeBinding の “最適な一致”
.NET Framework 4.6.2 では、NetNamedPipeBinding が強化され、“最適な一致” と呼ばれる新しいパイプの検索方法がサポートされました。“最適な一致” を使用する場合、NetNamedPipeBinding サービスは、最初に一致したサービスではなく、要求されたエンドポイントと最も一致する URI をリッスンしているサービスを検索するようにクライアントに強制します。
“最適な一致” のパイプは、既定の動作である “最初の一致” を使用すると WCF クライアント アプリケーションが誤った URI に接続してしまう場合に特に役立ちます。名前付きパイプ上で複数の WCF サービスがリッスンしている場合、“最初の一致” を使用している WCF クライアントは誤ったサービスに接続する可能性があります。この問題は、1 つの管理者アカウントで複数のサービスがホストされている場合に発生します。
この機能を有効化するには、以下の AppSetting をクライアント アプリケーションの app.config ファイルまたは web.config ファイルに追加します。
DataContractJsonSerializer の機能強化
DataContractJsonSerializer が強化され、複数の夏時間調整ルールが適切にサポートされるようになりました。この機能を有効化すると、DataContractJsonSerializer は TimeZone クラスの代わりにTimeZoneInfo クラスを使用します。TimeZoneInfo クラスは複数の調整ルールをサポートするため、過去のタイム ゾーン データを処理できます。この機能は、(UTC+2) イスタンブールのように、1 つのタイム ゾーンに複数の夏時間調整ルールがある場合に役立ちます。
この機能を有効化するには、以下の AppSetting を app.config ファイルに追加します。
TransportDefaults による SSL 3 のサポート終了
トランスポート セキュリティに NetTcp を使用し、証明書の資格情報の種類を使用する場合に、安全な接続のネゴシエーションに使用される既定のプロトコルから SSL 3 プロトコルが除外されました。NetTcp のすべての既定のプロトコル リストには TLS 1.0 が含まれているため、既存のアプリケーションへの影響はほとんどないと考えられます。すべての既存のクライアントは、TLS 1.0 以降を使用して接続をネゴシエートできます。
SSL 3 が既定のプロトコルから除外されたのは、安全と見なされなくなったためです。推奨はされませんが、必要に応じて以下の構成メカニズムのいずれかを使用して、ネゴシエートされたプロトコルの一覧に SSL 3 を再び追加することができます。
Windows 暗号化ライブラリ (CNG) のトランスポート セキュリティ
トランスポート セキュリティでは、Windows 暗号化ライブラリ (CNG) を使用して格納された証明書が新たにサポートされました。現時点では、このサポートは公開キーの指数の長さが 32 ビット以下の証明書を使用する場合に限定されます。
この新機能は、ターゲット フレームワークが .NET Framework 4.6.2 (またはそれ以降) のアプリケーションで有効化されます。アプリケーションの構成によって .NET Framework 4.6.2 をターゲットに指定するには、app.config または web.config 構成ファイルで以下のように設定します。
以前のバージョンの .NET Framework をターゲットとするアプリケーションでこの機能を使用するには、以下の構成ファイルのように AppContext スイッチを設定します。このスイッチは、アプリケーションが .NET Framework 4.6.2 (またはそれ以降) で実行される場合にのみ適用されます。
この機能は、以下のようにプログラムから有効化することもできます。
OperationContext.Current の非同期処理の機能強化
WCF では、ExecutionContext に OperationContext.Current を追加して、OperationContext を非同期の後続処理に渡すことができるようになりました。この機能強化により、スレッド間で CurrentContext を伝達できます。そのため、コンテキスト スイッチをはさんで OperationContext.Current を 2 回呼び出した場合にも、値はメソッドの実行中に常に正しく渡されます。
以下の例では、スレッドの切り替えの前後で OperationContext.Current が正しく渡されます。
これまで、OperationContext.Current の内部実装では CurrentContext を格納するために ThreadStatic 変数を使用していました。ThreadStatic 変数は、CurrentContext に関連付けられたデータをスレッドのローカル ストレージに格納します。メソッド呼び出しの実行コンテキストが変更された場合 (別の処理の待機によってスレッドが変更される場合など)、その後の呼び出しは、元の値を参照することなく別のスレッドで実行されます。今回の修正により、threadId1 と threadId2 が異なる場合でも、2 回目の OperationContext.Current の呼び出しによって想定した値が返されます。
Windows Presentation Foundation (WPF)
WPF では、以下の機能強化が実施されています。
グループの並べ替え
CollectionView を要求してデータをグループ化するアプリケーションで、グループを並べ替える方法を明示的に宣言できるようになりました。今回の機能強化により、アプリケーションによってグループが動的に追加または削除されたり、グループ化に関係する項目プロパティの値が変更されたりした場合に想定した順序にならないという問題が解決されます。また、グループ化プロパティの比較がコレクション全体の並べ替えから各グループの並べ替えに変更されるため、グループ作成処理のパフォーマンスも向上します。
この機能の GroupDescription クラスには、SortDescriptions と CustomSort という 2 つの新しいプロパティが追加されました。これらのプロパティは、GroupDescription によって生成されたグループのコレクションを並べ替える方法を示します。これは、ListCollectionView の同名のプロパティがデータ項目を並べ替える方法を示すのと同様です。また、PropertyGroupDescription クラスにも、CompareNameAscending と CompareNameDescending という新しい静的プロパティが追加されました。これらのプロパティは、一般的なケースで使用することができます。
たとえば、Age によってデータをグループ化し、作成されたグループを昇順に並べ替え、各グループ内の項目は LastName で並べ替えるとします。
今回の新機能により、以下のように宣言することができます。
この機能が追加される以前は、以下のように宣言していました。
Per-Monitor DPI のサポート
WPF アプリケーションが Per-Monitor DPI に対応しました。この機能強化は、DPI レベルの異なる複数のディスプレイを 1 台のマシンに接続する場合に重要になります。WPF アプリケーションの一部または全体を複数のモニター間で移動する場合に、WPF によってアプリケーションの DPI がディスプレイに合わせて自動的に変更されるようになりました。
WPF アプリケーションで Per-Monitor DPI を有効にする方法の詳細については、GitHub の WPF のサンプルおよび開発者向けガイド (英語) を参照してください。
以前のバージョンでは、WPF アプリケーションで Per-Monitor DPI を有効にするには追加のネイティブ コード (英語) を記述する必要がありました。
ソフト キーボードのサポート
ソフト キーボードのサポートにより、Windows 10 で WPF のスタイラス/タッチ入力を無効化しなくても WPF アプリケーションでタッチ キーボードが自動的に起動、終了するようになりました。
以前のバージョンでは、WPF アプリケーションのタッチ キーボードの起動や終了が明示的にはサポートされておらず、WPF のスタイラス/タッチ入力を無効化する必要がありました。これは、Windows 8 以降のタッチ キーボードがアプリケーション内のフォーカスを追跡する方法が変更されたことによるものです。
![softkeyboard]()
フィードバックのお願い
.NET Framework 4.6.2 のプレビュー リリースに関してフィードバックをお寄せくださった皆様に改めて感謝申し上げます。皆様からのフィードバックのおかげで、.NET Framework 4.6.2 はすばらしいリリースとなりました。引き続き、以下にフィードバックをお寄せください。
