Minor Upgrade Randomly Leaves Old Version in Add/Remove Programs

[mjanulaitis]

• Which version of WiX are you building with?

3.11 Release Build

• Which version of Visual Studio are you building with (if any)?

2019

• Which version of the WiX Toolset Visual Studio Extension are you building with (if any)?

NA

• Which version of .NET are you building with?

4.7.2

• If the problem occurs when installing your packages built with WiX, what is the version of Windows the package is running on?

Server 2016 Fully Patched

• Describe the problem and the steps to reproduce it.

Randomly on some servers and workstations running a minor upgrade leaves behind the old version in the add/remove programs list. This does not always occur. I just tested two of my latest builds on another machine and the old version was removed from add/remove. The same exact builds that a customer used produced very different results. In their case, and in one test case of my own, the old version remains in the add/remove programs. I'm not sure if this is an MSI bug or Wix but at any rate, some installations show over 10 old versions while other installations only show the latest. Click on an old version in add/remove programs removes the item. The uninstaller seems to just remove the registry entry so the item is removed from add/remove programs. Nothing else runs including custom actions are to run immediately at startup.

Update:
Here is the Product and Package attributes. The Upgrade code never changes. My build scripts simply parse the Version and update it to a higher number. This viewer does not handle xml so that's why I have escaped the less than and greater than values.

<Product Id="{F621DE0C-9524-4723-AB8F-9BD724F33130}" Name="My Product Name" Language="1033" Version="20.0.0.100" Manufacturer="" UpgradeCode="{2D860B08-38BA-422A-A4EF-259DD39D9716}">
<Package Id="*" Keywords="Installer" Description="My Product Installer" Comments="" Manufacturer="" InstallerVersion="300" Languages="1033" Compressed="yes" InstallScope="perMachine" />

`

• Describe the behavior you expected and how it differed from the actual behavior.

I expect the old version to be removed 100% of the time rather than 25% or so from the add/remove programs.

[barnson]

WiX doesn't use issues for support. We moved this issue to the experimental GitHub discussions area.
You might also consider asking your question on the wix-users mailing list or posting on Stack Overflow.

[robmen]

You'll need to pour over the log files to track down the inconsistencies. Eventually, I'm pretty confident you'll find the root cause is not a random number generator 😄 but some (possibly complex) interplay between package versions that manifest the problem.

Good luck. If you want help diagnosing complex (or even not so complex installation problems), check out commercial support from FireGiant.

[mjanulaitis]

Thank you yes I agree. Do you know what I should be looking for?

[mjanulaitis]

@robmen This is not a support issue. I see this issue randomly on various installs. I am running burn with the following params:

-q -norestart

I have somewhat tracked this down to the install pending a reboot. Each time the software auto updates itself the binaries are updated, however the old burn is not removed from the add /remove. Running an uninstall is instantons and my custom actions that run on new or minor upgrades are executed. Nothing is removed thankfully just the add/remove programs registry entry. The only way to remove is to uninstall the latest version listed in add/remove programs.

[robmen]

You'll want to look at the log file for the nested uninstall of the upgraded bundle to see why it is not uninstalling.