特集：第1回 スタートアップ.NET――基礎から始める.NET：dev .NET（6/8 ページ）

[大澤文孝，ITmedia]

.NET Frameworkは開発言語に依存しない仮想コード

　.NET Frameworkは、Win32のバイナリコードではなく、「MSIL（MicroSoft Intermediate Language）」と呼ばれるOSに依存しない仮想コードを使う。仮想コードで書かれたバイナリファイルも、Win32アプリケーションと同じく「dll」や「exe」の拡張子を持つ。しかし内部構造は大きく異なる。内部がMSILであるバイナリのことを「アセンブリ」と呼ぶ。

　アセンブリを実行する機能を持つのは、「CLR（Common Language Runtime）」だ。CLRは、アセンブリを実際のOSやCPUのコードに変換して実行する機能をもつ。.NET Frameworkを利用したプログラムを記述するためには、MSILのコードを最終的に書き出すコンパイラを用いる。このコンパイラは、開発言語製品でいえば、「Visual Studio .NET」であるが、無料でダウンロードできる「.NET Framework SDK」を使う方法もある。

　マイクロソフトが提供する.NET Framework対応の開発言語は、「Visual Basic .NET」（以下、VB.NET）「C#」「JScript」の3種類だ。しかしサードパーティからは、他の開発言語のコンパイラも提供されている。

　.NET Frameworkでは、開発言語によって、できることとできないことの区別が無くなったのもポイントだ。なぜならば、.NET Frameworkでは、言語の機能を使ってアプリケーションを構築するのではなく、.NET Frameworkのクラスライブラリを使ってアプリケーション構築をするためだ。クラスライブラリは、どの言語からも中立であるため、開発者は、使いやすい言語を使えばよい。

　たとえば、従来、Win32APIアプリケーションを構築するために使っていたVisual Basic 6.0では、手軽にアプリケーションを構築できるものの、Visual Basic 6.0自体で実現できる機能が比較的少なく、高度なアプリケーションを作成できなかった。そのため、Visual Basic 6.0は初心者向けの言語とまでも揶揄された。しかしVisual Basic 6.0の.NET Framework版となるVB.NETでは、Visual C++の.NET Framework版となるC#と比べても何ら変わりがなく、同じアプリケーションを作成できる。実行速度も、VB.NETとC#とで変わらない。

.NET FrameworkからWin32 APIを呼び出すこともできる

　.NET Frameworkでは、豊富なクラスライブラリによって、ほとんどの処理を実現できる。しかし、クラスライブラリでは提供されず、Win32 APIとしてしか利用できないOSの機能もある。そのような場合には、.NET FrameworkからWin32 APIを呼び出しても構わない。また従来の環境では、コンポーネントを構築するために「COM（Component Object Model）」という仕組みが使われていたが、COMを.NET Frameworkから呼び出すこともできる。

　ただし、.NET FrameworkからWin32 APIを呼び出す場合には、途中に変換処理が入るため、その個所で実行速度が若干低下する。

　.NET Frameworkでは、純粋にMSILだけのコードで書かれたプログラムを「マネージドコード（Managed Code）」と呼び、Win32 APIの呼び出しなど、MSIL以外のコードを含むプログラムを「アンマネージドコード（Unmanaged Code）」と呼び区別をしている。アンマネージドコードは、CLRの管理下にない（CLRによってManageされていない）コードという意味だ。

IEでダウンロード自動実行するノータッチデプロイメント

　ここまで説明してきたように、.NET Frameworkでは、基本的には、OSに依存したバイナリを使わずに、仮想コードを使って、最終的にCLRが実行する仕組みになっている。仮想コードを使うメリットは、大別して2つある。

下記のメリットは、アンマネージドコードには当てはまらないのは、言うまでもない。

　ひとつは、CLRさえあればほかのOSでもアプリケーション実行ができるという点だ。しかしながら、現状では、オープンソースの「Mono Project」（関連記事）やフリーソフトの「DotGNU」など、ほかのOSで動作するCLRはごく一部にすぎない。また完全互換ではないため、メリットはあまりない。強いていえば、Windows CE用の「.NET Compact Framework」が提供されている程度である。

.NET Compact Frameworkは、.NET Frameworkのサブセットである。そのため、すべてのクラスライブラリが提供されていない。

　もうひとつのメリットは、CLRでコードを検査することによって、安全性を高められるという点だ。

　.NET Frameworkでは、実際にコードを実行するのはCLRだ。そのため、CLRが事前にコードをチェックすることで、バッファオーバーランなどのセキュリティ上の問題が発生しないかどうかを確かめることができる。そしてさらに、実行する際に、ファイルシステムやネットワーク通信、プリンタなど、クライアントのリソースに対して、セキュリティ上の制限を課すことも可能だ。

　実際CLRでは、「アセンブリがどこから実行されたのか」を把握しており、「ネットワークからダウンロードしたアセンブリは、ファイルシステムの読み書きを一部制限する」といった設定が可能になっている。この制限は、「.NET Configurationツール」のランタイムセキュリティポリシーで設定される（図8）。

図8■.NET Configurationツール。どこから実行したアセンブリに対して、どのような実行許可を与えるのかを設定する

　.NET Frameworkには、Internet Explorerと連携して、Webからダウンロードしたアセンブリを直接実行可能な機能が備わっている。この機能は、「ノータッチデプロイメント」と呼ばれる。

　.NET Frameworkがインストールされている環境のInternet Explorerでは、exe形式へのリンクをユーザーがクリックした際、対象がアセンブリかどうかを調べている。そしてアセンブリであれば、そのアセンブリ（exe形式ファイル）をダウンロードした後、直接CLRで実行する仕組みだ。つまり、ノータッチデプロイメントとは、図9のように、Internet Explorerでexeファイルへのリンクをクリックしたら、そのままWindows上で実行する機能そのものである。

図9■ノータッチデプロイメント。ハイパーリンクをクリックするだけで、ダウンロードして即実行される。ただし.NET Configurationツールの設定で禁止した処理が実行されようとすると、そこで強制終了する

　ノータッチデプロイメントは、ActiveXコントロールや、通常のexe形式ファイルをダウンロードして実行するのと見た目で似ている。しかし、実行されるコードは仮想コードであり、CLRによって実行されるという点が異なる。ActiveXコントロールは、Win32のバイナリであり、場合によっては不正なコードが配布されている可能性もある。

　しかしノータッチデプロイメントでは、.NET Configurationツールで設定されているセキュリティしか与えず、制限をかけて実行する。標準では、任意のファイルの読み書きはもちろん、ネットワークの通信も、アセンブリを送り出したサーバとしかやり取りできないようになっている。当然、アンマネージドコードの実行も禁止だ。そのためユーザーは、ActiveXコントロールよりも安全な実行が可能なのである。実際、.NET Framework 1.1では、アセンブリをクリックして実行する場合、ユーザーに確認をせずそのままアプリケーション実行をしている。

.NET Framework 1.0では、ノータッチデプロイメント機能は、標準で無効になっていた。

　ノータッチデプロイメントは、構築したアプリケーションをユーザーに配布する場合に真価を発揮する。アプリケーションのアセンブリをWebサーバ上に置き、リンクを張るだけでよいからだ。インストーラを用意する必要も無く、アプリケーションをアップデートする際は、アセンブリを置き換えるだけですむ。