.NET Framework 4.6 のリリースを発表


本記事は、マイクロソフト本社の .NET Blog の記事を抄訳したものです。
【元記事】 Announcing .NET Framework 4.6 2015 2015/07/20 11:40 PM

 

.NET Framework 4.6Visual Studio 2015 の RTM がついにリリースされました。この記事では新機能についてご紹介していきますが、これを今読む方も、後で読む方も、ぜひこの最新リリースをお試しください。最も簡単なのは、無料の Visual Studio 2015 Community バージョンをインストールしていただく方法で、インストール後、すぐに利用を開始できます。

.NET Framework 4.6 では、64 ビットの "RyuJIT" JIT と、WPF および Windows フォームにおける高 DPI のサポートにより、パフォーマンスが今まで以上に強化されています。ASP.NET では、Windows 10 上で実行する場合に HTTP/2 のサポートを利用でき、非同期タスクを返す API も豊富に用意されています。Visual Studio 2015 には、.NET 開発者向けの数々のメジャー アップデートが搭載されており、その大部分は新しい Roslyn コンパイラ プラットフォームを基盤に開発されています。また、.NET 言語 (C# 6、F# 4、VB 14) も更新されています。

最近ベータ 5 がリリースされていた .NET Core と ASP.NET 5 も更新され、Visual Studio 2015 に搭載されています。.NET ネイティブなど、Windows 10 UWP アプリ開発用の .NET ツールもまもなくリリースされます (7 月 29 日を予定)。.NET UWP アプリと .NET ネイティブの詳細はその際にお伝えしたいと思います。

最新リリースは、以下からダウンロードできます。

本記事では、以下の概要をご説明します。

RTM リリースに向けた昨年来の開発の経緯については、RC 版のリリース記事プレビュー版のリリース記事をお読みください。.NET Framework 4.5.2 (英語) のリリースから、実に 14 か月しか経っていませんでした。

.NET Framework 4.6

.NET Framework 4.6 には数多くの強力な機能が搭載されています。これらのうち、RyuJIT や最新の GC の更新といった機能強化は、.NET Framework 4.6 をインストールするだけでご利用いただけるのでぜひお試しください。

RTM リリースの詳細については、「.NET Framework の新機能」、「.NET Framework 4.6 リリースでの変更一覧 (英語)」、さらに .NET Framework 4.6 リリースと 4.5.2 リリースを比較した「.NET Framework API の差分 (英語)」でもご確認いただけます。ASP.NET の更新については、ASP.NET チームの記事 (英語) をご覧ください。

.NET Framework 4.6 は Windows 10 に含まれていますが、Windows 7 と Windows 8 にもインストール可能です。Visual Studio 2012 以降では、.NET Framework 4.6 Targeting Pack をインストールすることで .NET Framework 4.6 をターゲットに設定することができます。Targeting Pack は Visual Studio 2015 に付属しています。

Windows Presentation Foundation

今回のリリースにおける WPF の主な機能強化は以下のとおりです。

透明な子ウィンドウのサポート

Windows 8.1 以降の WPF では、透明な子ウィンドウがサポートされるようになりました。これにより、四角形ではない透明な子ウィンドウを Windows の最上位に作成、構成することが可能になります。これは、HwndSourceParameters (機械翻訳)UsesPerPixelTransparency プロパティ (英語) を true に設定すると有効化されます。

高 DPI 対応

WPF における高 DPI のサポートがさらに強化されました。レイアウトの回り込みが変更され、境界を持つコントロールのクリッピングのインスタンスが削減されます。この機能はターゲットフレームワークが .NET Framework 4.6 (".NETFramework,Version=v4.6") 以上の場合に既定で有効化されます。それより前のバージョンをターゲットフレームワークとするアプリケーションの場合は、app.config ファイルに以下の設定を追加することで、この新しい動作をオプトインできます。この設定は、アプリケーションが .NET Framework 4.6 上で実行される場合にのみ適用されます。

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

</runtime>

また、DPI 設定が異なる (マルチ DPI 設定の) 複数のモニターにまたがる WPF のウィンドウが、ブラックアウト部分なしで正しく表示されるようになりました。この動作をオプトアウトするには、app.config のセクションに以下の行を追加します。

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

さらに、DPI 設定に応じた適切なカーソルの自動読み込みサポートが、System.Windows.Input.Cursor (英語) に追加されました。これにより、マルチイメージの .cur を WPF プラットフォームに提供し、アクティブなディスプレイのその時点での DPI 設定に基づいて適切なカーソルが自動選択されるよう、ファイルを構成することができます。

タッチ機能の強化

ダブルタップのしきい値には、業界でも評価の高い実装とされる、UWP アプリケーションで使用されている数値が導入されました。これにより、Windows 8.1 以降の WPF でも同じ実装が使用されるようになります。

さまざまなタッチ イベントの信頼性も強化されました。たとえば、タッチイベントの強化を求める Connect に投稿された問題 (英語) が、今回のリリースで修正されています。

 

高 DPI に対応した Windows フォームの更新

.NET Framework 4.5.2 (英語) でプロジェクトとして始まった Windows フォームの高 DPI サポートが更新され、対応するコントロールがさらに増えました。

.NET Framework 4.6 では、ComboBox、Cursor、DataGridView、DataGridViewColumn、DataGridViewComboBoxColumn、DomainUpDown、NumericUpDown、ToolStripComboBox、ToolStripMenuItem、および ToolStripSplitButton に高 DPI のサポートが組み込まれています。

Windows フォームの高 DPI サポートに関する機能強化の例をいくつかご紹介します。

clip_image001

clip_image002

clip_image003

これはオプトインの機能です。機能を有効にするには、app.config ファイルで EnableWindowsFormsHighDpiAutoResizing 要素を true に設定します。

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

RyuJIT

RyuJIT は .NET 向けの次世代の Just-In-Time (JIT) コンパイラです。高スループットな JIT コンパイルを目的として、高パフォーマンスな JIT アーキテクチャが採用されています。2005 年の .NET 2.0 リリース以来 10 年間使用されてきた既存の 64 ビット JIT コンパイラである JIT64 に比べ、処理を大幅に高速化できます。これまで 32 ビットの JIT と 64 ビットの JIT ではスループットに大きな差がありましたが、この差がかなり改善されたことで、64 ビット アーキテクチャ専用の設定や、32 ビットから 64 ビットへのワークロード移行を簡単に行えるようになりました。

RyuJIT は .NET Framework 4.6 を基盤とする 64 ビット プロセスで有効になります。アプリは、64 ビットまたは Any CPU (32 ビットの優先が指定されていないことが条件) でコンパイルされ、かつ 64 ビットのオペレーティング システムで実行される場合に、64 ビット プロセスで実行されます。RyuJIT は、64 ビットの JIT と同様に .NET Core に組み込まれています。

この 2 年間の RyuJIT をめぐる開発プロセスは、だれにでも開かれたものでした。RyuJIT に関するブログ記事 (英語) や RyuJIT のいくつかの CTP は、あらゆる開発者に公開されてきました。現在では RyuJIT のソース コード (英語) も公開され、プロジェクトに貢献していただけるようになっています。RTM を迎えるまでに RyuJIT の改善に力を貸してくださった皆様に感謝いたします。マイクロソフトが修正したバグやパフォーマンスの問題には、CTP の段階で皆様から寄せられたものが数多くありました。このようなより開かれた開発プロセスを RyuJIT で採用できたことは、マイクロソフトのエンジニアにとって大きな励みとなりました。

プロジェクトの当初の目的は大規模な 64 ビット クラウドのワークロードを強化することでしたが、現在はそれ以上に広い適用可能性が確認されており、将来のリリースでは 32 ビットのサポートの追加を見込んでいます。

SIMD

64 ビット CLR に Single Instruction Multiple Data (SIMD) ベクター型のサポートが導入されました。これらの新しい型は System.Numerics 名前空間 (機械翻訳) に含まれています。JIT はこれらを組み込みの型として認識し、マシンに応じて SSE2 および AVX2 ハードウェアの機能を利用してコードを生成します。

これらの新しい型には、サイズがターゲット依存 (例: SSE2 の場合浮動小数点が 4 つ、AVX2 の場合 8 つ) となる Vector<T> と、複数の固定サイズの Vector があります。固定サイズの Vector は 2 ~ 4 つの単精度浮動小数点の要素を表し、明示的な n 次元のアルゴリズムおよびデータ型 (例: ポイント、色など) を含むアプリケーションでの使用に最適です。これにより、アプリケーションが利用できるデータ並列処理の水準を高め、再構築せずにターゲットハードウェアに合わせて拡張できるようになります。

上記のコードでは、SSE2 の場合は 4 つ、AVX2 の場合は 8 つの追加が並列して実行されます (ここでは、配列のサイズをすべて同じにするための詳細な処理や、複数の Vector.Count は省略されています)。

Vector<T> コンストラクターは配列および配列内の開始インデックスを受け取り、開始オフセットから Vector<int>.Count 値の読み込みが 1 回実行され、CopyTo (配列を受け取るコンストラクターのアナログの 1 種) が、ターゲット配列の開始オフセットに Count 値を 1 回格納します。

これらの新しい型は、System.Numerics.Vectors NuGet パッケージ (英語) から利用できます。64 ビットの .NET Framework ランタイム上で実行される場合に自動で有効化されます。64 ビット .NET Core では SIMD もサポートされます。

ガベージ コレクターの更新

ガベージ コレクター (GC) には、待機時間を短縮しメモリ使用率を改善するための重要な機能強化が行われています。GC の更新は、Office 365 や Bing といったマイクロソフトの大規模なクラウド ワークロードに既に実装されており、これらのサービスでは飛躍的なパフォーマンス向上が確認されています。更新の適用自体も、コードを一切変更せずすぐに完了しました。

GC では、ピン留めオブジェクトの処理が最適化され、ピン留めオブジェクトに関連するメモリをより効率的に圧縮できるようになりました。この変更により、ピン留めを多用する大規模なワークロードを大幅に改善することができます。

ジェネレーション 1 オブジェクトからジェネレーション 2 オブジェクトの昇格も更新され、メモリ使用が効率化されました。GC は、新しいメモリ セグメントを割り当てる前に特定のジェネレーションの空き領域の使用を試みますが、新しいアルゴリズムが導入されたことにより、空き領域を使用して、オブジェクトサイズの一致率がより高いオブジェクトが割り当てられるようになりました。

メモリに関連した特定の状況下ではガベージ コレクションを実行しないという新しいモードが、ガベージ コレクターに追加されました。この新しいモードは、中断が許可されない待機時間の短いワークロードにおいて重要です。新しいモードでは、No GC Region に入る前提条件として、利用できる必要があるメモリ量を具体的に指定 (英語) できます。また、No GC Region に入った場合はガベージ コレクションが行われません。つまりこの間はワークロードの中断が発生しません。GC.Collect (機械翻訳) などでコレクションが明示的に要求された場合や、最初に指定したメモリ容量が不足した場合には、ガベージコレクションが開始されます。

新しいモードには複数の構成ポイントがあります。たとえば、小さなオブジェクト ヒープと大きなオブジェクト ヒープで利用可能なメモリを個別に指定し、No GC Region 内で使用することもできます。

Windows Communication Foundation

SSL

WCF は、SSL 3.0 と TLS 1.0 に加えて TLS 1.1 と TLS 1.2 の SSL バージョンをサポートするようになりました。このサポートは、NetTcp をトランスポート セキュリティおよびクライアント認証と組み合わせて使用する場合に利用できます。また、使用するプロトコルを選択したり、安全性の低い以前のプロトコルを無効化したりすることができます。その場合は、System.ServiceModel.TcpTransportSecurity.SslProtocols プロパティを設定するか、以下のように構成ファイルを更新します。

<netTcpBinding>
<binding>
<security mode= "None|Transport|Message|TransportWithMessageCredential" >
<transport clientCredentialType="None|Windows|Certificate"
protectionLevel="None|Sign|EncryptAndSign"
sslProtocols="Ssl3|Tls1|Tls11|Tls12"> </transport>
</security>
</binding>
</netTcpBinding>

異なる HTTP 接続によるメッセージ送信

WCF では、特定のメッセージの送信基盤として異なる HTTP 接続を使用できるようになりました。これには次の 2 とおりの方法があります。

  1. 接続グループ名のプレフィックスの使用: WCF が使用する文字列を、接続グループ名のプレフィックスとして指定できます。2 つのメッセージのプレフィックスが異なるときに、これらの送信基盤には異なる HTTP 接続が使用されます。プレフィックスを設定するには、キー/値ペア メッセージの System.ServiceModel.Channels.Message.Properties プロパティを追加します。キーは "HttpTransportConnectionGroupNamePrefix" とし、値を目的のプレフィックスとします。
  2. 異なるチャネル ファクトリの使用: 特定の機能を有効化することによって、異なるチャネル ファクトリで作成されたチャネルでメッセージを送信するときに、常に異なる HTTP 接続を基盤として使用することができます。この機能を有効化するには、以下の appSetting を true に設定する必要があります。

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

Windows Workflow

ワークフロー チームが新たに追加した設定により、未処理の "非プロトコル" ブックマークが存在する場合に、要求がタイムアウトする前にワークフローサービスが異常な操作要求を保持し続ける秒数を指定できるようになりました。"非プロトコル" ブックマークとは、未処理の Receive アクティビティに関連していないブックマークのことです。一部のアクティビティは非プロトコルブックマークを実装内に作成するため、非プロトコル ブックマークが存在するかどうかが明確ではない場合があります (State、Pick など)。このため、ワークフローサービスがステート マシンで実装されている場合や、ワークフロー サービスに Pick アクティビティが含まれている場合、非プロトコル ブックマークが存在する可能性が高くなります。

この設定は app.config ファイルの appSettings セクションに追加できます。

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

既定値は 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.

これは、非プロトコル ブックマークがない状態で受信する異常操作のメッセージと同じメッセージです。

FilterResumeTimeoutInSeconds の値が 0 以外で、非プロトコル ブックマークが存在し、タイムアウトの期限が切れた場合、操作は失敗してタイムアウトメッセージが表示されます。

ADO.NET の機能強化

SQL Server 2016 で提供される Always Encrypted (英語) 機能が ADO .NET でサポートされるようになりました。SQL Server による暗号化データに対する操作を可能にする Always Encrypted では、すべての暗号化キーが、サーバーではなくお客様の信頼済み環境内のアプリケーションと共に保管されることが大きなメリットです。Always Encrypted によってお客様のデータが保護されるため、プレーン テキスト データに対するアクセス権を DBA が持つことはありません。また、データの暗号化と暗号化解除はドライバーレベルで透過的に実行されるため、既存アプリケーションに対する変更は最小限で済みます。この機能の詳細については、SQL Server Security ブログ (英語) をお読みください。

非同期

新しい System.Threading.AsyncLocal クラスでは、特定の非同期制御フロー (非同期メソッドなど) のローカルに存在するアンビエント データを表現できます。これは、複数のスレッドにまたがってデータを永続化させる場合に使用します。また、AsyncLocal.Value プロパティの明示的な変更、またはスレッドにおけるコンテキスト変換の発生のいずれかが原因でアンビエント データが変更された場合に常に通知されるコールバック メソッドを定義できます。この新しい型の使用例を以下に示します。

 

System.Threading.Tasks.Task オブジェクトと System.Threading.Tasks.Task<TResult> オブジェクトが、.NET Framework 4.6 をターゲットとするアプリ用に、呼び出し元のスレッドのカルチャと UI カルチャを継承するようになりました。以前のバージョンの .NET Framework をターゲットとするアプリの動作に影響はありません。詳細については、System.Globalization.CultureInfo (英語) クラスに関する記事の「Culture and task-based asynchronous operations (カルチャとタスクベースの非同期操作)」セクションを参照してください。

便利な CompletedTask、FromCancelled、FromException の 3 つのメソッドが Task に追加され、特定の状態のときに完了済みタスクを返すようになりました。

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

ネットワークの機能強化

System.Net.Sockets

Windows 10 には、送信 TCP 接続用にローカル ポートを再利用することでマシン リソースの利用を効率化して高い拡張性を実現できる、新しいネットワークアルゴリズムが搭載されています。.NET Framework 4.6 でもこの新しいアルゴリズムをサポートしているため、こうした新しい動作を .NET アプリが活用できるようになります。旧バージョンの Windows では同時接続数が人為的に制限 (通常は 16384) されており、高負荷時にポートの空きがなくなった場合にサービスの拡張性も制限されることがありました。

.NET Framework 4.6 では、System.Net.Sockets.SocketOptionName.ReuseUnicastPort 列挙値と System.Net.ServicePointManager.ReusePort プロパティが追加され、ポートを再利用できるようになりました。

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

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

System.Uri

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

CLR アセンブリ ローダーのパフォーマンス

アセンブリ ローダーが、対応する NGEN イメージをロードした後、IL アセンブリをアンロードして、メモリをより効率的に活用できるようになりました。これは、大規模な 32 ビット アプリ (Visual Studio など) の仮想メモリに大きなメリットがあるほか、物理メモリの消費も節減されます。

暗号化の更新

現在チームでは、Windows CNG Cryptography API (英語) をサポートするための System.Security.Cryptography API (機械翻訳) の更新を進めています。これまで .NET Framework では Windows Cryptography API (英語) の旧バージョンを System.Security.Cryptography 実装の基盤として使用していましたが、CNG API は最新の暗号化アルゴリズム (英語) をサポートしているため、一部のカテゴリのアプリにとって重要なことから、このサポートのご要望が寄せられていました。

これにお応えし、以下の機能強化が行われています。

  • RSA の暗号化: SHA-2 ハッシュ ファミリを使用した OAEP パディングのサポートを追加
  • RSA の署名: PSS パディングのサポートを追加
  • RSA のユーザビリティ: API 公開領域を強化
  • RSA のユーザビリティ: RSA 以外の証明書に対して Null を返す、X509Certificate2.GetRSAPublicKey() および X509Certificate2.GetRSAPrivateKey() を追加。可能な限り CNG ベースの実装 (新しい暗号化モードと署名パディング モードを使用可能) を使用し、必要な場合は CAPI ベースの実装 (スマートカードなどハードウェア固有の RSA 実装) を使用してください。

 

Unix 時間

.NET Framework の型と Unix 時間の間で、日付と時間の値をより簡単に変換できるようになりました。これはたとえば、時間の値を JavaScript クライアントと .NET サーバーの間で変換する際に必要になります。DateTimeOffset 構造体 (機械翻訳) に以下の API が追加されました。

  • static DateTimeOffset FromUnixTimeSeconds(long seconds)
  • static DateTimeOffset FromUnixTimeMilliseconds(long milliseconds)
  • long DateTimeOffset.ToUnixTimeSeconds()
  • long DateTimeOffset.ToUnixTimeMilliseconds()

EventSource によるイベント ログのサポート

System.Diagnostics.Tracing.EventSource を使用して、マシン上に作成された既存の ETW セッションに加えて、管理メッセージや操作メッセージをイベント ログに記録できるようになりました。これは "ETW チャネル サポート" とも呼ばれます。以前はこの機能を実現するために Microsoft.Diagnostics.Tracing.EventSource NuGet パッケージ (英語) を使用する必要がありましたが、.NET Framework 4.6 にはこの機能が組み込まれています。

以下の機能が、NuGet パッケージと .NET Framework 4.6 の両方に更新として追加されています。

  • DynamicEvents - イベント メソッドを作成することなく、イベントを即時に定義できます。
  • RichPayloads - 特別な属性が設定されたクラス、配列、プリミティブ型をペイロードとして渡すことができます。
  • ActivityTracking – Start イベントと Stop イベントにおいて、この 2 つのイベントの間で発生するイベントが、現在アクティブなすべてのアクティビティを示す ID でタグ付けされます。

互換性スイッチ

AppContext (英語) は互換性に関する新機能です。ライブラリ作成者がこれを使用することで、新しい機能に関する一貫したオプトアウトメカニズムをユーザーに提供できるようになります。AppContext は、コンポーネント間に疎結合のコントラクトを確立して、オプトアウト要求を伝達します。この機能は、既存の機能が変更される場合に特に重要です。これに対し、新しい機能に関する暗黙的なオプトインは既に実装されています。

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

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

AppContext.SetSwitch("Switch.AmazingLib.ThrowOnExceptionh, true)

ライブラリは、利用者がスイッチの値を宣言したかどうかを確認し、値に従って適切に動作する必要があります。

 

スイッチはライブラリによって公開される正式なコントラクトであるため、スイッチに一貫した形式を使用すると便利です。わかりやすい形式として、次の 2 つが挙げられます。

  • Switch.namespace.switchname
  • Switch.library.switchname

.NET Framework の内部でも同じインフラストラクチャを使用して、開発者が既存の機能の更新をオプトアウトできるようにしています。

その他の基本クラス ライブラリの変更

  • System.Collections.Generic.Queue および System.Collections.Generic.Stack など、数多くのコレクション オブジェクトで System.Collections.Generic.IReadOnlyCollection を実装
  • System.Globalization.CultureInfo.CurrentCulture および System.Globalization.CultureInfo.CurrentUICulture プロパティを、読み取り専用ではなく読み書き可能に変更。これらのプロパティに新しい System.Globalization.CultureInfo オブジェクトを割り当てると、現在のスレッド カルチャ (Thread.CurrentThread.CurrentCulture プロパティが定義) と現在の UI スレッド カルチャ (Thread.CurrentThread,CurrentUICulture プロパティが定義) も変更されます。
  • System.Numerics 名前空間に、System.Numerics.Matrix3x2、System.Numerics.Matrix4x4、System.Numerics.Plane、System.Numerics.Quaternion、System.Numerics.Vector2、System.Numerics.Vector3、Vector4T:System.Numerics.Vector4 などの、科学計算用の SIMD 対応の型を数多く追加

リファレンス ソース

.NET Framework 4.6 では .NET Framework リファレンス ソースが更新されました。最新のソースについては、.NET Framework のソース デバッグ (英語) にも使用されている .NET Framework リファレンス ソース Web サイト (英語) を参照してください。新しい AsyncLocal<T> (英語) 型などがリファレンス ソースに公開されているのをご確認いただけます。

GitHub の .NET Framework リファレンス ソース リポジトリ (英語) も .NET Framework 4.6 に併せて近日更新される予定です。これは、Mono プロジェクト (英語) における .NET Framework ソースの利用拡大を支援することを主な目的に整備されたリポジトリです。

ASP.NET 4.6

ASP.NET 4.6 では、ASP.NET チームによる数多くの更新が実装されています。詳しくは、ASP.NET 4.6 の RTM に関するブログ記事 (英語)ASP.NET チームのメンバー Pranav Rastogi による更新内容の説明 (英語) をご覧ください。今回のリリースでは以下のコンポーネントが更新されています。

  • ASP.NET Web フォーム 4.6
  • ASP.NET MVC 5.2.3
  • ASP.NET Web ページ 3.2.3
  • ASP.NET Web API 5.2.3
  • ASP.NET SignalR 2.1.2

Web フォームの非同期モデル バインディング

.NET Framework 4.5 の Web フォームでは、モデル バインディングのサポートが追加されました。.NET Framework 4.6 では、非同期モデル バインディングのサポートが追加され、非同期モデル バインディング アクションを記述できるようになりました。以下は、非同期モデルバインディング アクションを使用する Web フォーム ページのコード スニペットです。

 

ID 管理と認証の更新

ASP.NET 4.6 テンプレートで Azure Active Directory (Azure AD) への認証にオープン ID 接続ミドルウェアが使用されるようになったことで、Azure AD による認証のためのプログラミング モデルをより簡単に実現できるようになりました。新しいプロジェクトの作成時に個々のユーザーアカウントを使用するオプションを選択すると、ASP.NET Identity 2.2.1 を使用した 2 要素認証とソーシャル ログインのサンプル コードがテンプレートに表示されます。

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

.NET Framework 4.6 では、ASP.NET に HTTP/2 のサポートが追加されました。これまでは、ネットワーク機能が複数の層に存在することが理由で、HTTP/2 を有効にするためには、Windows、IIS、ASP.NET に新しい機能が必要でした。ASP.NET で HTTP/2 を使用するには Windows 10 が必要です。現時点では ASP.NET 5 に HTTP/2 は追加されていません。

HTTP/2 は HTTP プロトコルの新しいバージョンで、接続の効率が大幅に向上する (クライアントとサーバー間のラウンドトリップが減少する) ことで、Web ページ読み込みの待機時間が短縮されます。HTTP/2 は単一のエクスペリエンスの一部としてリクエストされた複数の成果物を最適化するため、HTTP/2 のメリットが最も活かされるのは Web サービスではなく Web ページです。

すべての処理はブラウザーと Web サーバー (Windows 上の IIS) が行うため、ユーザーのための複雑な作業は必要ありません。

主要ブラウザーの大部分が HTTP/2 に対応しているため、HTTP/2 サポートのメリットを多くのユーザーが活用できるはずです。

トークン バインディング プロトコルのサポート

マイクロソフトは Google と協力して、新しい認証方式であるトークン バインディング プロトコル (英語) を開発しました。このプロトコルの前提となっているのは、ブラウザーのキャッシュ内の認証トークンが盗用され、銀行口座などのセキュリティで保護されたリソースにパスワードその他の特別な情報なしでアクセスされてしまうという可能性です。この問題を回避することが新しいプロトコルの目的です。

トークン バインディング プロトコルは Windows 10 でブラウザーの機能として実装されます。ASP.NET アプリは、このプロトコルを使用して認証トークンの正当性を検証します。クライアントとサーバーの実装により、このプロトコルで規定されたエンドツーエンドの保護を確立することができます。

Entity Framework

Entity Framework では、現在以下の 2 種類のバージョンを開発中です。

  • EF 6.1.3 (英語): 運用環境のワークロード用に推奨されます。EF 6.1.2 で報告された優先度の高い問題が修正されています。
  • EF 7 (英語): EF 6.x に対する重要な変更や機能強化が行われています。特に、Linux、OS X、Windows のサポートを含む、.NET Core の実装が提供されます。EF 7 は ASP.NET 5 アプリと UWP アプリで使用でき、EF 6.x と同様に .NET Framework でもサポートされますが、現時点では運用環境のワークロードではサポートされていません。

.NET 言語

今回 .NET 言語チームは、C# 6、F# 4.0 (英語)、VB 14 向け更新の最終版をリリースいたしました。これには、コンパイラ実装の最終版と C# および VB 向け言語機能セットの最終版が含まれています。実際には、言語の最新バージョンの機能自体は RC の段階で完成しています。

Roslyn v1

また、6 年近くの年月を経て、Roslyn の v1 バージョンもリリースされました。Roslyn は当初から壮大なプロジェクトだと考えられてきました。目的は、ネイティブ C++ ベースの C# および VB のコンパイラを、言語、コンパイラ、その他の API を豊富に提供する (C# と VB で開発された) .NET 実装で置き換えるというものでした。Visual Studio 2015 で現在使用できる Roslyn v1 製品は、このビジョンを実現し、Visual Studio の強力で新しい開発エクスペリエンスに貢献しています。

開発の経緯については、以前のブログ記事「Microsoft “Roslyn” CTP の概要 (英語)」をお読みください。当初はとても控えめに紹介されていたことがわかります。

Roslyn の詳細については、Roslyn のリポジトリ (英語) や「Roslyn の概要 (英語)」をご覧ください。

C# 6 および VB 14

C# (英語)VB (英語) は、いずれも Roslyn コンパイラ (英語) に含まれています。各言語でサポートされている機能については、「C# 6 と VB 14 言語の機能 (英語)」でご確認ください。

以下は、両方の言語で使用できる新しい言語機能です。その他の新しい言語機能 (英語) は、一方の言語にしか対応していないものや、一方の言語には既にあったもので、今回のリリースでもう一方の言語にも追加されたものもあります。

文字列の補完: 直観的な String.Format に似た構文によって、インライン表現を持つテンプレートから文字列を作成できます。

 

 

null 条件演算子 (?.): 合理的な構文によって、Null 以外の場合では条件付きでメンバーにアクセスするかメソッドを呼び出し、オブジェクトが Null の場合は NullReferenceException をスローせずに Null を返します。

 

 

NameOf 演算子: PropertyChanged イベントや ArgumentExceptions などでコード要素の名前を参照します。名前を変更する危険性がありません。

 

 

読み取り専用自動プロパティ: 簡潔な構文によって、初期化子またはコンストラクター内部のみで割り当てられるプロパティを宣言します。

 

 

静的インポート: C# 6 の新機能です。簡潔な構文によって、型条件なしで静的メソッドを呼び出せます。これは、System.ConsoleSystem.Math などのユーティリティ クラスのメンバーを頻繁に呼び出す場合に便利です。

 

この機能は、C# 6 では新しいですが、VB の旧バージョンには既にありました。

 

複数行の文字列リテラル: VB 14 の新機能です。文字列リテラルに改行文字を含められるようになりました。これにより、vbCrLf を手作業で文字列に連結せずに、複数行コンテンツを VB プログラムに簡単に含めることができます。

 

この機能は、VB 14 では新しいですが、C# の旧バージョンには既にありました。

 

F# 4.0

F# 4.0 (英語) では、言語とランタイムの新機能が数多く追加されています。それらの一部を以下にご紹介します。すべての機能の詳細については、プレビュー版のリリース記事 (英語)RC 版のリリース記事 (英語) をお読みください。VS 2015 リリース ノートでも紹介しています。

ファーストクラス関数値としてのコンストラクター: コンストラクターを、カリー化された関数やその他の .NET メソッドと同様に、ファーストクラス関数値として扱うことができるようになりました。これにより、コンストラクターを呼び出すためだけに小さなラムダ式を作成する必要がなくなります。

 

変更可能な値の簡素化: 変更可能な値を作成するすべてのケースで mutable キーワードを使用できるようになりました。以前は ref 値が必要だったシナリオは、コンパイラによって自動処理されます。

 

メソッド引数の暗黙の引用: メソッド引数が [<ReflectedDefinition>] 属性をサポートしたことで、渡された引数の値と、呼び出しサイトの式の引用の両方にアクセスできるようになりました。

 

正規化されたコレクション API: ListArraySeq の各モジュールが拡張、かつ完全に正規化され、すべてのコレクション型のあらゆる API が専用の実装になりました。これにより、104 個の新しい API が追加されました。

clip_image004

Visual Studio の .NET 向け機能強化

Visual Studio 2015 では .NET 向けの重要な機能強化が行われています。

Visual Studio Community

Visual Studio 2015 Community エディションは、学生、オープン ソース開発者、個人開発者向けに無料提供され、機能は Visual Studio Pro によく似ています。Xamarin や Resharper などの Visual Studio プラグインをサポートしています。

EnC – ラムダと非同期タスクのサポート

エディット コンティニュ (EnC) は、広く普及した生産性機能です。この機能によって、デバッグしながらコードを編集することができます。この機能の優れた点は数多くありますが、JSON ファイルの処理のように、API に直接含まれていない状態をコードで操作する必要があり、その状態が実行中に簡単に検出できる場合には特に便利です。

この EnC が、ラムダ、非同期メソッド、LINQ、その他の言語機能で使用できるようになりました。現在のコーディングパターンを考えると、これで EnC の利便性が飛躍的に高まることになると言えます。Visual Studio 2015 の EnC でサポートされるすべての EnC 操作については、「エディット コンティニュ (EnC) でサポートされる編集 (英語)」をご覧ください。

以下は EnC がこれまでサポートしていなかったコードの例で、LINQ ステートメントを含む非同期のラムダ式です。これがデバッガー内でどのように修正されたかをご確認いただけます。下の画像では string[] を "Enc" ではなく "EnC" で正しくクエリし、string[] 内のメッセージを変更しています。

 

clip_image005

F# スクリプトのデバッグ

F# スクリプトと F# インタラクティブが Visual Studio デバッガーに統合され、作業を対話的に進めながら Visual Studio の豊富なデバッグ ツールを使えるようになりました。

clip_image006

WPF Live Visual Tree

Visual Studio の新しいビューアーとエディターでは、WPF アプリをデバッグしながら XAML ビジュアルツリーをライブで表示できます。このため、アプリのライフサイクルのどの時点でもビジュアル ツリーを確認し、操作することができます。ボタン テキストなどのプロパティをツリーで編集でき、変更内容は実行中のアプリに反映されます。ツリーの構成を変更することはできません。

実行中のアプリのビジュアル コンポーネントを選択することもできます。コンポーネントを選択すると Visual Studio の Live Visual Tree が更新され、アプリ内の調査や更新の必要な箇所がわかります。

Live Visual Tree から XAML ソース編集機能を利用することもできます。Live Visual Tree で XAML ノードを選択すると、IDE 内の選択された XAML テキストがそれに合わせて変更されます。どのテキストが対応しているのかがわかるため、確認や変更が必要な XAML の行を簡単に見つけられるようになります。

以下は、Live Visual Tree と、アプリ内のボタンが新機能によって選択された状態のスクリーンショットです。

clip_image007

アプリケーション タイムライン ツール

[デバッグなしで診断ツールを開始] から利用できるアプリケーション タイムライン ツールには、アプリケーションの読み込みなどのシナリオにおいて、UI フレームの準備やネットワーク要求やディスク要求の処理にアプリケーションでかかった時間が表示されます。システム リソースの使用状況をシナリオに基づいて把握できるため、WPF アプリケーションの検査、診断、改善に便利です。また、アプリケーション タイムライン ツールに加えて、CPU 使用率ツールとメモリ使用量ツールが Windows 7 でも利用できるようになりました。

clip_image008

デバッガーの機能強化

Visual Studio 2015 ではデバッグ環境の改善に関する多くのご要望にお応えして、ラムダ式のデバッグ (英語)エディット コンティニュ (EnC) の機能強化 (英語)子プロセスのデバッグ (英語) を実現し、強力なブレークポイントの構成 (英語) などの主要エクスペリエンスを改良し、新しい例外設定ツール ウィンドウ (英語) を導入しました。

また、PerfTips (英語) のほか、履歴デバッグ用に再設計された IntelliTrace (英語)メモリ使用量ツール (英語) を含むまったく新しい診断ツール ウィンドウ (英語) を通じて、パフォーマンス ツールとデバッガーの統合という最先端の機能を実現しています。

Xamarin Starter Visual Studio 2015 に同梱

iOS と Android のアプリケーションを Visual Studio で C# または F# を使用して作成する場合、Xamarin は非常にお勧めの手段です。マイクロソフトと Xamarin の提携により、無料のオプション機能として Visual Studio 2015 に Xamarin Starter エディション (英語) が同梱されました。現在数多くの .NET 開発者が、Xamarin を使用して iOS と Android のアプリ開発を進め、ユーザーを増やしています。

また同社では、全 Xamarin 製品による Visual Studio 2015 のサポートを今回のリリース同日に開始 (英語) しています。

Visual Studio 2015 で Xamarin をインストールするには、カスタム インストール オプションを選択します。以下のチェックボックスをオンにします。

clip_image009

Xamarin Starter エディション (英語) は、アプリの作成、デバイスやシミュレーターでのテスト、アプリストアへの公開に期限なしで利用することができます。ただし、アプリのコード量は 128 KB 以下 (英語) に制限されます。より高度なエクスペリエンスが必要な場合は、Xamarin Business 試用版 (英語) をお試しいただけます。試用の後は Xamarin Starter エディションにいつでも戻すことができます。

Windows Xamarin.Forms

Xamarin.Forms による Windows プラットフォームのサポートが更新され、Windows 8.1 および Windows Phone 8.1 アプリのサポートが追加されました。これにより、あらゆる主要モバイル プラットフォームをターゲットとする Xamarin.Forms アプリを 1 つのコードベースで構築し、公開できるようになります。

Xamarin.Forms XAML のコード補完

Xamarin.Forms のコード補完により、Visual Studio による宣言型の UI 開発がより強力なものになりました。Xamarin.Forms のユーザー インターフェイス API を簡単に検索して、複雑な画面をスピーディに構築し、タイポやその他のよくあるエラーを回避しながら、XAML で UI を作成することができます。

clip_image010

Xamarin と Visual C++ デバッガーの統合

Xamarin.Android アプリでネイティブ C++ ライブラリを参照、デバッグすることができます。プロジェクトのプロパティページでマイクロソフトのデバッガーを選択するだけで、式の評価、ウォッチ ウィンドウ、オート ウィンドウなど、使い慣れたすべてのデバッグ機能を使用して、これらのライブラリをステップ実行できます。

.NET Core

.NET Core (英語) は、最新のデバイスとクラウド ワークロードに対応した新しいバージョンの .NET です。汎用かつモジュラー型の実装であるため、さまざまな環境に移植して、多様なワークロードに使用することができます。マイクロソフトでは現在 Linux および OS X への .NET Core の移植を進めています。

コミュニティでは Free BSD への .NET Core の移植が活発に進められており、最近は ARM Linux への移植も開始されました。さらに Linux x64 や OS X への移植も積極的に行われています。この .NET Core プロジェクトにおけるコミュニティの活動からは、最も楽観的な想定をはるかに超える、めざましい成果が生まれています。ご協力いただいている皆様に深く感謝いたします。

.NET Core は、ASP.NET 5 アプリ、Windows 10 UWP アプリ、コンソール アプリのワークロードに対応しています。今後は、マイクロソフトおよびコミュニティによるその他の .NET Core ワークロードのサポートと、.NET Core を基盤とするその他の企業による開発が期待されています。

簡単に言うと .NET Core は、クロス プラットフォーム ランタイムの実装であり、クロス プラットフォーム フレームワークライブラリの実装であり、複数の .NET 実装 (例: NET Framework、.NET Core、Xamarin、Unity) によって対応可能な標準の API 形式です。

現在は、ASP.NET 5 を使用することで、Visual Studio 2015 内で .NET Core をお使いいただけます。同じく .NET Core を使用する UWP 向けの .NET ツールは 7 月 29 日のリリースを予定しています。

.NET Core FX

現在 .NET Core Framework (英語) は、ASP.NET 5 アプリ、Windows 10 UWP アプリ、.NET Core コンソール アプリで使用することができます。.NET Core API は当初 Windows 8 ストア アプリ用の API として開発が開始されましたが、提供される API も増え、ASP.NET 5 を始め対応シナリオも拡大しました。現在では、.NET Core に追加された新しい API は、複数種類のアプリで使用できます。この手法により、エンジニアリングにかける時間を効率化し、ユーザーに一貫性のある API をすぐに提供しています。

.NET Framework 4.5 以降では、標準 API 形式としての .NET Core Framework API もサポートされます。つまり、移植可能なライブラリ、共有プロジェクト、その他のコード共有手段を用いなくても、デバイス、クラウド、デスクトップの各アプリ用に同じコードを記述、共有することができます。.NET では基本方針として常に低レベルのコード移植性を提供してきましたが、現在は、異なる種類のアプリで使用できる共通の API を提供するようになりました。

.NET Core ライブラリはすべて NuGet パッケージとして配布されます。パッケージは、Visual Studio 内またはいずれかの NuGet クライアントから直接簡単に入手できます。

ASP.NET 5

ASP.NET 5 は、MVC や Web API を含むさまざまな ASP.NET テクノロジの最新バージョンです。ASP.NET 5 は .NET Framework および .NET Core 上での実行に対応しています。つまり Windows、Linux、OS X、その他あらゆる .NET Core プラットフォームでの実行がサポートされます。ASP.NET 5 に関する説明については、まず ASP.NET ホーム (英語) のリポジトリをご覧になることをお勧めします。サンプルや利用開始手順もこちらで提供されています。

.NET Core のベータ 5 を含む ASP.NET 5 のベータ 5 (英語) が最近公開されました。これは Visual Studio 2015 に含まれているバージョンと同じです。今月後半に予定されているベータ 6 バージョンが公開されると、Visual Studio 2015、VS Code (英語)、その他の OmniSharp 対応のテキスト エディター (英語) で使用できる ASP.NET 5 の更新バージョンをインストールできるようになります。

.NET オープン ソース

.NET Framework と .NET Core の RTM バージョンには、中核となるマイクロソフト .NET チームの外部の開発者による変更が含まれています。彼らは強い情熱と高いスキルを備えた開発者たちで、マイクロソフトとの共同作業は GitHub の coreclr (英語) および corefx (英語) リポジトリで展開されました。Roslyn コンパイラも同様に roslyn (英語) リポジトリでの作業が行われました。ご協力いただいた皆様、ありがとうございました。これまでに、コミュニティメンバーによる製品変更の承認プロセスについて複数のお客様より質問が寄せられています。マイクロソフトを含め多くの企業が、アプリケーションのオープン ソース ソフトウェアに関するポリシーを定めています。こうしたお客様が知りたいのは、オープンソースに関する自社のポリシーを .NET Framework、.NET Core、Roslyn にも適用すべきかどうかということです。

簡単にお答えすると、マイクロソフトはこれまでと変わることなく、.NET Framework、.NET Core、Roslyn を高品質の商用製品として扱い、これらの製品にはこれまでと同様の厳格なエンジニアリング作業を実践し、以前と変わらないライセンス条件の下でこれらの製品を皆様に公開します。マイクロソフトが GitHub に移管したのはソース管理の領域であり、それ以外は何も変化していません。.NET Framework、.NET Core、Roslyn の各バージョンは、マイクロソフトが配布する商用製品であると引き続きご認識いただく必要があります。

詳しく説明すると、作業者がマイクロソフトの .NET チームのメンバーであるか、または GitHub のプル リクエストに基づくコアチーム外の開発者であるかにかかわらず、GitHub の .NET Core リポジトリと Roslyn リポジトリでの作業に対しては、.NET エンジニア (マイクロソフトの開発者と高度なスキルを持つコミュニティメンバー) がコード レビュー プロセスを必ず実施します。各コード レビューアーが問題ないと判断したら、"LGTM" (looks good to me: 大丈夫だと思います) や "LGTM, modulo my feedback" (私のフィードバック内容を反映すれば大丈夫だと思います) などといったコメントによってコードを承認します。コードの最終状態とコード レビュー プロセスの状態は、コア コミッター (この場合はマイクロソフトの従業員となります) が必ず承認し、承認されたコードはリポジトリに統合されます。コード レビュー プロセスは、変更内容に応じて数時間から数週間かかります。たとえばコード レビュー 1210 (英語)2344 (英語)3974 (英語) をご覧いただくと、プロセスの実際の進行をご確認いただけると思います。さらにマイクロソフトでは変更内容に対する自動スキャンを実施し、視覚的なコードレビューで見落とされた問題点を検出しており、これまでにもいくつかの問題を発見、修正しています。

マイクロソフトとコミュニティ メンバー両者による .NET Core での作業には、必ず .NET Foundation 協力者ライセンス条件 (英語) が適用されます。このライセンス条件は、マイクロソフトとその他すべての当事者に当該作業内容の使用権を付与するものでもあります。マイクロソフトが配布する .NET Framework、.NET Core、Roslyn は、従来からの厳格なエンジニアリング作業に従って開発されたマイクロソフトの商用ソフトウェアであると同時に、オープンソースと透明性のあるコード レビュー プロセスの利点がさらに追加されているということです。マイクロソフトが提供するバージョンは、当該バージョンと共にライセンス条件 (EULA) のダウンロードと同意が必要になり、マイクロソフトのサポート契約によりサポートされます。マイクロソフト以外の企業が .NET Core や Roslyn をソース コードから開発する場合は、オープン ソース ライセンスに従ってコードを使用することになります。つまり成果物はマイクロソフトがサポートしないオープンソースのコンポーネントになり、この場合は当該企業のオープン ソースに関するポリシーが適用されます。

まとめ

今回リリースされた .NET Framework 4.6Visual Studio 2015、そして関連する言語とコンポーネントによって、皆様の開発エクスペリエンスだけでなく、皆様の .NET アプリの信頼性とパフォーマンスを飛躍的に向上していただくことができます。新しいリリースをぜひお試しいただき、ご意見をお寄せください。

マイクロソフトのチームにも、今回のリリースに深い感慨を抱いているメンバーがいます。今回は、単に .NET Framework の新バージョンを公開したということ以上に、ここであらためてご紹介したい以下の大きなマイルストーンが達成されました。これらのマイルストーンから、.NET に対するマイクロソフトの姿勢がご想像いただけると思います。なお、.NET ネイティブ プロジェクトは 7 月末の公開を予定しているため、この記事では説明を省略しています。

  • Roslyn が公開を迎えました! 6 年間にわたって取り組まれてきた言語コンパイラ プロジェクト Roslyn v1 が Visual Studio に完全統合され、オープン ソースで公開されました。Roslyn は .NET Framework、.NET Core、Mono 上で実行されます。
  • RyuJIT が公開を迎えました! 5 年間にわたって取り組まれてきた JIT コンパイラ プロジェクト RyuJIT v1 が .NET Framework と .NET Core に完全統合され、オープン ソースで公開されました。.

マイクロソフトは、これらの 2 つのリリースについて何度もご説明の機会を設け、たびたび最新情報をお伝えしてきました。そしてようやく、この 2 つの v1 が完成しました。しかしこれらのプロジェクトはここで終わりではありません。どちらのチームも次の更新に向けて既に乗り出しています。

.NET Framework、.NET Core、Roslyn、ASP.NET 5、Visual Studio が今回重要なマイルストーンとなるリリースを迎えられたのは、皆様からのフィードバックのおかげにほかなりません。たくさんのご協力をいただき、本当にありがとうございました。

Comments (0)

Skip to main content