1
かなり長い歴史を持つインストーラを継承しました。いくつかのバージョンでは、コンポーネントのGUIDが適切に追跡されず、特定のファイルのコンポーネントGUIDが異なります。MSI：同じファイルの異なるコンポーネントのGUIDを修正する
明らかv1.0: C:\Program Files\Foo\Foo.exe {GUID_A}
v2.0: C:\Program Files\Foo\Foo.exe {GUID_B}
v3.0: C:\Program Files\Foo\Foo.exe {GUID_B}
このviolates component rules、およびアップグレード後に不在のファイルを避けるためにRemoveExistingProductsの早期シーケンシングが必要です。
それぞれ新しいバージョンがMajor Upgradeとしてインストールされます。最新のバージョンでは、以前のバージョンが正常にアップグレードされることが予想されます。
質問：今後このシナリオをリセットするか、サルベージする方法はありますか？私はInstallFinalizeの後でRemoveを起こさずにRemoveExistingProductsをスケジュールしたいと思います。
（私はプロジェクトのアホールドを得たので、私はheat.exe's決定論のGUIDを使用してきた。チャームポイントを今まで。）
InstallFinalizeの直後にREPをスケジューリングすると、破壊されるのはなぜですか？それは文書化された選択肢であり、あなたが心配していることは明確ではありません。 – PhilDW
最初のリンクから： "2つのコンポーネントに同じ名前と場所のリソースがあり、両方のコンポーネントが同じフォルダにインストールされている場合は、いずれかのコンポーネントを削除すると共通リソースが削除され、残りのコンポーネントが破損します。 –
RemoveExistingProductsはrefcount == 0のコンポーネント（私のシナリオではGUID_A）を削除します。最後にシーケンスが行われると、新しくインストールされたFoo.exeが削除されます。 –