Microsoft Windows Installer

Windows Installerは、Windowsでソフトウェアのインストール・メンテナンス・削除を行うエンジンである。コードネームはDarwin。以前はMicrosoft Installerと呼ばれていた。インストールパッケージ (installation package) には、インストール処理に関する情報とインストールされるファイルとがパッケージングされている。インストールパッケージのデフォルトのファイル拡張子が"MSI"であることからMSIファイルとも呼ばれる。インストールパッケージは内部的には数十個のリレーショナルデータベースのテーブルからなるOLE構造化ストレージファイルである。Windows Installerには以前のSetup APIと比較して多くの改善点が見られる。例えば、GUIフレームワーク、アンインストールシーケンスの自動生成、デプロイメント機能の強化、Windows Installerを他の実行可能形式のインストーラフレームワーク（InstallShield、WISE（後のバージョンは Windows Installerベースになっている）、NSISなど）と置き換えられるようにしたこと、等が挙げられる。
マイクロソフトはサードパーティーに対しWindows Installerをインストーラフレームワークのベースとすることを推奨している。これは、インストーラの動作をWindows Installerに合わせることで、インストールされた製品のデータベースの一貫性を保つためである。Windows Installerの機能であるロールバックやバージョン管理が正しく行われるためには、内部データベースの一貫性が保たれている必要がある。

**パッケージの論理構造**
パッケージが持つことのできる最も大きな単位がプロダクト (product) である。パッケージは複数のプロダクトのインストール情報を格納できる。プロダクトは全世界で一意な識別子であるGUID（PackageCodeプロパティ）で識別される。また、Windows Installerはプロダクト間の依存性については関与しない。プロダクトは複数の「コンポーネント」からなり、また複数のコンポーネントを「機能」という単位でまとめることができる。

**プロダクト (product)**
単独で動作する一つのプログラム（または、プログラムの集合）をプロダクトと呼ぶ。たとえば、Microsoft Officeなどの単一プロダクトがWindows Installerのプロダクトとなる。プロダクトも全世界で一意な識別子であるGUID（ProductCodeプロパティ）で識別される。プロダクトとパッケージとは別の単位で、一つのMSIパッケージで複数のプロダクトをインストールすることが可能である。たとえば、あるプログラムのフランス語版と英語版とを一つのMSIでインストールできるようにする場合、各言語版のプログラムは別々のプロダクトとなる。

**コンポーネント (component)**
コンポーネント (component) はプロダクトを構成する最小単位である。Windows Installerはコンポーネント単位でインストール・アンインストール処理を行う（すなわち、あるコンポーネントの一部をインストールするような設定は行えない）。コンポーネントはファイル、ディレクトリ、COMコンポーネント、レジストリキー、ショートカット、およびその他のデータを含むことができる。インストーラを起動したユーザーが直接コンポーネントを操作することはできない。
コンポーネントも、全世界で一意な識別子であるGUIDで識別される。これは、一つのコンポーネントを、一つのパッケージ内の複数の機能から、もしくは、複数のパッケージから共有できることを意味する。このような共有コンポーネントのことをマージモジュールと呼ぶ（この仕組みが正しく動作するためには、各コンポーネント間に重複した内容があってはならない）。

**キーパス (key path)**
キーパス (key path) はパッケージの製作者がそのパッケージに必須であると指定したファイル等のことである。キーパスにはファイル、レジストリキー、ODBCデータソースが指定できる。キーパスにはファイルを指定するのが一般的であるため、キーファイルとも呼ばれる。コンポーネントが持つことのできるキーパスは1つだけで、コンポーネントのキーパスを明示しなかった場合は、コンポーネントのインストール先のディレクトリがキーパスとなる。MSIベースのアプリケーションが起動されると、Windows Installerはキーパスに指定されたファイルやレジストリキーが存在するかチェックする。チェックの結果とMSIパッケージの情報との間に不整合があった場合（例えばキーファイルが削除されていた場合）、関連する機能の再インストールが行われる。このプロセスは自動修復機能と呼ばれる。複数のコンポーネントが同じキーパスを持つことはできない。

