次の方法で共有

Windows インストーラーのベスト プラクティス

  • [アーティクル]

このセクションでは、アプリケーション開発者、セットアップ作成者、IT プロフェッショナル、インフラストラクチャ開発者が Windows インストーラーを使用するためのベスト プラクティスを得られるため、メイン Windows インストーラー SDK ドキュメントにリンクされているヒントのリストを示します。

Windows インストーラーのバージョンを更新します。

  • Windows Server 2008 R2 と Windows 7 に Windows インストーラー 5.0 を使用します。 これは、オペレーティング システムと一緒に提供される Windows インストーラーのバージョンです。
  • Windows Server 2008、Windows Server 2003 with Service Pack 1 (SP1)、Windows Vista with Service Pack 1 (SP1)、Windows XP with Service Pack 2 (SP2) に Windows インストーラー 4.5 を使用します。 最新の Windows インストーラー バージョンの取得に関する詳細については、「Windows インストーラー再頒布可能パッケージ」を参照してください。
  • Windows 2000 with Service Pack 3 (SP3) に Windows インストーラー 3.1 を使用します。 Windows インストーラー バージョン 3.1 には、アプリケーション サービスとパッチ適用を容易にする機能があります。
  • 多くの重要な機能はバージョン 3.0 で導入され、「Windows インストーラー バージョン 2.0 でサポートされない」セクションに記載されています。 Windows インストーラー 2.0 用に作成されたインストール パッケージと更新プログラムは、Windows インストーラー 3.0 以降を使用してインストールできます。 Windows インストーラー 3.0 で使用される新しいテーブルを含むパッチ パッケージは、以前のバージョンの Windows インストーラーを使用して適用できますが、Windows インストーラー 3.0 のパッチ適用機能は使用できません。 以前のバージョンの Windows インストーラーでは適用できない Windows インストーラー 3.0 を明示的に必要とするパッチを作成することもできます。 ユーザーがインストーラーのバージョンを更新できない場合、アプリケーションまたは更新プログラムが Windows インストーラーの今後の更新プログラムと互換性があることを確認してください。
  • 以前のバージョンの Windows インストーラーでサポートされていない Windows インストーラー機能のリストについては、「Windows インストーラーの最新情報」を参照してください。

Windows ロゴの認定要件を満たします。

  • ロゴ プログラムにアプリケーションを提出しなくても、ロゴ認定ガイドラインに従うと、Windows インストーラー パッケージを向上できるようにします。 ロゴ要件の概要と特定のロゴ認定プログラムへのリンクについては、「Windows インストーラーとロゴの要件」を参照してください。

ローカライズ用にパッケージを準備します。

Windows インストーラーの開発ツールとドキュメントを更新します。

  • Windows インストーラー開発ツールは再頒布可能ではなく、Microsoft から利用可能なこれらのツールのバージョンのみを使用する必要があります。 Microsoft Windows ソフトウェア開発キット (Windows SDK) の「Windows インストーラー開発者向けの Windows SDK コンポーネント」で利用できます。
  • いくつかの独立系ソフトウェア ベンダーは、Windows インストーラー パッケージを作成または変更するツールを提供しています。 これらのツールは、Windows インストーラー SDK で提供されているツールよりも使用しやすいパッケージ作成環境を提供できます。 これらのツールの詳細については、「Windows インストーラー情報の他のソース」で説明されている情報リソースを参照してください。
  • テキスト ファイルでパッケージをビルドする機能は、一部の開発者にとってはより直感的な場合があります。 「Sourceforge.net」で利用可能な Windows インストーラー XML (WiX) ツールセットは、XML ソース コードで Windows インストール パッケージをビルドします。
  • Windows インストーラーSDK のドキュメントは、最も頻繁に更新されます。
  • Windows Vista 以降の Windows インストーラー開発者向け Windows SDK コンポーネントで利用可能なMsizap.exe (バージョン 3.1.4000.2726 以降) の最新バージョンを使用します。 Msizap.exe の小規模なバージョンは、ユーザーのコンピューター上の他のアプリケーションに適用されたすべての更新プログラムに関する情報を削除できます。 この情報を削除した場合、追加の更新プログラムを受けるには、これらの他のアプリケーションを削除して再インストールする必要がある場合があります。
  • Orca.exe データベース テーブル エディターは、Windows インストーラー パッケージとマージ モジュールを作成と編集するデータベース テーブル エディターです。 基本的な GUI インターフェイスを備えていますが、Windows インストーラー データベースの高度な編集をサポートしています。 別のアプリケーションをプライマリ開発ツールとして使用しても、パッケージのトラブルシューティングやテストを行うときに Orca.exe の使用が便利です。
  • ブログ、テクニカル チャット、ニュースグループ、技術記事、Web サイトで確認できる現在の Windows インストーラー情報については、「Windows インストーラー情報の他のソース」を参照してください。

