MSI: Fixing different component GUIDs for the same file

1
votes

I've inherited an installer with a fairly long history. In a few versions, component GUIDs were not tracked properly, resulting in different component GUIDs for a given file.

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}

This obviously violates component rules, and requires early sequencing of RemoveExistingProducts to avoid absent files after an upgrade.

Each new version installs as a Major Upgrade. It is expected that the latest version will cleanly upgrade any previous version.

Question: Is there any way to reset or salvage this scenario going forward? I'd like to schedule RemoveExistingProducts after InstallFinalize without causing destruction.

(I've been using heat.exe's deterministic GUIDs since I got ahold of the project. Best feature ever.)

1
wixwindows-installer
Why might scheduling REP just after InstallFinalize cause destruction? It's a documented choice, it's not clear what you're concerned about. - PhilDW
From the first link: "If two components have a resource under the same name and location and both components are installed into the same folder, then the removal of either component removes the common resource, which damages the remaining component." - Kevin Richardson
RemoveExistingProducts deletes the refcount==0 components (GUID_A in my scenario). If it's sequenced at the end, the newly-installed Foo.exe is removed. - Kevin Richardson
ok, my dumb mistake, I read InstallFinalize as InstallInitialize, which is where you should sequence REP to avoid the issue. - PhilDW
Yes, that's what is being done now. The question is whether there's a way to get into a situation where I don't have to do that. - Kevin Richardson

1 Answers

2
votes

To switch to a late major upgrade, you have to ensure you're only upgrading from versions that adhere to the component rules. So in this case, you have to block upgrades from v1.0.