【デブサミ2008】.NET Frameworkの仕組みを再確認、不測のトラブルに備えよう

デブサミ2日目のセッション「今こそ知りたい！ .NET Frameworkのメカニズム」では、マイクロソフト株式会社 新村剛史氏が、.NET Frameworkの概要および実行の仕組みについて語った。既存技術のおさらいが中心だが、入門者だけでなく、実際に使っている.NET Framework開発者にとっても、.NET Frameworkの理解を深めておくことは、開発環境では動くが実行環境で動かない、DLLが見つからないっといった不測のトラブルを防ぐのに役立つだろう。

　デブサミ2日目のセッション「今こそ知りたい！ .NET Frameworkのメカニズム」では、マイクロソフト株式会社 新村剛史氏が、.NET Frameworkの概要および実行の仕組みについて語った。

マイクロソフト株式会社 新村剛史氏

　既存技術のおさらいが中心だが、入門者だけでなく、実際に使っている.NET Framework開発者にとっても、.NET Frameworkの理解を深めておくことは、開発環境では動くが実行環境で動かない、DLLが見つからないっといった不測のトラブルを防ぐのに役立つだろう。

.NET Frameworkの概要

　.NET Frameworkはマイクロソフトが開発したアプリケーションの開発/実行環境。複数のバージョン（1.0/1.1/2.0/3.0/3.5）があるが、1.0から2.0までが機能強化であったのに対し、3.0、3.5はそれぞれ機能拡張と進化の形が一部異なっている。1.0/1.1/2.0は共存関係で別個のものとして扱われるが、3.0には2.0が、3.5には2.0、3.0が含有される。

.NET Frameworkのバージョン比較

　すべてのバージョンに一貫した特徴として、CLR（Common Language Runtime）と呼ばれる共通言語ランタイム上で動作する。異なる開発言語間の連携が容易であったり、高度なバージョン管理、セキュリティ管理を行うことができる。

CLR上で動作するアプリケーション

ソースコードからコンパイルまで

　ソースコードは、C#やVisual Basicといった言語別のコンパイラにより、「アセンブリ」に変換される。アセンブリはEXEやDLLといった、配置とバージョン管理を行う単位で、CLRが解釈できる共通の中間言語MSIL（Microsoft Intermediate Language）で記述されている。

アプリケーション動作までの流れ

　アセンブリにはプライベートアセンブリと共有アセンブリの2種類があり、大きく分けて次の4つの要素で構成される。Ildasm.exeというMSIL逆アセンブラを利用して、実際に中身を確認することも可能だ。

• MANIFEST
アセンブリ自体の情報（ID、厳密名、バージョンなど）を記述したもの。アセンブリを検索する手がかりになる。
• IL
JITコンパイラへの入力となる中間言語。
• メタデータ
アセンブリに含まれるクラスやメンバの情報。
• リソース
文字列や画像、永続化されたデータなど。

　アセンブリ名には、単純な「簡易名」（ファイル名と連動したテキスト）と、開発者に公開キーを割り付けて一意に識別できるようにした「厳密名」（テキスト＋バージョン＋カルチャ＋公開キー）がある。厳密名は共有DLLやバージョン管理で利用され、DLLのバージョン互換性の不具合による「DLL HELL」の回避や、適切なCLRのバージョンで実行（サイドバイサイド実行）に役立つ。

アセンブリから実行まで

　EXEファイル（プロセスアセンブリ）を実行すると、まずCPUアーキテクチャ（32bit/64bit等）に合わせて「MScorEE.dll」、.NET Frameworkのバージョンに合わせて「MSCorWks.dll」が選定される。続いて、アセンブリローダにより、アセンブリのマニフェスト/署名確認、アセンブリのバージョン選定/検索、パーミッションの設定などが行われる。

　また、中間言語MSILのコードは、JIT（Just In Time）コンパイラにより、実行可能なネイティブコードにコンパイルされた後、メモリに格納され、実行される（一度コンパイルされたものは再度コンパイルされない）。

アセンブリの配置場所・配置方法

　アセンブリの配置場所には注意が必要だ。.NET Frameworkでは、アセンブリ単位で高度なバージョン管理が行われるため、従来のようなレジストリへの登録が不要。また、PATH環境変数を利用しないため、DLLの場所をPATHに追加してもうまく動かない点に気をつけたい。

　必要なアセンブリは、GAC（Global Assembly Cache）と呼ばれる共有スペース、構成ファイルの<codeBase>に記述されている場所の順で検索され、見つからない場合はProbingというプロセスに入る。アプリケーションが存在するディレクトリ以下で「アセンブリ名＋.dll/.exe」が検索され、それでも見つからないと例外（System.IO.FileNotFoundException）となる。なお、原則Probingは避け、GACや<codeBase>を利用すべきとしている。

　なお、GACに登録するには厳密名を持つ必要があり、登録されているアセンブリ一覧は「Windows」フォルダ直下の「assembly」フォルダで確認できる（実際にアセンブリがこのディレクトリに存在するわけではない）。「Gacutil.exe」というユーティリティを利用して追加/削除することも可能だ。

　アセンブリの配置方法には、XCopy（ツリー構造のままコピー）による単純な配置、Windowsインストーラ（.msiファイル）による配置、ClickOnce（インターネット経由のインストール）による配置がある。

.NET Frameworkのセキュリティ

　.NET Frameworkが標準で備えているセキュリティは、大きく次の2種類がある。

• コードアクセスセキュリティ
プログラムの実行時に、アセンブリに対して、リソースアクセスや特定動作に関して行われるアクセス制御。セキュリティーポリシーに沿ってアクセス許可が付与される。コマンドラインツールの「Caspol.exe」や、Microsoft 管理コンソール（MMC）で管理できる。
　
• エビデンス（アセンブリで何であるかの証明）
• コードグループ（エビデンスに基づいた組み合わせ）
• アクセス許可セット（許可のグループ）
• セキュリティポリシー（コードグループとアクセス許可セットの組み合わせ）
　
• ロールベースセキュリティ
アプリケーションの「役割」ごとにグループ化（ロール）し、ロール単位でセキュリティ制御を行う。ロールはWindows OSのアカウントに依存しない（マッピングは可能）。主にビジネスロジックの制御で利用する。一つの実行スレッドに対して、一つのPrincipalオブジェクト（ユーザーの識別情報/所属するロールなど）が関連づく。

まとめ

　新村氏は、このセッションのキーポイントとして「サイドバイサイド実行」「アセンブリとその配置」「コードアクセスセキュリティ」を挙げ、これらを押さえておくことがアプリケーションのトラブル回避に有効である、と述べた。

　また、通常一日かけてレクチャーする内容を小一時間に圧縮したため、表面をなぞる内容になっており、より詳細な理解の一助となる書籍として『プログラミング.NET Framework 第2版』（Jeffrey Richter 著、吉松史彰 監訳、日経BPソフトプレス）を紹介した。興味を持った方はぜひ参照してみるとよいだろう。