技術解説 DLL Hellを解消する新しいWindowsインストーラとアセンブリ 2．Windows Installer 2.0の新機能 Peter Pawlak 2003/03/13 Copyright(C) 2003, Redmond Communications Inc. and Mediaselect Inc.

---

　Windows Installer 2.0はWindows Installerの最新版だ。Windows Installerベースのアプリケーション・パッケージ（つまり、.msi拡張子を持つアプリケーション）のインストールとアンインストールを処理する。Windows Installer 2.0はWindows XPとWindows Server 2003にバンドルされる。また、Windows 2000 Service Pack 3を使えば、古いバージョンのWindows Installerを新版にアップグレードできる。Windows Installer 2.0はまた、Windows 9xおよびWindows NT 4.0 Service Pack 6システム対応のアプリケーションとともに再配布できる。

　Windows Installer 2.0には新機能が追加されたほか、バージョン1.0、1.2の制限事項が一部解消されている。前バージョンのWindows Installer向けに書かれたパッケージは、バージョン2.0とも完全な互換性がある。ただし、新機能は反映されないため、新機能を活用するには、パッケージの書き換えが必要だ（Windows Installerの概略については、コラム「Windows Installerの概要」を参照）。

　Windows Installer 2.0の主な変更点と改善点は以下のとおり。

●署名付きパッケージのサポート
　新バージョンでは、Windows Installerパッケージにデジタル署名を付けられるようになっており、Windows Installerはインストールに先立って、破損あるいは改ざんされたアプリケーション・ファイルがないか確認できる。

　さらにWindows Server 2003は、署名付きパッケージと連動して、ソフトウェア制限ポリシーをサポートする。これにより、管理者は一定の基準（「会社のIT部門のデジタル署名を含む」など）を満たさないアプリケーションのインストールを禁止できる。ただし、このソフトウェア制限ポリシーはWindows XP以降が動作するコンピュータにしか対応せず、ポリシーの設定にはWindows Server 2003 グループポリシーが必要だ。

●改善されたインターネット・ダウンロード
　Windows Installerの新バージョンは、ソフトウェアをインストールする権限を持つユーザーが、Webページのリンクをクリックしてアプリケーションをインストールしようとした場合、まずMSIファイルだけダウンロードし、その後、ユーザーが選んだインストールのオプションに基づき、必要なキャビネットファイル（拡張子は.cab）のみをダウンロードするようになっている。これにより、インストールの時間とネットワークに与える影響を軽減できる。これまでのバージョンでは、インストールを開始する前にすべてのソースファイルをダウンロードする必要があった。

●64bitのサポート
　64bit版のWindowsに32bitと64bitのアプリケーションをインストールできるのは、バージョン2.0だけだ。

●オリジナル・メディアの必要性を軽減
　新バージョンでは、ほとんどの場合、インストール・プログラムが更新やパッチを実行中に、オリジナル・メディアを用意する必要はない。Windows Installer 1.xでは、既存のファイルをオリジナルのソース・メディアと照合し、変更がないか、正しいバージョンかどうかを確認する必要があった。

　Windows Installer 2.0はファイル・ハッシュを計算し、それをMSIファイルに格納されているハッシュ値と比較する。パッケージ開発者が特に要求しない限り、ファイル・ハッシュがオリジナルのハッシュと適合してさえいれば、オリジナル・ソースへのアクセスは不要だ。このおかげで、パッチ適用と更新作業の効率がアップした。

●カスタム・アクションのサンド・ボックス
　Windows Installer 2.0はインストール時にカスタム・アクションを実行するための「サンド・ボックス」と呼ばれる隔離型セキュリティ・パーティションを利用する。カスタム・アクションは、ISV（独立系ソフトウェアベンダ）がWindows Installerでサポートされていないアクションを実行するための方法だ。

　例えば、Javaアプレットのインストールを含んだアプリケーション・セットアップを作成する場合、ISVはJava Package Managerを使ってJavaコードを登録する独自のカスタム・アクションを作成できる（Java Package Managerを使えば、ローカル・システムにインストールされたJavaコードを把握し、コードをほかのアプレットと共有できる）。

　Windows Installer 2.0はサンド・ボックスを利用して、カスタム・アクションにWindows Installerサービスへの安全かつ厳密な進入、退出路を提供する。カスタム・アクションの記述に不備がある場合、そのカスタム・アクションからWindows Installerサービスが管理する専用データにはアクセスできない。そのため、不適切なカスタム・アクションが重要なデータに損傷を与えたり、Windows Installerの高い特権を悪用するような事態を防げる。

●イベント・ログの改善
　Windows Installer 2.0では、これまでのバージョンよりもはるかに詳細なインストール情報がイベント・ログに記録されるため、インストールに関する問題のトラブル・シューティングが容易だ。

