WiX "Major Upgrade" doesn't completely install app on downgrade

Question

Currently all upgrades work fine whenever updating to a newer version number, however I'm getting an odd behavior when downgrading. It seems that it'll uninstall the existing version and then partially install the version that I'm trying to install, the main exe doesn't exist in the target location yet, but advertised shortcuts are created. When the advertised shortcut is opened, it'll finish the installation (presumably do a repair) and then it'll run fine.

Does anyone have any ideas why this is happening?

My upgrade block looks like this:

<UpgradeVersion Minimum="0.0.0.0" Maximum="99.0.0.0" Property="PREVIOUSVERSIONSINSTALLED" IncludeMinimum="yes" IncludeMaximum="no" IgnoreRemoveFailure="yes" />

(The IgnoreRemoveFailure was an attempt to fix this issue, but it doesn't appear to have done anything)

In my InstallExecuteSequence I have <RemoveExistingProducts After="InstallValidate" />

Also I have Product Id="*" and Package Id="*"

The reason the downgrade is needed is because the client application needs to be running the same version as the server to ensure compatibility, and the entire process needs to be automated so if the client/server versions don't match on signin the user can just click "yes" and the proper version is downloaded, installed and started. This is working so far for upgrades, but for downgrades an extra unintuitive step is needed which is to relaunch the app manually and then see a windows installer dialog pop up before it launches.

The end result is that regardless of upgrade or downgrade, the current version needs to be fully uninstalled and the downloaded version fully installed, so if there's another way to accomplish that, that'll also be a good answer.

Answer 1

This is what worked for me:

<Wix ...>
  <Product ...>
    <Property Id="REINSTALLMODE" Value="amus" />
    <MajorUpgrade AllowDowngrades="yes" />

Answer 2

Allowing downgrades isn't considered best practice, at least in part because it's so hard to test every combination you'll support while it's still possible to fix them. Is it not feasible to detect and block this case instead (suggest the remove the newer version first), and only automatically support moving forward?

If you must get this one working, is there anything in a verbose log for the downgrading install (or for the repair - you'll need to set the machine's logging policy to get this one created) which confirms the major upgrade (I'd look near FindRelatedProducts) or discusses why the component for your exe isn't installed? Definitely check for any log lines with SELMGR as they might explain this in a minor upgrade scenario.

Since an advertised shortcut is in place, it sounds like the component was advertised instead. This could indicate component rules violations in a minor upgrade (specifically the addition of a component in a newer version looking like the removal in your older version - see HeathS's commentary) though it appears the Product/@Id='*' should force a major upgrade.

You might also try working in a sample project, starting from a base version that has a single feature, single component, and single file with shortcut. If relevant, add another component and file to the upgraded version; otherwise just increment the file versions. Then try your reverse scenario. Slowly add things in until you find your culprit. Then hope it's something you can remove from your real product, or can otherwise be worked around.

Answer 3

My suggestion is a little on the "make it work" side - you could try a silent repair custom action in case of downgrade.

Answer 4

How did you order the operations in your InstallExecuteSequence?

If you perform the uninstall after the install (which gives you the best upgrade performance) you might see issues if file versions change to lower versions; which could be the case on your downgrades.

Windows installer will not overwrite older versions with newer versions unless explicitly asked.

Reordering to uninstall before installing should help if this is the case.