Windows installer duplicating entries when it's the same version, but a different Id

Question

I'm creating a Windows installer for my app using WIX, so, I start in the usual way:

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
     xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
    <Product Id="*" Name="Project X" Manufacturer="X LLC" Language="1033"
             Version="1.0.0.1" UpgradeCode="PUT-GUID-HERE>
        <Package InstallerVersion="301" Compressed="yes" InstallScope="perMachine"/>

        <MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed."/>

Because the Id is set to *, every time I build an MSI it has a different id, but the UpgradeCode remains the same. This successfully achieves replacing the old one with a new one when there's an upgrade in version (1.0.0.2 for example).

The MajorUpgrade entry prevents a lower version, such as 1.0.0.0, from being installed.

If I run exactly the the same MSI file, it shows me a dialog to repair, uninstall or change the installation parameters.

My problem is that if I re-build the MSI, and run the new one, it installs as if there's no other copy of Project X installed and the user ends up with two entries in the Windows Apps & Features.

Is there a way to prevent that? Is there a way to prevent it without having to modify (and commit) my .wxs file or another build file each time I build? I try to have my builds as automated as possible and having to open a file a change it each time would be really annoying.

Regarding passing the version number to candle.exe, it doesn't solve the problem. That would still require storing the version number in the repo, creating commits for each test of the installer. It's the same problem whether I have to write the number manually in the wxs file or I have to write the number manually in the pom.xml (that's the build tool's config) or whether it's generating during build and stored on a file that then I have to commit to the repo so that the number keeps monotonically increasing for myself and all developers involved.

In case this matters, I'm using Git as my source control system, and Maven as my building tool, calling heat.exe, candle.exe and light.exe. Specifically, I'm not using Visual Studio.

Regarding the similar question WIX. How to perform Major Upgrade with same version and different product code?, both the question and the answer assume it's ok to modify the .wxs file to increment the version number each time you build an installer to test. I don't think it's acceptable. I already knew this was possible because this is what MajorUpgrade does and I took note in this question.

Answer 1

This is because your ProductCode GUID is being randomly generated each build but your ProductVersion isn't being incremented. You need to follow the format 0-255,0-255,0-255 (fourth allowed by ignored per spec) and increment it each build. Then each MSI will perform a major upgrade resulting in one entry.

This machine is now in a bad state so cleaning it up could be fun. I'd uninstall all the legacy instances first then move forward.

Answer 2

Generate the version number in the build system and pass it to the candle.exe command line:

candle.exe -dProductVersion=<value>

Then refer to the preprocessor variable:

<Product Version="$(var.ProductVersion)" ...

Note that only the first fields in the product version are limited to 255. The third (and fourth, if you use it) can be up to 65535.

Answer 3

I am in a hurry, I don't have time to read your question in the detail I would like to. However, skimming it I think I dealt with something similar a while back, and I decided to try the old-style major upgrade elements in WiX to get more control over how the Upgrade Table ends up being populated. The Major Upgrade is a convenience feature, using the old-style elements you get more fine grained control of the Upgrade Table.

I am not sure whether this is what you are after, but let me try to link to the answer I am referring to: Doing Major Upgrade in Wix creates 2 entries in Add/Remove Programs. As I recall it, I changed it so running a same-version MSI with different product codes triggers a "downgrade not allowed-message", and hence prevents a new version from installing on top of an existing version. You can then uninstall the old version from Add / Remove programs manually, or right click the old MSI and select Remove. Right clicking the new MSI and going Remove will not work - since this MSI has a new product code, and will not be able to uninstall the previous version this way.