20

I have an installer of an application that needs to install over any existing version, regardless of version number.

Instead, I've got an installer that constantly says that I need to go to add/remove programs. That's very frustrating behavior for my testers, since it just slows them down for no real reason in their minds-- the previous installer package would always just install, deleting any files that were previously there, so they never had to do that step. We also have a (large) customer base that's been similarly trained, in that whatever version I install right now should overwrite whatever install I might have had before.

It seems, from what I can gather, that the WiX paradigm is to do things like block backwards version installations and other complicated things, like patching. Our customers, frankly, are not smart enough to know or care about patching, merging, whatever, and just want one installer that always works (and I'm inclined to agree with them; the bandwidth is cheap). So how do I get that?

I've tried this, but it just doesn't seem to matter:

<InstallExecuteSequence>
  <RemoveExistingProducts Before="InstallInitialize"/>
</InstallExecuteSequence>

This is version 3.0.5120 of WiX.

EDIT: As per Rob's suggestion there, I've added this code:

<InstallExecuteSequence>
  <RemoveExistingProducts After="InstallInitialize"/>
</InstallExecuteSequence>

<Upgrade Id="27cb76c7-544e-465f-b1f3-b11d9a49e416">
  <UpgradeVersion Minimum="0.8.0"
                  IncludeMinimum="yes"
                  Maximum="1.5.1"
                  Property="OLDERVERSIONBEINGUPGRADED" />
</Upgrade>

I'm not adding the code to not allow for a rollback installation; for reasons that are incredibly embarrassing to me, let's just say that an increase in version number does not necessarily correlate to an increase in software goodness. I don't want anyone to get locked out of what they think they need.

Also, very important, is to change the default GUID for the product to "*" in order to make for a different GUID with a different installer, which was apparently the problem.

mmr
  • 14,781
  • 29
  • 95
  • 145
  • 2
    i don't quite get your last sentence: Setting the default GUID for the product to * generates a new GUID for every compiled installer. This leads to a new installation side by side for every update. At least that's what i figured. I still trying to find a simple working PoC for your problem... – Martin Booka Weser Jun 25 '12 at 14:22
  • To me, it seems like the installations would never be side by side. As long as the upgrade codes matched, the old version would be uninstalled and the new one would be installed in its place. Isn't this expected behavior from wix? – Shadoninja Jan 29 '16 at 23:44
  • You can find the answer here: https://stackoverflow.com/questions/11732290/how-do-i-make-a-wix-msi-always-remove-a-previous-version – CITBL Sep 06 '19 at 18:27

1 Answers1

18

You want a major upgrade. There is a topic dedicated to that in the WiX.chm "How To" (also on the web: http://wix.sourceforge.net/manual-wix3/major_upgrade.htm).

Rob Mensching
  • 33,834
  • 5
  • 90
  • 130
  • 1
    Looking interesting. So if I just want the upgrading stuff, but I also want to allow going back a version, then I just leave out the second part about not allowing lower version installations, I'm thinkin'. – mmr Apr 22 '09 at 17:01
  • 2
    @mmr Can you share what you ended up doing? The link provided doesn't seem to fully answer to your question, if anything it tells you how to do the opposite of what you want. – user145400 Mar 12 '15 at 18:38