Using Wix4/wixsharp MSI to upgrade Wix3 bundle leaves behind an orphaned ARP entry for the old version

[lab2k1]

I have an app whose v1 was installed using a Wix3 bundle. I wrote a Wix4/wixsharp installer for v2 of the same app. A very basic installer, using just the native dialogs and a couple of custom actions. Fresh installs work fine, but upgrading from v1 to v2 leaves a v1 entry in ARP, right next to the newly added v2 entry. I verified that the v1 files/settings/etc are in fact removed before the v2 ones are installed. What's left behind is just that orphaned v1 entry in ARP. To preempt the obvious, both v1 and v2 installers are per-user and have the same upgrade code, language, manufacturer etc.

Digging some more, turns out that the Wix3 bundle makes two entries in ARP upon installation. Main entry under the 64-bit HKCU\Software\Microsoft\Windows\Uninstall for the MSI payload of the bundle. The other one (surprisingly) under the 32-bit HKLM\Software\WOW6432Node\...\Uninstall for the bundle bootstrapper. Upgrading to v2 (with just a plain MajorUpgrade.Default) removes the first HKCU uninstall entry and all files/settings/etc, but leaves behind the HKLM uninstall entry. This is the entry which is displayed in ARP. This is consistent with Wix4 doing something like msiexec /x {product-code} for the HKCU entry, instead of the command listed as the UninstallString in the registry.

Doing an Uninstall in ARP gets rid of the v1 ghost entry, without breaking the v2 upgrade, but that's not something end users should be burdened with. I hope I am missing something basic, and there is an easy way to right this, other than having to write a custom action to criss-cross the registry and uninstall by hand. Any pointers much appreciated, thank you.

[oleg-shilo]

@lab2k1, it's really something strange. And I also agree the workaround you did is not something that "end users should be burdened with".

Unfortunately, I do not have the answer for you. But if I were in your shoes I would probably collect both msi and bundle WXS and try to figure out what is causing this problem. There is a good chance that it is already discussed somewhere and most likely the discussion was around the WiX definition(s). That's why you will need the generated WXS files. Also... WixSharp does not do much of its own behaviour.