レガシ セットアップ アプリケーションを再パッケージ化する場合、適切な再パッケージ化のプラクティスに従ってください。

多くのアプリケーション ベンダーは、自社製品のインストールにネイティブ Windows インストーラー パッケージを提供します。 既存のレガシ セットアップ アプリケーションを Windows インストーラー パッケージに変換するソフトウェアは、再パッケージ化ツールと呼ばれます。 既存のセットアップ アプリケーションを再パッケージ化することは、最適な開発手法ではありません。 Windows インストーラーの機能を活用するように最初から設計されたアプリケーションは、ユーザーが簡単にインストールしてサービス提供できます。 再パッケージ化ソフトウェアを使用する場合、次のプラクティスはより優れた Windows インストーラー パッケージを作成できるようにします。

  • 再パッケージ化ツールは、インストールの前後にステージング システムを撮影することにより、レガシ インストールを Windows インストーラー パッケージに変換します。 キャプチャ プロセス中に発生するレジストリ変更、ファイル変更、システム設定は、インストールに含まれます。 インストールの再パッケージ化に使用するコンピューターのハードウェアとソフトウェアは、可能な限り、対象のユーザーのシステムに近い内容に構成します。 異なるハードウェア構成ごとに個別のパッケージを作成します。 クリーン ステージング コンピューターを使用して再パッケージ化します。 不要なアプリケーションを削除します。 不要なプロセスをすべて停止します。 重要でないシステム サービスをすべて閉じます。
  • 作業を開始する前に、必ず元のインストールのコピーを作成してください。 常にコピーで作業をします。 パッケージのビルドが完了する前に、再パッケージ化を停止しないでください。 再パッケージ化によってパッケージが破損しても、元のパッケージが残ります。
  • Microsoft ソフトウェアの更新プログラムを Windows インストーラー パッケージに再パッケージ化しないでください。 Microsoft は、自動的にインストールを実行する自己解凍ファイルとして、サービス パックなどのソフトウェア更新プログラムをリリースします。 これらの更新プログラムは、保護された Windows リソースを置き換えるために Windows インストーラーとは異なるインストーラーを使用し、Windows インストーラー パッケージに変換することはできません。 Windows サービス パックを展開する方法の詳細については、「Microsoft TechNet」の Service Pack の展開ガイドを参照してください。
  • 再パッケージ化ツールを使用し、Windows インストーラー パッケージを新しいパッケージに変換しないでください。 Windows インストーラーは、システムとアプリケーション リソースに構成情報を追加します。 再パッケージ化ツールがインストール前後にシステムを比較すると、再パッケージ化によって構成情報がアプリケーションの一部として誤って解釈されます。 通常、再パッケージ化されたアプリケーションを損傷します。 代わりに、カスタマイズ変換を使用して既存の Windows インストーラー パッケージを変更するか、新しいパッケージを作成します。 Msitran.exe ツールを使用してカスタマイズ変換を作成できます。
  • 再パッケージ化ツールを使用し、複数の Windows インストーラー パッケージを 1 つのパッケージに統合しないでください。 代わりに、Msistuff.exe ツールを使用し、パッケージを 1 つずつインストールするように Setup.exe ブートストラップ実行可能ファイルを構成できます。
  • 顧客が簡単にカスタマイズできるように、Windows インストーラー パッケージを作成します。 インストール時に Windows インストーラーが使用するグローバル変数は、パブリックプロパティまたはカスタマイズ変換を使用して設定できます。 これらのプロパティの使用に関するドキュメント、ならびにカスタマイズ可能なすべての値の実用的な既定値を指定します。 プロパティの取得と設定に関する詳細については、「プロパティを使用する」を参照してください。 カスタマイズ変換の例については、「カスタマイズ変換の例」を参照してください。

保護されたリソースを置き換えないでください。