**機能 (feature)**
機能 (feature) はコンポーネントを階層的にまとめた構造である。一つの機能は複数のコンポーネントからなる。また、機能の中に機能を入れ子にすることもでき、他の機能に含まれる機能をサブ機能(subfeature)と呼ぶ。ほとんどソフトウェアでは、パッケージは単一の機能からなる。大規模なインストールプログラムでは通常、実行時にカスタムセットアップダイアログが表示され、ユーザがインストール・アンインストールする機能を選択できるようにしている。
機能の単位はパッケージの作成者が決定する。例えばワープロプログラムであれば、メインの実行プログラム、ヘルプファイル、オプションとしてスペルチェッカー等がそれぞれ一つの機能となる。

**セットアップのフェーズ**

**UIシーケンス**
UIシーケンスでは、インストール先のシステムの状態を取得し、インストールウィザードを表示し、インストールのオプションをユーザーに選択させる。
ただし、UIシーケンス中では、システムに対する変更は一切行われない。これには以下の3つの理由がある。
#MSIパッケージはquietモードで実行できなければならない。quietモードではGUIは全く表示されず、通常UIシーケンスで指定する情報はすべてコマンドラインから指定される。よって、ユーザインタフェース中で行われるすべてのアクションは、quietモードでは実行されない。quietモードでのインストールを行うには、コマンドラインからmsiexec.exeを/qn（または/qb、/qr）オプション付きで実行する。
#同様に、コントロールパネルのアプリケーションの追加と削除で削除ボタンを押下した場合にはアンインストーラが実行されるが、ここでもインストール時にUIシーケンスで行われたすべてのアクションは実行されない。
#システムに変更を加えるアクションをUIシーケンス中で実行した場合、Elevated Privileges機能で昇格した権限ではなく、インストーラを実行したユーザの権限でシステムへの変更処理が実行されてしまう。これについては以降のセクションで述べる。
UIシーケンス中で行われるアクションと表示されるダイアログボックスはInstallUISequenceテーブル中に定義される。似たようなテーブルとしてAdminUISequenceテーブルがあり、ここでは管理インストールで実行されるアクションと表示されるダイアログボックスが定義される。

**実行シーケンス**
典型的なMSIインストールウィザードでは、完了またはインストールボタンを押下すると実行シーケンスが実行され、コンポーネントの実際のインストールが行われる。実行フェーズではシステムに変更が加えられる一方、ユーザインタフェースは一切表示されない。
実行フェーズは次の2つのステップに分けて実行される。:
即時実行モード: このステップでは、Windows Installerは、ユーザもしくはアプリケーションからプロダクトのインストール・アンインストールに必要な命令を受け取る。リクエストが発行されるとアクション (action) のシーケンス (sequence) が実行され、データベース内の情報から、遅延実行モードで行うべき処理を記述したスクリプトが内部的に構築される。
遅延実行モード: このステップでは、即時実行モードで構築されたスクリプトが実行される。スクリプトはWindows Installerサービスが動作しているアカウント（LocalSystemアカウント）で実行される。これは、セットアップ処理を起動する方法が多岐にわたるためである。たとえば、非特権ユーザーがインストールを行う場合は特権ユーザへの昇格が必要になる（なお、特権ユーザへ昇格してインストールを行うには、パッケージがLocal administratorによってデプロイされているか、システム管理者がグループポリシーでパッケージをアドバタイズしている必要がある）。
通常のインストールで実行されるアクションのシーケンスはInstallExecuteSequenceテーブルに格納される。同様に、管理インストールで実行されるアクションはAdminExecuteSequenceテーブルに、アドバタイズされたパッケージのインストールで実行されるアクションはAdvtExecuteSequenceテーブルに格納される。

**ロールバック**
遅延実行シーケンススクリプトの実行中にエラーが発生した場合や、ユーザーの操作によって処理がキャンセルされた場合、その時点までに行われたアクションはロールバックされ、システムは元の状態に復元される。Windows Installerの標準アクションは実行時に自動的にロールバックスクリプトへの書き込みを行っており、ロールバック処理ではそのスクリプトが実行される。パッケージの作者がシステムに変更を加えるカスタムアクションを作成する場合は、対応するロールバックアクションも作成する必要がある。アンインストール用アクションにも同様にロールバック用のアクションが必要になる。このメカニズムによって、アンインストールが失敗した場合には再インストールが行われるという少し奇妙な処理が行われる。

**その他の機能**

