.NET 2015とは何か：特集：.NET大変革（2/3 ページ）

オンラインイベント「Connect();」で、マイクロソフトが明らかにした.NET 2015構想。本稿では、.NET 2015を構成する主要素について概観していく。

[かわさきしんじ，著]

ASP.NET 5

　Windows以外にも、Linux、Mac（OS X）でもホストできるという点で、ASP.NET 5は.NET Core 5が目指すクロスプラットフォーム性を大きく示している。以下にASP.NET 5の特徴をまとめておこう。

• Windows、Linux、Macで実行可能： Windowsではフル機能のCLR／CoreCLRを、Mac／LinuxではMono CLRを使用
• コンパイル不要： コードに変更を加えて保存した後に明示的にビルドを行わなくとも、動的にコンパイルが行われ、ブラウザー上でページを更新することで、その変更が反映される（Roslynと呼ばれる新たなコンパイラープラットフォームの活用）
• ASP.NET MVC／Web API／Web Pageの統合： コントローラー／ルートなど、各フレームワークで重複して実装されていた機能が統合された
• DI（依存性注入）のサポート： ASP.NET 5では全面的にDIがサポートされ、リクエストごとに固有なシングルトンオブジェクトの生成などでDIが使われる
• アプリのサイドバイサイド実行： 異なるバージョンの.NETを1台のサーバー上で実行可能（CoreCLRを使用している場合）。これにより、最新バージョンを必要とするアプリと最新バージョンではうまく動作しないアプリが共存可能となる
• NuGetを使用したパッケージ管理： プロジェクトで必要とする機能は、アセンブリ参照の形ではなく、NuGetパッケージを参照する形で指定する。これにはproject.jsonファイルに直接記述するか、NuGetパッケージマネージャーを使用する

　ASP.NET 5は.NET Frameworkの基本クラスライブラリに含まれているSystem.Webアセンブリと、これと強く結び付いているIISへの依存を断ち切ることで、IIS以外をサーバーとして動作できるようになっている*1。

*1　これを実現するのに大きな役割を果たしているのがOWIN（Open Web Interface for .NET）と呼ばれる技術だ。これは、WebサーバーとWebアプリとを疎結合するためのインターフェース仕様であり、マイクロソフトによるOWIN実装としてKatanaが存在する。

　ASP.NET 5にはASP.NET MVC 6（Web APIやWeb Pagesを含む）／SignalR 3／Entity Framework 7などが含まれるが、System.Webアセンブリに強く依存するWebフォームは含まれない（ASP.NET 4.6には含まれる）。これはつまり、従来のASP.NETアプリはASP.NET 5ではなく、ASP.NET 4.6でサポートされるであろうことを意味している。

　なお、上の図ではASP.NET 5は.NET Framework 4.6と.NET Core 5の双方に含まれている。.NET Framework 4.6上で動作するバージョンを単にASP.NET 5、.NET Core 5上で動作するバージョンを「ASP.NET Core 5」と呼ぶこともあるようだ。

　なお、ASP.NET 5については機会をあらためて詳細に解説を行う予定だ。

.NET Native

　一般に、.NETアプリは中間言語（MSIL）へとコンパイルされ、これが実行時にJITコンパイラーによってネイティブコードへと変換される。これを事前にネイティブコードへとコンパイルしておく仕組みが.NET Nativeだ。VS 2015 Previewにはすでにこの機能が組み込まれており、ネイティブコードコンパイルを試せるようになっている。また、前述の通り、.NET Nativeは.NET Framework 4.6でもサポートされる。

　.NET Nativeのメリットは次のようなものになる。

• C#と.NET Frameworkを使ってプログラミングが可能
• ネイティブコードならではのパフォーマンスを得られる
• ネイティブコードになった後でも.NET Frameworkが持つガベージコレクションなどの機能の恩恵を受けられる
• アプリ起動時間の短縮
• アプリを実行するマシンでは.NET Frameworkが不要

　現状では.NET NativeはC#で記述されたWindowsストアアプリを対象としている。Visual Basicなどの他言語までサポートするかは現在のところは不明だ。ストアアプリ以外の.NETアプリのネイティブコードへのコンパイルについては長期的な目標として考えられている。

　.NET Nativeが有効なWindowsストアアプリは、まずVS上で中間言語にコンパイルされ、これがストアに登録される（動作の検証を目的としてVS上でネイティブコードにコンパイルすることも可能だ）。そして、これがストア上でネイティブコードに変換される。ストアアプリを利用する側では、インストール先のデバイスのCPUアーキテクチャに適合したものがインストールされる。このようにすることで、アプリの実行側ではJITコンパイルが不要となり、アプリの起動時間や実行速度の面で大幅な性能向上が見込まれる。

