現在、MSI Windows インストーラーを介して配布される製品を構築しています。その製品は、WiX Burn のようなブートストラップ/チェイナーまたは InstallShield のようなオーサリング ツールを使用して、独自の MSI 内で私たちのようなさまざまな形式を使用して、お客様によって統合されています。
このシナリオを念頭に置いて、MSI を維持する代わりにマージ モジュール (MSM) を使用することの制限や利点は何か、また、一方を他方に対して選択することについて最近推奨されているアプローチは何かを常に知りたいと思っていました。
紙の上ではマージモジュールは問題ありませんが、現実の世界では更新が面倒で、欠陥が発見される前に多くのセットアップにマージされる可能性があるため、エラーが発生しやすいことがわかります。その結果、マージ モジュールはまったくお勧めしません。私は、ブートストラップまたはバッチ ファイルを介してバッチ プロセスとして実行でき、簡単に更新できる単一の MSIを好みます。これにより、一般的に直感的ではないあらゆる種類の問題が回避されます。
マージ モジュールは、ファイル システム内の共有ファイル用の場所にインストールされ、頻繁には変更されない真の共有ファイルに対して適切に機能することを付け加えたいと思います。これらは一般にOS ランタイムです。これらのマージ モジュールは通常、十分にテストされており、問題なく動作します。ただし、頻繁に変更されるファイルにマージ モジュールを使用し、その場しのぎでさまざまなフレーバーのさまざまな場所にインストールする人をよく見かけます。この種の使用は完全な混乱であり、非常に無駄な努力です。
そうは言っても、マージモジュールを介して複数のセットアップに一連のファイルを繰り返し、変更せずに含める高度なリリース管理が必要な場合、マージモジュールを実際に使用して成功しました。それでも、しばらくするとバージョンの問題が発生し、いくつかのファイルを更新する必要があり、その後、プロジェクトを他の人に任せたときに間違ったマージ モジュールが使用されたというマイナーなエラーが発生しました。また、マイナーなマージ モジュールのバグ修正のために、すべてのセットアップを再構築する必要があったことも経験しました。その後、すべてのセットアップで再度 QA を実施する必要がありました。このような密結合には非常にイライラします。
要件が単純で、多数のファイルを共有する大規模なマルチ製品リリース プロジェクトに取り組んでいない場合は、 MSMの代わりにMSIを使用してください。理解しやすく、一般的に対処する作業が少なく、よりアトミックな更新が行われ、マージ モジュールの更新や設計上の問題が原因で多くのセットアップで同じエラーが発生するリスクが少なくなります。