グローバル アセンブリ キャッシュ

グローバル アセンブリ キャッシュ (: Global Assembly Cache略称GAC) は、マイクロソフト仕様の共通言語基盤 (: Common Language Infrastructure、略称:CLI) においてのコンピューター全域で共有されるCLIアセンブリキャッシュである。

グローバルアセンブリキャッシュは中央リポジトリで特別に管理されており、そのようなアプローチはDLL地獄のような欠点につながった共有ライブラリの概念の欠陥に伴う落とし穴を避けるために有効である。

必須要件

[編集]

GAC内のアセンブリは異なるコード バージョン間でのサイド バイ サイド実行を可能にする特定のバージョン管理スキームに従う必要がある。具体的には、このようなアセンブリは厳密に命名されている必要がある。

使用法

[編集]

GACを使用するには基本的に2つの方法があり、それらはグローバル アセンブリ キャッシュ ツール (gacutil.exe) と、アセンブリ キャッシュ ビューアー (shfusion.dll) である。

グローバル アセンブリ キャッシュ ツール

[編集]

"gacutil.exe" は.NET 1.1に搭載され、また.NET SDKで引き続き使用されている、古いコマンドライン ユーティリティである[1]

下記のコマンドを使用してGAC内の共有アセンブリの可用性をチェックできる。

gacutil.exe /l <assemblyName>

GACに共有アセンブリを登録するには下記のコマンドを使用する。

gacutil.exe /i <assemblyName>

もしくは下記の場所に共有アセンブリをコピーする[注釈 1]

%WinDir%\assembly\

ただし.NET 4以降のGACの場所は下記であることに注意されたい。

%WinDir%\Microsoft.NET\assembly\

その他のオプションについては、下記のように"/?"コマンドラインオプションフラグを使用すると簡易的に説明される。

gacutil.exe /?

アセンブリ キャッシュ ビューアー

[編集]

アセンブリ キャッシュ ビューアーは新たなインターフェイスとしてWindowsエクスプローラーに統合されている[2]

"%WinDir%\assembly\" または "%WinDir%\Microsoft.NET\assembly\" を参照すると、キャッシュに格納されているアセンブリが、それらのバージョン、カルチャー、公開キー トークン、およびプロセッサ アーキテクチャと共に表示される。アセンブリはドラッグ アンド ドロップによりインストールされ、選択しDeleteキーを押すかまたはコンテキスト メニューを使用してアンインストールされる。なお.NET Framework 4の導入により、アセンブリ キャッシュ ビューアーのシェル拡張機能は廃止された[1]

活用例

[編集]

1つのコンピューターに"AssemblyA"と名付けられた2つのCLIアセンブリがあり、 1つはバージョン1.0、もう1つはバージョン2.0とする。それらは両方とも"AssemblyA"としてコンパイルされることが必要だが、ファイル名が同じなために双方が1つのFAT32ファイル システム上の同じディレクトリに存在することはできない。代わりにプログラムはGACの仮想ファイル システムを使用し、それぞれに必要なバージョンのアセンブリを使用することができる。

実装

[編集]

コンストラクト[要説明]としてのGACはWindows OS内には実在しない。GACはCLIによって実装され管理されている。"%SystemRoot%" 内の "assembly" と名付けられたフォルダーおよび "Microsoft.NET\assembly" (.NET 4以降) フォルダーには、アセンブリのバージョンおよび公開キー トークンが参照できるよう、マネージドファイル名を持ったグローバルに使用できるアセンブリのすべてが含まれている。これによって各バージョンのアセンブリが同じフォルダー内に存在することができ、以降のバージョンは通常のようにコードのエントリ ポイントの場所の保存をせずとも呼び出されることができる。Windowsエクスプローラーは、コマンドラインからのインストールが許可されない場合にのみ、このフォルダーにドラッグ アンド ドロップ インストールを行う。呼び出し元のアプリケーションは、参照時にアセンブリのバージョンを指定し、実行時には単にファイル名を指定することで、正しいバージョンのアセンブリを使用することができる。

落とし穴

[編集]

グローバル アセンブリ キャッシュ メカニズムはかつてのDLL地獄を避けるために役立つが、いまだにいくつかの欠点がある。例えば下記のようなものが挙げられる[2]

  • 既定では、アプリケーションはそのコンパイルに使用された.NET Frameworkのバージョンでのみ実行可能なので、.NET Frameworkの新しいバージョンがインストールされたマシン上でアプリケーションが失敗する可能性がある(たとえアプリケーションが新しいバージョンとともに適切に通常実行されるであろう場合であっても)。
  • (アプリケーションで使用する) コア.NETの呼び出しがいくつかのバージョンのみでサポートされている場合、条件付きコンパイルを使用する必要がある。
  • GACメカニズムであっても、ネイティブ コードに依存する.NETアプリケーションは、非互換性のリスクがある。
  • GACに追加されているすべてのアセンブリは厳密に命名されている必要がある。だがアセンブリの「厳密な名前」を作るプロセスはいくつかの状況下では非常に困難な作業になる。たとえば、アセンブリが厳密に命名されていない別のアセンブリに依存する場合、GACには登録できない。厳密に命名されていないサード パーティ アセンブリのコードをプログラマが所有していない場合、厳密な名前に変換することは現実的には不可能である。
  • 標準のWindows APIを使用したファイル参照では、エクスプローラーがGACのユーザーフレンドリービューを表示しているとき "assembly" フォルダーの下にあるDLLの選択は許されていない。

脚注

[編集]

注釈

[編集]
  1. ^ 環境変数"%WinDir%"はシステム環境に応じて"C:\Windows"などに展開される。

出典

[編集]
  1. ^ a b How to: View the Contents of the Global Assembly Cache”. マイクロソフト. 2010年7月22日閲覧。
  2. ^ a b John, Mueller (2005年2月11日). “Ten Managed Application Pitfalls that Kill Version Compatibility”. devsource.com. 2008年1月26日閲覧。

外部リンク

[編集]