Windows インストーラー パッケージは、インストールまたは更新中に保護されたリソースを置き換えてはなりません。 Windows が重要なシステム ファイル、フォルダー、レジストリ キーの置き換えを防止するため、Windows インストーラーはこれらのリソースを削除または置き換えることはありません。 これらのリソースを保護すると、アプリケーションとオペレーティング システムの障害を防ぐことができます。

  • Windows Server 2008 または Windows Vista で実行している場合、Windows インストーラーは、Windows リソース保護 (WRP) で保護されているファイルまたはレジストリ キーのインストールをスキップし、インストーラはログ ファイルに警告を入力してエラーなしで残りのインストールを続行します。 詳細については、「Windows インストーラーと Windows リソース保護を使用する」を参照してください。
  • WRP は Windows ファイル保護 (WFP) の新しい名称です。 WRP はレジストリ キーとフォルダーの他に、重要なシステム ファイルも保護します。 Windows Server 2003、Windows XP、Windows 2000 では、Windows インストーラーが WFP で保護されたファイルを検出すると、インストーラーは WFP にファイルのインストールを要求します。 詳細については、「Windows インストーラーと Windows リソース保護を使用する」を参照してください。

クリティカルでないリソースに依存しないでください。

次の理由により、インストールまたは更新プログラムがクリティカルでないリソースのインストールに依存してはなりません。

  • カスタム アクションは、ユーザーがインストールではなく、公開する機能に属するコンポーネントに依存している場合、失敗する可能性があります。
  • InstallFinalize アクションの前にシーケンスを決定したカスタム アクションは、インストールされるアセンブリを含むコンポーネントに依存している場合、失敗する可能性があります。 Windows インストーラーは、InstallFinalize アクションが完了するまで、アセンブリをグローバル アセンブリ キャッシュ (GAC) にコミットしません。

API を使用して Windows インストーラーの構成情報を取得します。

アプリケーションまたは更新プログラムのインストールは、コンピューターに保存されている Windows インストーラー構成情報への直接アクセスに依存してはなりません。 代わりに、Windows インストーラー アプリケーション プログラミング インターフェイスを使用して構成情報を取得します。 構成情報の場所と形式は、Windows インストーラー サービスによって管理され、変更される可能性があります。

コンポーネントを中心にアプリケーションのインストールを整理します。

Windows インストーラー サービスは、“コンポーネントと呼ばれるリソースのコレクションをインストールまたは削除します。 コンポーネントは一般的に共有されるため、インストール パッケージの作成者は、機能またはアプリケーションのコンポーネントを指定するときに規則に従う必要があります。

  • アプリケーションをコンポーネントに整理するときは、コンポーネント ルールに従い、他のアプリケーションを破損することなく、新しいコンポーネントまたは新しいバージョンのコンポーネントをインストールと削除できるようにします。 「インストーラー コンポーネントを定義する」に記載されている手順に従います。
  • インストーラは、コンポーネント テーブルで指定されたコンポーネント ID GUID ごとに対象となるコンポーネントをすべて追跡します。 コンポーネント ID GUID が正確であることは、Windows インストーラーの参照カウント メカニズムの操作に不可欠です。 「コンポーネント コードの変更」のガイドラインに従ってください。
  • パッケージがコンポーネントのルールを破る必要がある場合、考えられる結果に注意し、ユーザーのシステムのコンポーネントを破損する可能性がある場合、インストールがこれらのコンポーネントをインストールしないようにしてください。 詳細については、「コンポーネント ルールを破った場合に発生すること」を参照してください。
  • 既存のファイルの置き換えする場合、Windows インストーラーがファイルのバージョン管理ルールをどのように適用するかに注意してください。 Windows インストーラーは、コンポーネントのすべてのファイルをインストールする前に、コンポーネントのキー ファイルが既にインストールされているかどうかを最初に判断します。 インストーラがターゲットの場所にインストールされているコンポーネントのキー ファイルと同じ名前のファイルを見つけた場合、2 つのキー ファイルのバージョン、日付、言語を比較し、ファイルのバージョン管理ルールを使用して、パッケージが提供するコンポーネントをインストールするかどうかを判断します。 インストーラがキー ファイルに基づいてコンポーネントを置き換える必要があると判断した場合、インストールされている各ファイルにファイルのバージョン管理ルールを使用し、ファイルを置き換えるかどうかを判断します。

大きな Windows インストーラー パッケージのサイズを縮小します。

非常に大きな Windows パッケージはシステム リソースを使用し、ユーザーがインストールするのが難しい場合があります。 次の方法により、非常に大きな Windows インストーラー パッケージのサイズを減らすことをお勧めします。

  • インストール内のファイルを圧縮し、キャビネット (.cab) ファイルに保存します。 インストーラは、.cab ファイルを別の外部ファイルとして保存するか、MSI パッケージ自体のデータ ストリームとして保存できるようにします。 詳細については、「キャビネットと圧縮ソースを使用する」を参照してください。
  • 「.msi ファイルのサイズを縮小する」で説明されているいずれかのオプションを使用し、.msi ファイル内の無駄な記憶領域を削除します。
  • Windows インストーラー パッケージに 32767 を超えるファイルが含まれている場合、データベースのスキーマを変更する必要があります。 詳細については、「大きなパッケージの作成」を参照してください。