**アドバタイズ**
Windows Installerでは、製品をアドバタイズ (advertise) することもできる。製品がアドバタイズされると、ユーザーからは製品がインストールされたように見えるが、実際のインストールは製品が初めて起動されるとき（スタートメニューからの起動、関連付けられたファイルを開く、アドバタイズにより設定されたCOMクラスを呼び出す等）に実行される。パッケージのアドバタイズを行うには、グループポリシーまたはその他のデプロイメント機構を使用するか、msiexec.exeを/jm（すべてのユーザに対してアドバタイズ）または/ju（現在のユーザに対してアドバタイズ）オプション付きで実行する。

**オンデマンドでのインストール**
アドバタイズと同様に、オンデマンドでのインストールに指定された機能はユーザーが使用しようとした時点で初めてインストールされる。

**管理インストール**
管理インストールでは非圧縮の状態の製品のイメージが作成される。この機能は、主にアプリケーションをネットワークドライブからインストールまたは実行する際に用いられる。管理用インストールでは、通常のインストールとは異なり、ショートカットの作成・COMサーバの登録・「プログラムの追加と削除」への追加は行われない。管理用インストールは、展開したインストール用ソースから機能を実行する場合にしばしば使用される。
管理インストールはWindows Installerのパッチを作成する場合にも使用される。これは、バイナリファイルの差分を得るために、古いバージョンと新しいバージョンの展開済みイメージが必要になるためである。管理インストールを行うには、msiexec.exeを/aオプション付きで実行する。

**その他**
Windows Installerでは、アプリケーションをネットワーク共有から直接実行することができる。ローカルへのコピーは不要であり (run from source)、以下の処理が可能である。- 壊れたインストールの修復。破壊・削除されたファイルやレジストリエントリをリストアする。- コンポーネント識別子からのパスの解決。アプリケーションへのファイルパスのハードコーディングを不要にする。- ネイティブでサポートされたパッチ（.mspファイル）と、transformsまたは.mstファイルを使用したパッケージのデータベースの操作によるパッケージのカスタマイズ。
また、ブラックボックス部分が非常に少ない点も、他のWindows用インストーラフレームワークと比較して特筆すべき違いである。すべてのAPIとコマンドラインオプションのドキュメントが提供されている。パッケージの内容は、無償のツールや自作のプログラムから自由に閲覧・編集できる。この点は、プロプライエタリであり、弱い暗号であるとはいえ暗号化されたパッケージを使用するInstallShieldとは対照的である。ファイルアーカイブのフォーマットはCABであり、ドキュメントも豊富に提供されている。

**Windows Vista**
Windows Vistaに同梱されているWindows Installer 4.0には、UACと連携するための機能が盛り込まれている。MSIパッケージを管理者権限が不要であるとマークすれば、ユーザは管理者資格情報のプロンプトを表示せずにパッケージをインストールできる。Windows Installerと再起動マネージャの連動も可能である。アプリケーションやシステムコンポーネントのインストールおよび更新を「フル」ユーザインタフェースモードで行うときは、影響を受けるアプリケーションのうちシャットダウンできるもののリストが表示され、ファイルが更新された後に再起動することができる。サイレントモードでは、インストーラのアクションによってアプリケーションは自動的に再起動される。システムサービスやトレイアプリケーションも同様に再起動が可能である。

**診断ログ**
Windows Installerは強力な診断用ツールとして詳細なロギング機能をサポートしている。ロギングは次の方法で有効化できる。- コマンドライン
 MSIパッケージをコマンドラインからインストールする場合、/Lオプションを指定するとロギングが有効になる。例えば、以下のコマンドはPackage.msiをインストールし、詳細なログをc:\Package.logに出力する。
msiexec /i Package.msi /l*v c:\Package.log- Windows レジストリ
 レジストリに次の値を設定すると詳細なロギングが有効になる。
キー: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
名前: Logging
種類: REG_SZ
データ: voicewarmup
ログはMSI###.log（"###" はランダムに決定される一意な識別子）という名前でユーザーのTempディレクトリに保存される（'temp' ディレクトリはユーザーごとに別々で、環境変数%temp%で表される）。- グループポリシー
 以下のグループポリシーの設定で複数のシステムにおけるロギングを管理することができる。
