技術解説 DLL Hellを解消する新しいWindowsインストーラとアセンブリ コラム：.NETとWin32のサイド・バイ・サイド共有コンポーネント Peter Pawlak 2003/03/13 Copyright(C) 2003, Redmond Communications Inc. and Mediaselect Inc.

　.NET Frameworkで構築されたアプリケーションと、Windows XPで導入されたWin32コンポーネントのバージョン特定機能を利用できるWin32アプリケーションに関しては、DLL Hell（コンポーネント更新で生じるバージョンの競合）の主要な原因は解消された。

　どちらのケースも、同じコンポーネントの複数のバージョンを同時に格納、実行し、適切なバージョンのコンポーネントに関数呼び出しをリダイレクトするメカニズムを備える。それぞれのアーキテクチャは全く異なるが、どちらも同じような方法でDLL Hellの問題を解消している。

　いずれのケースでもカギとなるのが「アセンブリ」の概念だ。アセンブリは、アプリケーションが正しいバージョンの共有コンポーネントにアクセスするために必要な重要な情報を提供する。ただし、.NETアセンブリとWin32アセンブリは異なるため、混乱しないように注意しなければならない。

.NETアセンブリとWin32アセンブリの違い

　概念的には、アセンブリとはコンポーネントのプログラム・コードの集合に「マニフェスト」と呼ばれる文書を加えたものだ。マニフェストには、コンポーネントについて説明したXMLデータが含まれる。例えば、名前、バージョン、デジタル署名、公開するクラス（つまり関数）、ほかのコンポーネントとの依存関係、それらのコンポーネントのロケーションに関する情報などだ。

　.NETアプリケーションとコンポーネントはアセンブリとしてパッケージされ、アセンブリは.exeファイル（アプリケーションの場合）または.dllファイル（コンポーネントの場合）、および組み込みマニフェストで構成される（.exeファイルと.dllファイルには、Microsoft Intermediate Language（MSIL）形式の組み込みプログラム・コードが含まれる）。

　.NETアプリケーションが起動したり、コンポーネントが呼び出されると、Windowsと.NET FrameworkのCommon Language Runtime（CLR）がアセンブリを解凍し、マニフェストと照合して、MSILコードをマシン言語にコンパイルし、アセンブルしてロードする。

　一方、Win32アセンブリは従来型のWin32 EXE、またはDLLで構成される。Windows XPでは、新たに.NETの組み込みマニフェストと同様の役割を果たすXMLベースのマニフェスト・ファイルが個別に追加される。

　さらにWin32アセンブリは、グローバルに共有されるコンポーネントの格納場所が.NETアセンブリと異なる。.NET共有アセンブリは、.NET Frameworkのクラス・ライブラリもすべて含め、GAC（グローバル・アセンブリ・キャッシュ）と呼ばれる専用のシステム・ディレクトリ構造に格納されるが、Win32アセンブリは「WinSxS」と呼ばれる別個のシステム・ディレクトリにインストールされる。後者のサブディレクトリ構造では、2つのバージョンのDLLが同一のファイル名を持てるため（例えば「comctl32.dll」など）、ネーミングをめぐる競合を回避できる。

Win32のバージョン競合を解消

　.NET Frameworkは、コンポーネントのバージョン競合の問題をすべて解消できる機能をネイティブに備えている。ただし、Windows XPやWindows Server 2003以前、グローバルな共有コンポーネントを利用するレガシーなWin32アプリケーションは、それに相当するメカニズムを持たなかった。

　この新しい機能を活用できるWin32アプリケーションに関しては、Windows XPとWindows Server 2003はマニフェストの情報を使って、どのバージョンのコンポーネントに依存しているかを確認することで、競合問題を解消できる。同じディレクトリに含まれる専用コンポーネントであれば、適合するバージョンのコンポーネントをロードするようにOSに要求するだけだ。

　ただし、グローバルに共有されたWin32コンポーネントの場合、新サービスはコンポーネントのマニフェストに含まれる情報やそのほかのポリシー・ファイルに含まれる規則に基づき、適切なバージョンのファイルへ自動的にコールをリダイレクトする。

　これにより、MicrosoftやISVは既存のアプリケーションの動作に影響を及ぼすことなく、共有コンポーネントをアップグレードできる。もはや、古いコンポーネントを上書きする必要もなければ、レジストリ情報を使ってコンポーネントを探す必要もない。

　例えば、Windows XP Service Pack 1は、Windows XPのオリジナル・リリースで提供されているcomctl32.dll 6.0.0.0と並行してcomctl32.dll version 6.0.10.0をインストールする。下の図にあるとおり、古いバージョンのcomctl32.dllを必要とするアプリケーションは、まず自身のマニフェストを確認し、必要なバージョンを確認して、それをSxS Managerと呼ばれる新しいWindowsカーネル・コンポーネントに伝える。

共用Win32アセンブリ

SxS Managerが適切なバージョンのDLLをロードする。

　SxS Managerは共有コンポーネントディレクトリへのコールの仲介役として、コンポーネント・アセンブリのマニフェストから収集した情報を基に、適切なバージョンを探し出し、ロードする。複数のアプリケーションから同時にコールがある場合も、両方のDLLをロードして、同時に実行できる。

INDEX
	［技術解説］DLL Hellを解消する新しいWindowsインストーラとアセンブリ
	1．クライアント・ソフトウェアのインストールに関わる問題
	2．Windows Installer 2.0の新機能
	3．新しいサイド・バイ・サイド・コンポーネントのサポート
	コラム：アプリケーションのインストール時に何が起きているか？
	コラム：インストール技術の改善の歴史
	コラム：Windows Installerの概要
	コラム：.NETとWin32のサイド・バイ・サイド共有コンポーネント

　

技術解説

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）