カスタム アクションを使用する場合、適切なカスタム アクションのプラクティスに従ってください。

Windows インストーラーには、アプリケーションのインストールとメンテナンス用にビルトインの標準アクションが多数あります。 開発者は、独自のカスタム アクションを作成せず、実用的な限り標準アクションに依存する必要があります。 ただし、インストール パッケージの開発者がカスタム アクションの記述が必要だと判断する場合があります。

アセンブリを使用する場合、適切なアセンブリ プラクティスに従ってください

パッケージでソフトウェア アセンブリが使用されている場合、「パッケージにアセンブリの追加」、「アセンブリの更新」、「アセンブリのインストールと削除」に関するガイドラインに従ってください。

同時インストールを出荷しないでください。

同時インストール (入れ子になったインストールとも呼ばれる) は、現在実行中のインストール時に別の Windows インストーラー パッケージをインストールします。 顧客が管理することが難しいため、同時インストールはお勧めしません。 パッチ適用とアップグレードは、同時インストールと機能しない場合があります。 同時インストールの代替の推奨事項として、代わりにセットアップ アプリケーションと外部 UI ハンドラーを使用し、複数の Windows インストーラー パッケージを順番にインストールできます。

外部 UI ハンドラーの使用に関する詳細については、「MsiSetExternalUI を使用したインストールの監視」を参照してください。 レコードベースの外部ハンドラーの使用に関する詳細については、「MsiSetExternalUIRecord を使用したインストールの監視」を参照してください。

一般ユーザー向けを対象としないアプリケーションをインストールするため、同時インストールは管理された企業環境で使用されるときがあります。 同時インストールを使用する場合、次のガイドラインに従ってください。

  • 出荷製品のインストールや更新に同時インストールを使用しないでください。
  • 同時インストールにはコンポーネントを共有しないでください。
  • 管理インストールには、同時インストールを含めてはなりません。
  • 統合 ProgressBars は、同時インストールと使用してはなりません。
  • 公開されるリソースは、同時インストールでインストールしてはなりません。
  • アプリケーションの同時インストールを実行するパッケージは、親製品をアンインストールするときに同時実行のアプリケーションもアンインストールする必要があります。 入れ子になったインストールは、[コントロール パネル] の [プログラムの追加と削除] で親製品のコンテキストの下に存在します。

パッケージ名とパッケージ コードの一貫性を保ちます。

.msi ファイルはユーザーがパッケージを識別できる任意の名前を指定できますが、製品コードも変更せずに名前を変更してはなりません。

  • .msi ファイルにユーザーフレンドリな名前を付けて、ユーザーが Windows インストーラー パッケージの内容を識別できるようにします。
  • 製品コードはアプリケーションのプリンシパル ID であり、アプリケーションに包括的な更新があるときに変更する必要があります。 詳細については、「ProductCode」と「製品コードを変更する」を参照してください。 アプリケーションの .msi ファイルの名前を変更することは包括的な変更と見なされ、一貫性を維持するために製品コードに対応する変更を行う必要があります。
  • パッケージ コードは、インストーラが特定のインストールの正しいパッケージを検索して検証するために使用するプライマリ識別子です。 そっくりでない 2 つの .msi ファイルに同じパッケージ コードを持ってはなりません。 パッケージ コードを変更せずにパッケージが変更されたら、インストーラーがまだ両方ともアクセス可能な場合、インストーラは新しいパッケージを使用できません。 パッケージ コードは、「概要情報ストリーム」の「リビジョン番号の概要」プロパティに格納されます。
  • 製品コードとパッケージ コード GUID の文字はすべて大文字である必要があることに注意してください。

SelfReg テーブルと TypeLib テーブルは使用しないでください。

  • インストール パッケージの作成者には、自己登録と SelfReg テーブルを使用しないことを強くお勧めします。 代わりに、レジストリ テーブル グループで 1 つ以上のテーブルを作成してモジュールを登録する必要があります。 自己登録ルーチンはクリティカルな構成情報を非表示にする傾向があるため、Windows インストーラーの多くの利点は自己登録によって失われます。 自己登録を回避する理由のリストについては、「SelfReg テーブル」を参照してください。
  • インストール パッケージの作成者には、TypeLib テーブルを使用しないことを強くお勧めします。 TypeLib テーブルを使用する代わりに、レジストリテーブルを使用してタイプ ライブラリを登録します。 TypeLib テーブルを使用したインストールが失敗してロールバックする必要がある場合、ロールバック前と同じ状態にコンピューターを復元できないことがあります。

