9

製品 A と B がそれぞれ複数の MSI をインストールし、一部の MSI が同じ場合、A または B のいずれかをアンインストールすると、もう一方に影響しますか? 設置場所は重要ですか？

また、一般的な MSI C のバージョンが製品 B で高く、B がインストール時に C をアップグレードするとどうなりますか? ここで、B をアンインストールすると、製品 A を破壊する一般的な MSI C が削除されます。Permanent フラグを使用せずに、これをどのように適切に処理しますか?

4

3 に答える 3

14

この質問で最初に頭に浮かぶのは、問題の製品が本来あるべき方法で分解されているかどうかです。

原則として、すべての MSI ファイルは自分がインストールしたものを所有していると見なし、参照カウント (コンポーネントを使用している製品の数) がゼロの場合、アンインストール時に MSI 内のコンポーネント GUID に関連付けられているすべてのものをアンインストールします。

この規則にはいくつかの条件があります。

  • コンポーネントが永続的とマークされている場合、 アンインストールされることはありません
  • ファイル/レジストリ項目にコンポーネント GUID がまったくない場合、インストールされ、Windows インストーラーによって追跡されず、アンインストールもされません。
  • 最後に、MSI の参照カウントにより、同じコンポーネントを複数の製品間で共有できるようになり、他の複数のインストーラー パッケージで使用中に登録されている場合、アンインストール中にディスク上に保持されます。

MSI パッケージ間で共有コンポーネントを作成するためのメカニズムは、一般的に次のとおりです。

  1. マージ モジュールを使用すると、参照カウントされ、システム上で GUID を使用している他のクライアントが存在する場合に関連製品のアンインストール後もディスクに残る共有コンポーネントをインストールできます。マージ モジュールは、コンパイル時に他の MSI パッケージにマージされます。必要に応じて、バイナリ アーリー バインディングの形式。任意のパッケージにマージできます。
  2. Wix (xml ベースのインストーラー ソース ファイル)の出現により、マージ モジュールの代わりにXML ソース インクルード ファイルを介して複数のセットアップから同じファイル セグメントを含めることが可能になりました。これは、Wix がソース管理に適しているため、私の意見では非常に優れています (説明については、Wix のリンクを参照してください)。「 Wixソースインクルードファイル」を認識することは非常に重要です" マージ モジュールとまったく同じ効果があります。そのコンポーネントは、ソース ファイル内の GUID がハード コードされている場合、異なるインストーラー パッケージ間で共有するために適切に参照カウントされます (この特定の目的で自動生成された GUID を使用しないことをお勧めします)。一般的なランタイム ファイルにはサード パーティのマージ モジュールを使用する必要があるというのが私の個人的な意見ですが、独自の共有ファイルには Wix インクルードのみが含まれます. マージ モジュールは、Wix インクルードよりも管理が難しい.

更新とファイルの置換:

  • 更新シナリオに関しては、特別な Windows インストーラー プロパティREINSTALLMODEの全体的な設定に応じて、 MSI ファイル置換ルールが新しいファイルの更新を処理します。
  • 一般に、上位バージョンのファイルは下位バージョンのファイルを上書きします。バージョン管理されていないファイルは、変更されていない場合は上書きされます。それらが変更された場合、作成日スタンプと変更日スタンプが異なり、ファイルはそのままになります。
  • ファイルのダウングレードの問題は、全体的な MSI 設計によって積極的に抑制されていることに注意してください。ファイルをダウングレードする必要がある場合 (共有されているかどうかに関係なく)、設計に配置の臭いがあります。

この時点で、これらの回答を徹底的に読みます。

Wix を使用している場合、または Wix を使用する意思がある場合、重複する製品に対処する最善の方法は、インストーラーを必要に応じてメインのインストーラーに含めるWix セグメント ソース ファイルに分解することだと思います。これにより、1 つの製品をアンインストールしても、他のアプリケーションで使用されているコンポーネントをそのまま残すことができます。

そうは言っても、この記事（上記にもリストされています）にリストされている理由により、インストーラーであまりにも多くの重複する依存関係を引き起こすのは好きではありません：複数のアプリケーションをインストールする Wix。

安定性のためには、共有コンポーネントがコンパイルまたはマージされるすべてのセットアップの再コンパイルが一般的なルールとして必要になるため、バグ修正としてあまりにも多くのセットアップで使用される前に、共有コンポーネントが安定していることが非常に重要です。簡単に言うと、一緒に変更されるファイルをまとめてバンドルします。

この大規模な再コンパイルの必要性に対抗するために、いくつかの共有コンポーネントで構成されるスタンドアロンのサポート セットアップを提供することを選択できます。Wix が含まれる可能性が高い「共有コンポーネント設定」の 1 つまたは 2 つには、同様の遅いリリース スケジュールで一緒に変更が含まれ、各製品の個別の設定は、バランスを維持しながら展開のニーズに対応できる必要があります。保守性と柔軟性の間。

製品のセットアップは頻繁に再コンパイルする必要があり、共有モジュールのセットアップは再コンパイルが最小限になるように設計する必要があります。次に、要件の変更を待ちます:-)。

私にとっては、結束と結合がすべてであり、販売、マーケティング、および技術的ニーズのバランスを取ることの難しさです。

于 2014-08-10T11:24:22.960 に答える