4

Basically I need to change this behavior:

Installing a product with the same version and upgrade code (but different product code) is allowed and treated by MSI as two products.

I need this to be threated as Major Upgrade. So installing v 1.0.1 over v 1.0.1 (old build, different ProductCode) will uninstall old one. This is because I'm not interested in changing versions unless we're going for public release.

I have:

<Product Id="*" UpgradeCode="2067109E-DCDA-4639-B4FC-B95E0A239E1A" Version="1.0.1"...
....
<MajorUpgrade AllowSameVersionUpgrades="yes" ...

What I have now is two entries under Add/Remove Programs, which is not what I want.

Kara
  • 6,115
  • 16
  • 50
  • 57
Dizzy
  • 892
  • 3
  • 12
  • 24
  • I would recommend thinking about versioning your installers with every build. That way if you have an issue, it will be able to reference, which build, which installer. If you had to force some specific version number for the actual release, say 1.0.1, you could change that manually just before the final release build. – BryanJ Dec 20 '13 at 19:04
  • Actually single .msi works as expected. This is the Bundle who creates duplicate Add/Remove Programs entries. Found related bug: http://sourceforge.net/p/wix/bugs/3065/ – Dizzy Dec 26 '13 at 06:40
  • Interesting. Not sure how to fix that, although WiX bundles do allow for (and take into account) a fourth version number (even though the msi's themselves ignore the fourth version). So one workaround could be to version each build with a build number as in 1.0.1.####, although that doesn't answer your questions. – BryanJ Dec 26 '13 at 07:30

1 Answers1

2

Just add a fourth version number (Major.Minor.Patch.Build) and increment the build number for each new build.

Using the same UpgradeCode but a different ProductCode, will allow any installer with the same (Major.Minor.Patch) to be installed as an upgrade, but at least you will know what build version is installed.

Make sure to use 

<MajorUpgrade AllowSameVersionUpgrades="yes"

Note that this will not prevent earlier builds to be installed when a later build is present.

oɔɯǝɹ
  • 7,219
  • 7
  • 58
  • 69
  • @BryanJ's comment is the right answer. I don't want to take credit, so using community wiki. – oɔɯǝɹ Jan 14 '15 at 21:42
  • How do you increment the build for each new build without modifying the file manually? – Pablo Fernandez Apr 23 '18 at 20:06
  • @pupeno that really depends on your build environment. You can use (for example) a source control changeset number, or a date based number to generate a buold number. Ideally you want to be able to use the build number to determine what source version was used whem building that version. You could also tag a soirce version with the build number. – oɔɯǝɹ Apr 23 '18 at 20:13
  • I'm using git and Maven as my build tool. I don't see how the build number can be incremented without opening the `wxs` file each time I want to build an installer to try, incrementing it by one, saving it, committing it, building it, pushing it. This is quite annoying to do for me and other developers in the same team that will get a stream of meaningless commits, and also, I could run out of Build numbers, as there's only 256 entries in each of the quad version entries. – Pablo Fernandez Apr 23 '18 at 20:16
  • That would seem to be a question in itself, but why the need to commit after increment? Just checkout the .wsx on the build server, imcrement the value locally, build the package and undo the checkout/don't commit. – oɔɯǝɹ Apr 23 '18 at 20:22
  • What do I do with the change if I don't commit? roll it back? leave it there forever? If I roll it back, the next time I build an installer, it'll be a lower version than the currently installed. If I leave it there, what will happen is that I will most likely commit it accidentally with something unrelated or it will cause conflicts when the file gets changed somewhere else. – Pablo Fernandez Apr 23 '18 at 20:28