ユーザー インターフェイスなしでインストールするオプションを指定します。

管理者は多くの場合、ユーザーの操作を必要とせずに、企業内でアプリケーションを展開することを好みます。 アプリケーションが、None のユーザー インターフェイス レベルでインストールされるオプションを提供できるようにすることをお勧めします。

  • 構成の詳細については、「パブリック プロパティ」を使用してください。 管理者はこの情報をコマンド ラインで提供できます。
  • インストールが、ユーザーがダイアログ ボックスを操作して収集した情報に依存することを必須条件にしないでください。 この情報はサイレント インストール中に利用できません。
  • サイレント インストール中にユーザーのコンピューターを自動的に再起動しないでください。
  • 管理者は "/q" のコマンド ライン オプションを使用し、インストール時にユーザー インターフェイス レベルを設定できます。 ユーザー インターフェイス レベルは、「MsiSetInternalUI」を呼び出してプログラムで設定することもできます。

AlwaysInstallElevated ポリシーは使用しないでください。

AlwaysInstallElevated ポリシーが設定されていない場合、管理者によって配布されないアプリケーションはユーザーの特権を使用してインストールされ、管理対象アプリのみが昇格された特権を取得します。 このポリシーを設定すると、Windows インストーラーがシステムにアプリケーションをインストールするとき、システムのアクセス許可を使用するように指示します。 このポリシーを設定すると、管理者以外のユーザーが昇格された特権でインストールを実行し、コンピューターのセキュリティで保護された場所にアクセスできるため、このメソッドはコンピューターをセキュリティ リスクにさらす可能性があります。 管理者以外のユーザーが昇格された特権でパッケージをインストールしたり、ユーザーごとの管理対象アプリのパッチ適用したりするとき、AlwaysInstallElevated ポリシーとは別の方法を使用することをお勧めします。

DisableMedia ポリシーを有効にし、不正なインストールを制限します。

DisableMedia ポリシーは、アプリケーションの不正なインストールを防ぐことができます。 このポリシーを有効にすると、1 つの製品のメンテナンス インストールを実行しているユーザーと管理者は、[参照] ダイアログを使用し、他のインストール可能な製品のソースであるメディア ソース (CD-ROM など) を参照できなくなります。 インストールが昇格された特権で行われたかどうかを問わず、他の製品の参照はできなくなります。 ユーザーが正しくラベル付けされたメディア ソースを持っている場合、ユーザーはメディアから製品を再インストールできます。

元のパッケージ ソース ファイルをセキュリティで保護し、ユーザーが利用できるようにします。

状況によっては、アプリケーションのオンデマンドインストール、修復、更新を行うため、Windows インストーラー パッケージの元のソースが必要になる場合があります。 インストーラが利用可能なソースを見つけることができない場合、ユーザーはメディアを指定するか、必要なソースを含むネットワークの場所に移動するように求められます。 ユーザーに要求することなく、インストーラが必要なソースを利用できるようにすることをお勧めします。

  • デジタル署名と外部キャビネットファイルを使用し、インストーラが使用する元のソースが安全であることを確認します。 パブリックな場所に格納されている未圧縮のソース イメージは安全ではありません。
  • SOURCELIST プロパティにアプリケーションのインストール パッケージへのネットワークまたは URL ソース パスを記載した完全なリストを含めます。
  • ソース パスに分散ファイル システム (DFS) の共有を使用します。
  • Windows インストーラー API を使用し、Windows インストーラー アプリケーションとパッチのソース リスト情報の取得と変更をします。 詳細については、「インストール ソースの管理」を参照してください。
  • インストーラ オブジェクト、製品オブジェクト、パッチ オブジェクトのメソッドとプロパティを使用し、Windows インストーラー アプリケーションとパッチのソース リスト情報の取得と変更をします。
  • パッチが元のソースへのアクセスを必要とする可能性を最小限に抑えるには、「パッチが元のソースへのアクセスを必要とすることを防止する」ポイントに記載されたポイントに従ってください。
  • システムの一時フォルダーではない場所にパッケージ ソース ファイルを格納します。 一時フォルダーに格納された Windows インストーラーのソース ファイルは、ユーザーが利用できなくなる可能性があります。