VS 2015 Preview上で.NET Nativeを有効化したところ
ソリューションのプロパティで［アクティブ構成］に何らかのCPUアーキテクチャを指定し、次にプロジェクトを右クリックしてコンテキストメニューから［Enable for .NET Native］を選択すると.NET Nativeが有効化される（上図）。有効化すると、.NET Nativeでのネイティブコードコンパイル用に静的なコード解析が実行される（コンテキストメニューから［Run static analysis for .NET Native］を選択すると、任意のタイミング＝プロジェクトがある程度完成した時点でこのコード解析を実行できる）。
次にプロジェクトのプロパティから［ビルド］タブを選択し、［.NET ネイティブ ツール チェーンでコンパイルする］チェックボックスをオンにする。

　アプリを開発する側から見ると、.NET FrameworkとC#という従来と変わらないプログラミングを続けながらネイティブコードの高速性の恩恵を受けられる。また、.NET Nativeでは、アプリで必要な.NET Frameworkなどを含めて、全てが静的にリンクされ、ネイティブコードへコンパイルされるので、ターゲットマシンでは.NET Frameworkも不要となる。

　ネイティブコードへの変換時には.NETコードは基本的に全て削除される。このため、リフレクションの使用に制限が掛かる。一部のコードについては変換時にある程度推測してくれるが、そうでない部分については手作業でリフレクションに関する処理を行う必要がある。

　.NET Core 5の話の最後に、なぜこれが生まれたのか、なぜモジュール化されているのかについて少し考えてみよう。

モジュール化することの意義

　.NET Frameworkが誕生した後、さまざまなプラットフォームをターゲットとすべくさまざまなプロファイル（バージョン）が登場するようになった。例えば、Windows Mobile用に登場した.NET Compact Framework、Silverlight、Windowsストアアプリ用の.NET Frameworkなどがそうだ。これらのプロファイルはフルセットの.NET Frameworkのサブセット（＋プラットフォーム固有の実装を施したもの）である。

　これはプラットフォーム（プロファイル）が異なると、使用可能なAPIが異なるということだ（.NET Frameworkのフラグメンテーション化）。

従来の.NET Frameworkでは、プラットフォームごとにプロファイルが存在し、プロファイルごとに使用可能なAPIが異なる

　こうした状況でさまざまなプラットフォームをターゲットとしてアプリを開発（あるいは移植）しようとすると、あるプラットフォームではサポートされているAPIが別のプラットフォームではサポートされない事態が発生する可能性がある。

　この問題を解決すべく、.NET Core 5ではモジュール化された設計が取り入れられた。つまり、.NET Core 5では、個々のアセンブリが個々のNuGetパッケージと対応し、パッケージ名はアセンブリ名と同じものになる（NuGetパッケージのバージョンも、アセンブリのバージョンと同じになる）。そして、それぞれのアプリが必要なコンポーネントをNuGet（VSのコンポーネントマネージャー）を利用して管理するのだ。

　プロファイル方式のAPI管理を行うのではなく、NuGetパッケージによるコンポーネントの管理を行うことで、アプリがターゲットとするプロファイルが何か、そのプロファイルで使用できるAPIが何かに頭を悩ます必要がなくなり、単に必要なAPIを含むコンポーネントをアプリが利用すればよいだけだ。

.NET Core 5ではNuGetを利用して必要な機能だけを参照する

　このようにモジュール化を行うことには他にもメリットがある。1つは、.NET Core 5を構成する要素がアップデートされたときに、迅速にそれをリリースできることだ。

　と同時に、その機能を使用していないアプリには何の影響もないのもメリットといえる。これまで.NET Frameworkではmscorlib.dllファイルにその主要な機能が詰め込まれていた。そのため、mscorlib.dllファイルがバージョンアップされたら、変更のあった機能を自分のアプリが使用していなくとも、新しいバージョンへの対応をどうするかを検討しなければならない。そして、そのためにはそれなりのコストが必要になる。こうした事態がなくなるのもモジュール化とNuGetによるパッケージ管理のメリットといえるだろう。

　.NET Core 5ではアジャイルな形でパッケージが随時リリースされる。が、1年に4回ほどのペースで「.NET Coreディストリビューション」と呼ばれるパッケージ群がリリースされる予定だ。これは、リリース時点における.NET Core 5のスナップショットであり、マイクロソフトによって全パッケージのテストなどが行われたものとなる。

　次に.NET 2015に含まれるもう1つのフレームワーク、.NET Framework 4.6について簡単に見ておこう。