「最新.NET技術がよく分からない」と感じる人のための用語整理：特集：ASP.NET 5を探る（1/3 ページ）

KRE、XREにDNX。ASP.NET 5を理解する前によく分からない用語がたくさんある。そこで、これらを整理して、ASP.NET 5とDNXに備えよう。

[かわさきしんじ，Insider.NET編集部]

　 　 　 　 　 　 　 　

連載目次

　ASP.NET 5はマイクロソフトが提供する次世代のWebアプリ用フレームワークだ。オープンソース的な開発アプローチを採り、急速なペースで進化を続けている。だがオープンな開発体制が災いしたのか、この技術に関連する用語は時と共に大きく変化をしてきた。本稿では、ASP.NET 5関連する用語、特にその実行環境となるDNXやそれに関連する用語を整理しておこう。

ASP.NET 5とDNX

　まず覚えておきたいのは「DNX」（.NET Execution Environment）という語と、「ASP.NET 5≠DNX」であるということだ。何となく「DNXってASP.NET 5のことでしょ？」と思っている方もいらっしゃるかもしれないが、DNXは「.NETアプリをクロスプラットフォームで実行するために必要な要素をまとめた環境」であり、ASP.NET 5はこの上で動作する（もともとDNXは、ASP.NET 5アプリの実行環境として開発が始められたが、今ではそのターゲットはASP.NET 5だけではないということだ）。

DNXはASP.NET 5を実行する環境

　図に示したように、DNXの下に位置するOSとしてはWindows／OS X（Mac）／Linuxが存在する。そして、これらのOS上で.NETアプリを開発／実行できるように、ランタイムや、ランタイム／アプリを各OS上でホストするコードなどを提供するのがDNXだ。

DNXの特徴

用語：DNX

DNX： Windows／OS X／Linuxなど、クロスプラットフォームで.NETアプリを実行するための環境。もともとはASP.NET 5の実行環境として開発が始まった。以前はKRE（K Runtime Environment）、XRE（Cross-platform Runtime Environment）などと呼ばれていた。なお、「K」はASP.NET 5の礎となったOWINのマイクロソフト実装「Katana Project」を表しているといわれている。

　DNXには次のような特徴がある。

• 自己完結型の実行環境
• 1台のコンピューター上でのサイドバイサイド実行が可能
• 互換性のあるDNXがインストールされていれば、OSの種類に関係なく、アプリを実行可能
• NuGetを使用したパッケージ管理により高いモジュール性を実現
• ビルドを行わずそのままソースコードから実行可能（Roslynを使用）

　ここでいう自己完結型とは、上でも述べているように「DNXにアプリを開発／実行するための全ての要素が含まれている」ということだ。そして、DNXを1台のコンピューターに複数インストールして、それらをサイドバイサイドで実行できる。DNXが自己完結的であり、サイドバイサイドに実行できることにはいくつかのメリットがある。

　一つには、開発マシンあるいはアプリを実行するサーバー上の.NET環境のバージョンアップとアプリが分離されることだ。あるDNXを対象に作成したアプリは、それが依存するDNXやアセンブリがありさえすれば、どこでも実行できる。異なるバージョンのDNXで作成したアプリを1台のコンピューター上で動作させることも問題なく行える。

1台のコンピューター上で複数バージョンのDNXを実行可能

　コマンドラインで作業をしている場合に、現在の環境で使用するDNXを切り替えるのに使うのがdnvmコマンドだ（dnvmは「.NET Version Manager」の意）。

用語：dnvmコマンド

dnvmコマンド： 現在の環境で使用するDNXを管理するコマンド。最新バージョンのDNXのインストール、インストールされているDNXで使用するもの選択などを行う。旧称はKVM（K Version Manager）。

dnvmコマンドは「dnvm コマンド オプション」の形式で使用し、実行できるコマンドには次のようなものがある（抜粋）。

• upgrade： 最新のDNXをインストールする
• list： インストールされているDNXを一覧表示する
• install： 指定したバージョンのDNXをインストールする
• use： 現在開いているコマンドプロンプトやシェルで使用するDNXのバージョンを指定する

dnvmコマンドでは安定版に加えて、開発版のDNXもインストールできる。これには「dnvm upgrade」コマンドまたは「dnvm install」コマンドで「-u」オプションを指定する（「u」は「unstable」を表す）。

また、現在選択されているDNXのバージョンに関係なく、指定したバージョンのDNXを使用して、後述するdnxコマンドやdnuコマンドを実行することも可能だ。これには「dnvm run」コマンドや「dnvm exec」コマンドに実行対象のDNXバージョンと実行するコマンドを指定する（詳しくは「dnvm help」を参照のこと）。一時的に、別バージョンのDNXでのアプリの実行確認を行いたいといった場合に便利に使える。

　もう一つのメリットは、あるDNX上で開発したアプリを、別のコンピューターで実行する場合でも、そのコンピューターのネイティブな環境がどうかに関係なく、同じDNXを用意してやるだけでアプリを実行できることだ。OSが異なっていても、必要なDNXとアセンブリがあれば、アプリをクロスプラットフォームで実行できるのだ。

DNXはクロスプラットフォームでのアプリの開発／実行を可能にする

　また、DNXでは、マイクロソフトの次世代コンパイラープラットフォーム「Roslyn」を使用することで、アプリの実行時コンパイルが可能となっている（これまでは、Visual StudioでASP.NETアプリをコンパイルし、これをサーバーに配備した後、アプリ実行時にランタイム上でさらにコンパイルが行われるのが一般的だった）。OS X／Linuxでも実行可能なRoslynが登場したことで、Windows＋Visual Studio以外の環境でのDNXアプリ（とは結局、現状ではASP.NET 5アプリ）の開発に対するハードルが低くなったといえる（加えて、先日発表されたVisual Studio Codeもある）。

　DNXでは、NuGetによるパッケージの取得／作成もその特徴に挙げられる。必要なアセンブリが単独のパッケージとしてNuGetで配布されているので、必要なものだけを必要なだけ開発するアプリに取り込めるのだ。これは、モノリシックなSystem.Webアセンブリに依存する従来のASP.NETとは大きな違いだ。