展開のトラブルシューティングを行うとき、ユーザーのコンピューターに詳細ログを有効にします。

Windows インストーラー ログ には、ユーザーのコンピューターで有効にできる詳細ログのオプションが含まれています。 詳細ログの情報は、Windows インストーラーのパッケージ展開のトラブルシューティングを行うときに役立ちます。

  • コマンド ライン オプション、MsiLogging プロパティ、ログ ポリシー、MsiEnableLog、EnableLogメソッドを使用して、ユーザーのコンピューターに詳細ログを有効にすることができます。
  • Windows インストーラーのログ ファイルを解釈するために非常に便利なリソースは「Wilogutl.exe」です。 このツールはログ ファイルの分析を支援し、ログ ファイルで見つかるエラーに対して推奨される解決策を表示します。
  • 詳細ログ オプションはトラブルシューティングの用途にのみ使用する必要があり、システムのパフォーマンスとディスク領域に悪影響を及ぼす可能性があるため、オンの状態に放置してはなりません。 [コントロール パネル] で [プログラムの追加と削除] ツールを使用するたびに、新しいファイルが作成されます。

アンインストールすると、ユーザーのコンピューターはクリーン状態になります。

アプリケーションの削除はインストールと同じくらい重要です。 Windows インストーラー パッケージをアンインストールすると、ユーザーのコンピューターに役に立たないパーツは残りません。

  • アンインストールを実行した後に、ユーザーのコンピューターから削除されるはずのファイルが残る場合、「孤立したファイルの削除」に記載されている 1 つ以上の理由により、インストーラはファイルを含むコンポーネントを削除していない可能性があります。
  • アプリケーションを登録する必要がある場合、アプリケーションをアンインストールするときにレジストリ情報を削除するパッケージを作成します。 詳細については、「コンポーネントのインストールまたは削除にレジストリ キーを追加または削除する」を参照してください。 アプリケーションが登録されていない場合、アプリケーションは [コントロール パネル] の [プログラムの追加と削除] 機能にリストされず、Windows インストーラーを使用して管理することはできません。
  • [コントロール パネル] の [プログラムの追加と削除] 機能からアプリケーションを非表示にしつつ、Windows インストーラーを使用してアプリケーションを引き続き管理できるようにするには、「アプリケーションを追加と削除し、レジストリに形跡を残さない方法」に記載されているガイドラインに従ってください。
  • カスタム アクションは、必要に応じてアンインストール時に実行するか、しないように条件設定する必要があります。 インストールとアンインストールには、異なるカスタム アクションの実行が必要な場合があります。
  • ユーザー固有のカスタマイズ情報は、コンピュータでテキスト ファイルに保存できます。 このカスタマイズのユーザーが現在ログオンしていない場合でも、アプリケーションをアンインストールするときにファイルを削除できるという利点があります。

ユーザーごととマシンごとのインストール展開の両方にパッケージをテストします。

インストール用のパッケージをマシンごとまたはユーザー ごとのインストール コンテキストで展開するかどうかについて、顧客が決定できるようにすることをお勧めします。

  • 開発プロセス中に、特定のユーザーのみか、コンピューターのすべてのユーザーがアプリケーションを利用できるようにすることを検討してください。
  • ユーザーごとのインストールコンテキストとマシンごとのインストール コンテキストの両方でパッケージが正しく動作することをテストします。
  • パッケージを簡単にカスタマイズ可能にし、顧客がユーザーごとにデプロイするか、マシンごとにデプロイするかについて決定できるようにします。

アプリケーションを出荷する前に、サービス戦略を計画してテストします。

初めてアプリケーションをデプロイする前に、アプリケーションをサービス提供する方法を決定する必要があります。

元のソースに対する更新プログラムの依存関係を減らします。

アプリケーションを更新するために元のソース ファイルが必要な場合、アプリケーションのサービス提供がさらに難しくなる可能性があります。 次のメソッドは、元のソースに対する更新プログラムの依存を減らすことに役立ちます。

サービス不可能なマージ モジュールを配布しないでください。

マージ モジュールの所有者とアプリケーションの所有者が異なる場合、アプリケーションはコンポーネントをインストールするためにマージ モジュールに依存しません。 両方の所有者がアプリケーションまたはモジュールを更新するために連携する必要があるため、アプリケーションのサービスを提供することが難しくなる可能性があります。 アプリケーションの所有者がマージ モジュールを使用したすべてのアプリケーションを知らない場合、更新プログラムが別のアプリケーションと互換性がない可能性のリスクを知らずに、マージ モジュールを更新できません。 マージ モジュールの所有者は、マージ モジュールを既にインストールしている Windows インストーラー パッケージを更新するための直接手段はありません。

  • 必要なコンポーネントを別の Windows インストーラー インストールとしてユーザーに提供することを検討してください。

