Windowsインストーラ（msiexec.exe旧称Microsoftインストーラ、[3] コードネーム Darwin）[4] [5]は、ソフトウェアのインストール、メンテナンス、および削除に用いられるMicrosoft Windowsのソフトウェアコンポーネントおよびアプリケーションプログラミングインターフェース（API）である。インストール情報、およびオプションでファイル自体がインストールパッケージにパッケージ化されている。インストールパッケージは、 COM構造化ストレージとして構造化された緩やかなリレーショナルデータベースであり、デフォルトのファイル名拡張子から一般に「MSIファイル」と呼ばれる。ファイル拡張子が のパッケージにはWindowsインストーラの「変換スクリプト」が含まれ、拡張子が のパッケージには「マージモジュール」が含まれ、ファイル拡張子は「パッチ作成プロパティ」に使用される。[6] Windowsインストーラは、その前身であるセットアップAPIから大幅に変更されている。新機能には、 GUIフレームワークとアンインストールシーケンスの自動生成が含まれる。Windowsインストーラは、旧バージョンのInstallShieldやNSISなどのスタンドアロン実行可能インストーラフレームワークの代替として位置付けられている。
mstmsmpcp
Microsoft Store （当時はWindows Store）の導入以前、Microsoftはサードパーティに対し、Windowsインストーラーをインストールフレームワークの基盤として利用することを推奨していました。これは、他のインストーラーと正しく同期し、インストールされた製品の内部データベースの一貫性を保つためです。ロールバックやバージョン管理といった重要な機能は、信頼性の高い動作を実現するために、一貫性のある内部データベースに依存しています。さらに、Windowsインストーラーは、権限のないユーザーに代わってプロキシ経由でソフトウェアのインストールを実行することで、 最小権限の原則を促進します。
パッケージは、1つまたは複数の完全な製品のインストールを記述し、 GUIDによって普遍的に識別されます。製品はコンポーネントで構成され、コンポーネントは機能ごとにグループ化されます。Windowsインストーラーは製品間の依存関係を処理しません。
インストールされ、動作する単一のプログラム（またはプログラムセット）は、製品と呼ばれます。製品は、世界中で信頼できるIDを提供する一意のGUID（ProductCodeプロパティ）によって識別されます。GUIDとバージョン番号（ProductVersionプロパティ）を組み合わせることで、製品のファイルとレジストリキーのリリース管理が可能になります。
パッケージには、パッケージロジックと、実行時のパッケージの動作に関連するその他のメタデータが含まれます。例えば、製品内のEXEファイルを変更すると、リリース管理のためにProductCodeまたはProductVersionを変更する必要がある場合があります。ただし、起動条件を変更または追加するだけの場合（製品は以前のバージョンと全く同じまま）、MSIファイル自体のリリース管理のためにPackageCodeを変更する必要があります。
機能とは、コンポーネントの階層的なグループです。機能には、任意の数のコンポーネントと他のサブ機能を含めることができます。小規模なパッケージでは、単一の機能のみで構成されることもあります。より複雑なインストーラーでは、「カスタムセットアップ」ダイアログボックスが表示され、ユーザーはそこからインストールまたは削除する機能を選択できます。
パッケージ作成者は製品の機能を定義します。例えば、ワードプロセッサでは、プログラムのコアファイルを1つの機能に、ヘルプファイル、オプションのスペルチェッカー、文房具モジュールを追加機能に配置する場合があります。
コンポーネントは製品の基本単位です。Windowsインストーラーは各コンポーネントを1つの単位として扱います。インストーラーはコンポーネントの一部だけをインストールすることはできません。[7]コンポーネントには、プログラムファイル、フォルダ、COMコンポーネント、レジストリキー、ショートカットなどが含まれます。ユーザーはコンポーネントを直接操作することはありません。
コンポーネントは GUID によってグローバルに識別されるため、理想的にはマージ モジュールを使用することで、同じパッケージまたは複数のパッケージの複数の機能間で同じコンポーネントを共有できます。
キーパスとは、パッケージ作成者が特定のコンポーネントにとって重要であると指定したファイル、レジストリ キー、またはODBCデータ ソースのことです。 ファイルは最も一般的なキー パスの種類であるため、一般的にキー ファイルという用語が使用されます。 コンポーネントには最大で 1 つのキー パスを含めることができます。コンポーネントに明示的なキー パスがない場合、コンポーネントのインストール先フォルダーがキー パスとして使用されます。 MSI ベースのプログラムを起動すると、Windows インストーラーによってキー パスの存在が確認されます。 現在のシステム状態と MSI パッケージで指定された値の間に不一致がある場合 (キー ファイルが見つからないなど)、関連する機能が再インストールされます。 このプロセスは、自己修復または自己修復と呼ばれます。 2 つのコンポーネントが同じキー パスを使用することはできません。
新しいアプリケーションのインストーラーパッケージを作成するのは簡単ではありません。どのファイルをどこに、どのレジストリキーでインストールするかを指定する必要があります。標準以外の操作は、通常DLLで開発されるカスタムアクションを使用して実行できます。MSIパッケージの作成を支援する商用およびフリーウェア製品が多数あり、Visual Studio（VS 2010まではネイティブ対応、[8] 、新しいVSバージョンでは拡張機能付き[9]）、InstallShield、WiX、InnoSetup、InstallSimple、Advanced Installerなどがあります。ユーザーインターフェイスと動作は、無人インストールなどのあまり一般的ではない状況で使用するために、程度の差はありますが構成できます。インストーラーパッケージの準備が整うと、開発者のローカルマシンから命令とファイルを読み取り、.msiファイルを作成することで「コンパイル」されます。
Windowsインストーラは、コンポーネントの登録とロールバックのサポートのオーバーヘッドにより、数万のレジストリキーと一時ファイルの生成を伴うことが多いため、InstallAware [ 10]などのネイティブコードインストールテクノロジよりも遅くなる可能性があります。
インストール開始時に表示されるユーザーインターフェース（ダイアログボックス）は、新しいインストーラを開発するセットアップエンジニアによって変更または構成できます。一連のダイアログボックスに配置できるボタン、テキストフィールド、ラベルといった言語は限られています。インストーラパッケージは、いわゆる「無人インストール」のために、UIなしで実行できる必要があります。
Microsoftは、MSIデータベースの潜在的な問題を検出するために使用できる内部整合性評価ツール（ICE）のセットを提供しています。[11] ICEルールはCUBファイルに統合されています。CUBファイルは、対象となるMSIデータベースの内容の検証警告やエラーをテストするカスタムアクションを含む、簡素化されたMSIファイルです。ICE検証は、プラットフォームSDKツールのOrcaおよびmsival2、または各種オーサリング環境に付属する検証ツールを使用して実行できます。
たとえば、ICE の規則の一部は次のとおりです。
ICE 検証の警告とエラーに対処することは、リリース プロセスにおける重要なステップです。