Windows以外にも、Linux、Mac(OS X)でもホストできるという点で、ASP.NET 5は.NET Core 5が目指すクロスプラットフォーム性を大きく示している。以下にASP.NET 5の特徴をまとめておこう。
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アプリは中間言語(MSIL)へとコンパイルされ、これが実行時にJITコンパイラーによってネイティブコードへと変換される。これを事前にネイティブコードへとコンパイルしておく仕組みが.NET Nativeだ。VS 2015 Previewにはすでにこの機能が組み込まれており、ネイティブコードコンパイルを試せるようになっている。また、前述の通り、.NET Nativeは.NET Framework 4.6でもサポートされる。
.NET Nativeのメリットは次のようなものになる。
現状では.NET NativeはC#で記述されたWindowsストアアプリを対象としている。Visual Basicなどの他言語までサポートするかは現在のところは不明だ。ストアアプリ以外の.NETアプリのネイティブコードへのコンパイルについては長期的な目標として考えられている。
.NET Nativeが有効なWindowsストアアプリは、まずVS上で中間言語にコンパイルされ、これがストアに登録される(動作の検証を目的としてVS上でネイティブコードにコンパイルすることも可能だ)。そして、これがストア上でネイティブコードに変換される。ストアアプリを利用する側では、インストール先のデバイスのCPUアーキテクチャに適合したものがインストールされる。このようにすることで、アプリの実行側ではJITコンパイルが不要となり、アプリの起動時間や実行速度の面で大幅な性能向上が見込まれる。
アプリを開発する側から見ると、.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のフラグメンテーション化)。
こうした状況でさまざまなプラットフォームをターゲットとしてアプリを開発(あるいは移植)しようとすると、あるプラットフォームではサポートされているAPIが別のプラットフォームではサポートされない事態が発生する可能性がある。
この問題を解決すべく、.NET Core 5ではモジュール化された設計が取り入れられた。つまり、.NET Core 5では、個々のアセンブリが個々のNuGetパッケージと対応し、パッケージ名はアセンブリ名と同じものになる(NuGetパッケージのバージョンも、アセンブリのバージョンと同じになる)。そして、それぞれのアプリが必要なコンポーネントをNuGet(VSのコンポーネントマネージャー)を利用して管理するのだ。
プロファイル方式のAPI管理を行うのではなく、NuGetパッケージによるコンポーネントの管理を行うことで、アプリがターゲットとするプロファイルが何か、そのプロファイルで使用できるAPIが何かに頭を悩ます必要がなくなり、単に必要なAPIを含むコンポーネントをアプリが利用すればよいだけだ。
このようにモジュール化を行うことには他にもメリットがある。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について簡単に見ておこう。
Copyright© Digital Advantage Corp. All Rights Reserved.