管理インストールにパッチを適用しないでください。

ワークグループのメンバーがアプリケーションをインストールできるように、ネットワーク上にアプリケーションの元の Windows インストーラー パッケージの管理インストールを提供します。 この管理イメージのユーザーは、コンピューターにあるアプリケーションのローカル インスタンスに更新プログラムを適用する必要があります。 これにより、ユーザーは管理イメージと同期されます。 次の理由により、管理インストールに更新プログラムを適用することはお勧めしません。

  • ユーザーが更新プログラムを入手するために必要なダウンロードのサイズと待機時間は、パッチのダウンロードと比較して増加します。 更新された Windows インストーラー パッケージとソース ファイル全体をダウンロード、再キャッシュ、再インストールする必要があります。
  • アプリケーションを再キャッシュして再インストールするまで、ユーザーは更新された管理インストールからアプリケーションをオンデマンドインストールと修復することはできません。
  • 管理インストールにパッチを適用すると、パッケージからデジタル署名が削除されます。 管理者はパッケージを再署名する必要があります。 デジタル署名の使用の詳細については、「デジタル署名と Windows インストーラー」を参照してください。
  • 多くのバイナリ パッチは、アプリケーションの RTM イメージを対象としており、以前のファイル バージョンが必要です。 更新された管理インストールからインストールされたアプリケーションのローカル インスタンスは、他の更新プログラムと動作しない可能性があります。 多くのバイナリ パッチ アプリケーションが失敗する可能性があります。
  • 管理インストールにパッチを適用すると、ソース ファイルと .msi ファイルが更新されますが、更新プログラムに関する情報でネットワーク イメージにスタンプしません。 ユーザーは、管理インストールから受信した更新プログラムを特定できません。 ユーザー側で適用された更新プログラムを、管理イメージ側で既に適用されている更新プログラムとシーケンスを決定できなくなります。
  • 管理インストールに適用されたパッチは、アンインストール不能なパッチではありません。 ユーザーのコンピューターにキャッシュされたパッケージ コードが、管理インストールのパッケージ コードと異なることを防止できます。 ユーザーのコンピューターにキャッシュされたパッケージ コードが管理インストールのパッケージ コードと異なる場合、管理インストールからアプリケーションを再インストールし、クライアント コンピューターにパッチを適用します。
  • 管理イメージにパッチを適用して小さな更新プログラムを適用する場合、「管理イメージにパッチを適用して小さな更新プログラムを適用する」のトピックに記載されているガイドラインに従ってください。

昇格された特権で実行する更新プログラムを登録します。

Windows インストーラー 3.0 以降では、パッチに昇格された特権が登録された後、ユーザー管理コンテキストごとにインストールされているアプリケーションにパッチを適用できます。 バージョン 3.0 より前のバージョンの Windows インストーラーを使用し、ユーザーごとのマネージド コンテキストにインストールされているアプリケーションにパッチを適用することはできません。

MsiPatchSequence テーブルを使用してパッチにシーケンスを決定します。

パッケージに MsiPatchSequence テーブル を含め、パッチのシーケンス決定情報を追加します。 Windows インストーラー バージョン 3.0 以降では、インストーラーは複数のパッチをインストールするときに MsiPatchSequence テーブルを使用し、最適なパッチ アプリケーション シーケンスを特定できます。 パッチ ファミリの定義には、「Windows インストーラー バージョン 3.0 のパッチ シーケンス」のホワイト ペーパーで説明されているガイドラインを使用してください。

  • 実用的な場合、すべてのパッチを 1 つのパッチ ファミリに属するように指定します。 多くの場合、1 つのパッチ ファミリはパッチのシーケンスを決定するために十分な柔軟性を提供します。 複数のパッチ ファミリを使用すると、作成の複雑さが増えます。 パッチ ファミリにわかりやすい名前を割り当て、時間の経過と共に増加するそのパッチ ファミリにシーケンス値を割り当てます。 「複数のパッチ適用の例」に従い、パッチが発行された順序で適用します。
  • 「Patchwiz.dll」の「PatchSequence テーブル」を使用し、MsiPatchSequence テーブルで情報を生成します。 Windows インストーラー 3.0 でリリースされた PATCHWIZ.DLL のバージョンは、パッチ シーケンス情報を自動的に生成できます。 新しいパッチを追加する方法の詳細については、「パッチ シーケンス情報の生成」を参照してください。 パッチ シーケンスのシナリオの詳細については、「Windows インストーラー バージョン 3.0 のパッチ シーケンス」を参照してください。