　さらにWindows Installer 2.0には、.NET Frameworkで動作するマネージドコード・アプリケーションのサポート、Windows XPとWindows Server 2003の新しいサイド･バイ･サイド・コンポーネントのサポートも含まれる。

.NET Frameworkアプリケーションのインストールは簡単？

　.NET Frameworkでは、Visual Studio .NET（VS.NET）とWindows Forms（WinForm）のクラス・ライブラリを使って、新しいタイプのシック・クライアント・アプリケーションを開発できる。

　.NET Frameworkは、従来型のWin32アプリケーションやCOMアプリケーションのインストール、動作には何ら影響を及ぼさないが、.NETアプリケーションに関しては状況が若干異なる。.NETコンポーネントの場合、もはやインストール時にほかのコンポーネントに正しく場所を認識させるためにシステム・レジストリに登録する必要はない。

　また、.NET Frameworkはコンポーネントのバージョン管理機能を内蔵するため、期待と異なるバージョンのコンポーネントをコールすることもない。

　こうした機能を理由に、Microsoftでは「.NETコンポーネントのインストールは、単にファイルをファイル・システム内の適切な場所にコピーするだけでよい」としている（XCOPYと呼ばれる方法）。

　確かにXCOPYは、ASP.NETアプリケーションなど、一部のアプリケーションでは可能だ。だが、実際この方法を実用的に利用できるのは、比較的シンプルなWinFormベースの.NETシック・クライアント・アプリケーションに限られる。

　全体的に見れば、確かに.NET Frameworkはシック・クライアントのインストールを改善しているが、そのプロセスは決して自動化されていない。コンポーネント登録の必要がなくなったとはいえ、これまでCOMアプリケーションやWin32アプリケーションが抱えていたインストールの問題の多くは、依然として.NETアプリケーションにも当てはまる。

• グループポリシーで設定を一元管理するアプリケーションの場合、依然としてWindowsレジストリからユーザーごと、あるいはマシンごとの設定データを読み書きする必要がある。バックグラウンド・サービスとして動作するアプリケーションの場合も、Windowsレジストリを使って起動情報を保存する必要がある。

• デスクトップやメニュー・ショートカットを使って、ユーザーがアプリケーションを起動できるようにする必要がある。

• 管理者特権を持つローカル・ユーザーにアプリケーションのアップグレード、修正、アンインストール手段を提供するためには、Windowsの「プログラムの追加と削除」機能との統合が必要。

• インストール・プロセスには、ターゲット・アプリケーションのディレクトリを作成したり、書き込んだり、インストールしたファイルに適切な許可を設定したりするための十分な権限が必要。

• 確実なインストールを実行するために、インストール・プロセスは各種の一般的なタスクを実行する必要がある。例えば、依存関係の確認、例外処理、必要なコンポーネントがすべて確実に正しくインストールされたかどうかの確認（そうでない場合には、インストール以前の状態にロールバックする必要がある）など。

　さらに、アプリケーションが.NET FrameworkとCOMとの相互運用性を活用したい場合、COMコンポーネントを登録する必要もある。

　以上の要件のいずれにも該当しない.NET Framework WinFormアプリケーションであれば、XCOPYでも問題ないはずだ（どのような場合にXCOPYが適切かについては、本記事の最後に示す参考資料を参照）。

　XCOPYを利用できるケースでは、「ノー・タッチ」と呼ばれるテクニックを使える可能性もある。これは、ユーザーがブラウザからWebページのリンクをクリックするだけで、WinFormアプリケーションがダウンロードされ、実行されるというもの。この方法は、Webアプリケーションのセルフサービス的な要素と、シック・クライアント・アプリケーションの優れたインターフェイスと高速な性能という、双方の特性を組み合わせたものだ。

　.NETアプリケーションのメリットの1つは、Windowsユーザーや開発者の間でDLL Hellとして有名なバージョン絡みの問題に遭遇することなく、バージョン付きのコンポーネントや共有コンポーネントを利用できる点だ。内蔵のバージョン管理機能により、アプリケーションのインストールや更新が容易になり、既存のアプリケーションの動作を中断させる可能性も少ない。アプリケーションのセットアップ・ルーチンを作成する開発者は、コンポーネントの登録や同じDLLの複数のバージョンによって生じるファイル名の競合といった問題に、もはや頭を悩ませる必要はない。

　Microsoftは.NET Frameworkのサポートを念頭に置いて、Windows Installer 2.0を設計している。Windows Installer 2.0は.NETアプリケーションのインストールに使えるほか、.NETアプリケーションに自己回復機能を提供する。

　またWindows Installer 2.0は、共有.NETアセンブリをGAC（グローバル・アセンブリ・キャッシュ）と呼ばれるストレージ・ロケーションにインストールするためにも必要だ。さらにWindows Installer 2.0には、リファレンス・カウントの更新を行い、依存するアプリケーションがすべて削除されるまで、共有.NETコンポーネントが削除されないように管理する役割もある。

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

　

技術解説

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