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.

Ferryman

I have endless problems with this even today. WiX added a new "MajorUpgrade" element which was supposed to make things harder to get wrong. We're using this now, but even so, downgrades have the same issue as before. The difference now is that it removes a couple of culprits: (1) The InstallExecuteSequence (2) The UpgradeVersion element. – Thickknee

Answer 1

This is what worked for me:

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

Illboding

This should be the accepted answer. This worked for me too, although I used "dmus" instead of "amus" to only overwrite the files if the version is different. Complete list of flags here: msdn.microsoft.com/en-us/library/… – Alan

This worked also for me, even if I have a warning: "REINSTALLMODE is defined in the Property table. This may cause difficulties." – Strang

Also, to get rid of the warning, you can follow: #70883121 <SetProperty Id="REINSTALLMODE" Value="amus" Before="FindRelatedProducts" Sequence="first" /> – Strang

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.

Maldon

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.

Kunlun

I couldn't find how to schedule a repair as a custom action. Do you have any links that describe this? – Ferryman

I was thinking at something like run a custom action with msiexec and using your msi as a source (msiexec /fa prod.msi /qn) – Kunlun

I'm not sure you can have more than one windows installer instance running at a time. In this case there would be two. One executing from within another. – Apoplectic

Hmm... now that I think of it.. the MSI is never run directly by the enduser, it's always scheduled through some sort of bootstrapper so I could make that work I think. Will try and mark as accepted if that's the case. – Ferryman

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.

Barfield

Uninstall is ordered before install. Had that problem before with upgrades until I rescheduled it. Now it works with upgrades, but still has problems with downgrading – Ferryman

Answer 5

What happens if you use two "UpgradeVersion" elements?

<UpgradeVersion Maximum="CurrentVersion" Property="PREVIOUSVERSIONSINSTALLED" IncludeMaximum="no" />
<UpgradeVersion Minimum="CurrentVersion" Property="PREVIOUSVERSIONSINSTALLED" IncludeMinimum="no" />

Apoplectic