コンピュータの構成 -> 管理テンプレート -> Windowsコンポーネント -> Windows インストーラ -> ロギング- WindowsインストーラAPI
 自作のプログラムからMSIパッケージのインストールを行う場合、MsiEnableLog関数でログファイルの作成とロギングレベルの設定が行える。設定は呼び出し側のプロセスが生きている間のみ有効である。- MsiLoggingプロパティ
 Windowsインストーラ4.0ではMsiLoggingプロパティが導入された。これはフラグのリストで、どの情報をログに残すかを表す。フラグはmsiexec.exeの/Lオプションで指定したり、ロギングポリシーの設定で使用するものと同様である。MsiLoggingを使用すると、MsiLogFileLocationプロパティにログファイルの場所がセットされる。
冗長なログはWindowsインストーラの問題を診断するには便利だが、とても長く、訓練なしに読むのは難しい。ログから問題の個所を簡単に見つけ出すには、テキストエディタ（たとえば メモ帳）でログファイルを開き、"Return Value 3"という文字列を検索する。この文字列は通常、致命的なエラーが発生した場所の近くで出力される。また、Windows Installer SDKでWiLogUtlというツールが提供されている。これはWindowsインストーラのログファイルをパースし注釈を付けてくれる。
ログファイルにデバッグ情報を出力する場合は、コマンドラインか、またはレジストリのLoggingの値にxを指定する。例えば、以下のコマンドはPackage.msiをインストールし、デバッグ情報を含む詳細なログをc:\Package.logに出力する。
msiexec /i Package.msi /l*vx c:\Package.log

**ICE による検証**
マイクロソフトは、MSIデータベースの潜在的な問題を検出するInternal Consistency Evaluators (ICE) を提供している。ICEのルールはCUBファイルにまとめられている。これは必要最低限の内容のみを含むMSIファイルで、ターゲットのMSIデータベースを検証し、警告またはエラーを出力するカスタムアクションを含んでいる。ICEによる検証はPlatform SDKのツールであるOrcaとmsival2から行える。また、各種オーサリング環境に付属の検証用ツールからも行える。
ICE のルールは、例えば次のようなものである。- ICE09: システムフォルダに格納されるすべてのコンポーネントがPermanentとしてマークされているか検証する。- ICE24: 製品コード、製品バージョン、製品の言語のフォーマットが適切か検証する。- ICE33: Registryテーブルに、他のテーブル（Class, Extension, Verbなど）に格納すべきデータが含まれていないか検証する。
リリースプロセスにおいて、ICEの警告とエラーを処置することは重要なステップである。
インストール処理では、インストールに先立ってMSIパッケージのコピーがテンポラリフォルダに作成される。これは、パッケージがローカルにある場合でも行われる。インストールパッケージがローカライズされている場合、InstallShield製品はMSIパッケージの追加のコピーをテンポラリフォルダに作成する。
パッケージビルダが「オンデマンドでのインストール」もしくは「修復」機能を使用するよう設定した場合、パッケージ全体（ローカライゼーションメッセージは除く）とスタブのMSIパッケージが%WinDir%\Installerディレクトリにコピーされる。
グループポリシーによって、インストールの全操作をログに取るよう設定できるが、このログは Windows のテンポラリディレクトリに作成される。このログファイルは、大きなパッケージに対して最も冗長なログを取得した場合、数十メガバイトにもなる。ログファイルは診断には便利だが、ユーザがインストーラに関係した操作（インストール、アンインストール、変更、修復、パッチ）を頻繁に行う場合、ログによるスペースの消費は馬鹿にならない。ロギングポリシーはデフォルトでは無効になっているが、顧客によるインストールプログラムのデバッグの補助のために、セットアップのブートストラッププログラムがロギングを有効にしている場合もある。
MSIインストールファイルのサイズは同等の.zipや.rar（または自己解凍形式の .exe）ファイルよりも大きくなる傾向にある。これは、強力な圧縮アルゴリズムを使用していないためである。date=2010年5月

**バージョン**

**再配布**
Windows Installerは再配布が可能である。以下のサイトからダウンロードできる。- 3.0 -  Windows Installer 3.0 Redistributable- 3.1 -  Windows Installer 3.1 Redistributable (v2)- 4.5 -  Windows Installer 4.5 Redistributable - 日本語

**脚注**

**関連項目**
WiXはマイクロソフトのオープンソースツールで、XMLファイルからMSIファイルをビルドするのに使用される。
*Scriptlogic
*Windows SDK
*:Category:システムソフトウェア

**外部リンク**
 Windows インストーラ テクノロジの概要- Windows Installer 4.0 for Windows Vista and Windows Server 2008
*MSDNの Windows Installer Team Blog - WiX- InstallSite.org