インストール パッケージを徹底的にテストします。

Windows インストーラー パッケージの正しいインストール、修復、削除をテストします。 テスト プロセスを次のパーツに分割できます。

  • インストール テスト - アプリケーション機能のすべての可能な組み合わせでインストールをテストします。 管理 インストール、ロールバック インストール、オンデマンドインストールを含め、すべてのインストールの種類をテストします。 .msi ファイルのクリック、コマンド ライン オプション、コントロール パネルからインストールを含め、考えられるすべてのインストール方法を試してください。 ユーザーがすべての可能な特権コンテキストでパッケージをインストールできることをテストします。 すべての可能な方法でパッケージを展開した後に、インストールを試してください。 各テストで Windows インストーラー ログを有効にし、インストーラー ログとイベント ログで見つかるすべてのエラーを解決します。
  • ユーザー インターフェイス テスト - すべての可能なユーザー インターフェイス レベルをインストールした時にパッケージをテストします。 ユーザー インターフェイスがインストールされていないパッケージ、ならびにユーザー インターフェイスで提供されるすべての情報がインストールされたパッケージをテストします。 ユーザー インターフェイスのアクセシビリティ、ならびにさまざまな画面の解像度とフォント サイズでユーザー インターフェイスが期待どおりに機能することを確認します。
  • サービス提供と修復テスト - 小さな更新プログラム、マイナー アップグレード、メジャー アップグレードによって提供されるパッチ適用とアップグレードをパッケージが処理できることをテストします。 パッケージを展開する前に、各種類の試用版の更新プログラムを記述し、元のパッケージに適用してみてください。
  • アンインストール テスト - パッケージが削除されると、ユーザーのコンピューターに役に立たないパーツは残らず、パッケージに属する情報のみが削除されたことを確認します。 パッケージをアンインストールした後にテスト コンピューターを再起動し、一般的なシステム ツールとその他の標準アプリケーションの整合性を確認します。 すべての可能な特権コンテキストでユーザーがパッケージを削除できることをテストします。 すべてのメソッドをテストし、パッケージを削除、.msi ファイルをクリック、コマンド ライン オプションを試し、コントロール パネルからパッケージを削除してみてください。 各テストで Windows インストーラー ログを有効にし、インストーラー ログとイベント ログで見つかるすべてのエラーを解決します。
  • 製品の機能テスト - パッケージのインストール、修復、削除の後に、アプリケーションが期待どおりに機能することを確認します。

新しいまたは変更されたインストール パッケージを展開する前に、すべての検証エラーを修正します。

初めて新しいまたは変更された Windows インストーラー パッケージをインストールする前に、パッケージ検証を実行します。 検証機能は、Windows インストーラー データベースに作成エラーの有無をチェックします。 検証に合格しないパッケージをインストールすると、ユーザーのシステムが損傷する可能性があります。

  • Orca.exe または Msival2.exe を使用してパッケージを検証できます。 両方のツールとも Windows SDK で提供されています。 サードパーティ ベンダーは、ICE 検証システムを作成環境に組み込む場合もあります。
  • SDK に付属する .cub ファイルに含まれる内部一貫性エバリュエーター - ICE の標準セットを使用するか、ICE をビルドして .cub ファイルに追加することで検証をカスタマイズできます。
  • Evalcom2.dll を使用し、インストール パッケージとマージ モジュールに検証オートメーションを実装できます。

セキュリティで保護されたインストールを作成します。

インストール時にセキュリティで保護された環境を維持するには、パッケージを開発するときに次のガイドラインに従ってください。

HANDLE の代わりに PMSIHANDLE を使用する

PMSIHANDLE 型の変数は msi.h で定義されています。 インストーラーはスコープ外に出る PMSIHANDLE オブジェクトを閉じるのに対し、アプリケーションは MsiCloseHandle を呼び出して MSIHANDLE オブジェクトを閉じる必要があるため、アプリケーションが PMSIHANDLE 型を使用することをお勧めします。 PMSIHandle は、API 署名の互換性のために MSIHANDLE にキャスト演算子を提供します。

たとえば、次のようなコードを使用するとします。

MSIHANDLE hRec = MsiCreateRecord(3);

次のように変更します。

PMSIHANDLE hRec = MsiCreateRecord(3);