10

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.

Yan Sklyarenko
  • 31,557
  • 24
  • 104
  • 139
Davy8
  • 30,868
  • 25
  • 115
  • 173
  • 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. – Hakanai Nov 15 '11 at 22:49

5 Answers5

6

This is what worked for me:

<Wix ...>
  <Product ...>
    <Property Id="REINSTALLMODE" Value="amus" />
    <MajorUpgrade AllowDowngrades="yes" />
Gian Marco
  • 22,140
  • 8
  • 55
  • 44
  • 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: https://msdn.microsoft.com/en-us/library/aa371182%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 – Gyum Fox Mar 04 '16 at 10:04
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.

Michael Urman
  • 15,737
  • 2
  • 28
  • 44
1

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

Gabriel
  • 99
  • 3
  • I couldn't find how to schedule a repair as a custom action. Do you have any links that describe this? – Davy8 Oct 12 '09 at 20:21
  • I was thinking at something like run a custom action with msiexec and using your msi as a source (msiexec /fa prod.msi /qn) – Gabriel Oct 12 '09 at 23:09
  • 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. – w4g3n3r Oct 16 '09 at 17:54
  • 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. – Davy8 Jan 07 '10 at 19:10
1

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.

Sander Rijken
  • 21,376
  • 3
  • 61
  • 85
Bert Huijben
  • 19,525
  • 4
  • 57
  • 73
  • 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 – Davy8 Oct 19 '09 at 04:23
0

What happens if you use two "UpgradeVersion" elements?

<UpgradeVersion Maximum="CurrentVersion" Property="PREVIOUSVERSIONSINSTALLED" IncludeMaximum="no" />
<UpgradeVersion Minimum="CurrentVersion" Property="PREVIOUSVERSIONSINSTALLED" IncludeMinimum="no" />
w4g3n3r
  • 967
  • 5
  • 8