15

Does anyone know:

  1. How can I Force wix installer to uninstall any previous copy previously installed, whether minor or major before installing a new version of our setup.

  2. If 1) can't be done when running a new minor/major setup, can I at least display a message saying that a previous version was detected and it should first be uninstalled and cancel the setup?

Thanks.

UPDATE:

I've added the following to my settings.wxi

<Upgrade Id="$(var.UpgradeCode)">

    <!-- Populate NEWERPRODUCTFOUND if there is an installed 
         package with the same upgrade code
         and version is > the version being installed -->
    <UpgradeVersion
         Minimum="$(var.CurrentVersion)"
         IncludeMinimum="no"
         OnlyDetect="yes"
         Language="1033"
         Property="NEWERPRODUCTFOUND" />

    <!-- Populate UPGRADEFOUND if there is an installed 
         package with the same upgrade code
         and the version is between the earliest version defined
         and the version being installed -->
    <UpgradeVersion
         Minimum="$(var.FirstVersion)"
         IncludeMinimum="yes"
         Maximum="$(var.CurrentVersion)"
         IncludeMaximum="no"
         Language="1033"
         Property="PREVIOUSVERSIONSINSTALLED" />
</Upgrade>

I've defined the following in MyProduct.wxs

<?define CurrentVersion="5.0.0.18"?>
<?define FirstVersion="1.0.0.0"?>
<?define UpgradeCode="c1b1bfa0-9937-49eb-812c-5bac06eff858"?>

and finally, I've added this to my <InstallExecuteSequence>

<RemoveExistingProducts Before="InstallInitialize" />

But it still not removing the old version when I increase my version to 5.0.0.19.

Maybe I'm looking at this the wrong way, but in my "Add/Remove Programs" window, I see my setup listed as 5.0.0.18 and I see a second entry as 5.0.0.19

Should I be changing the upgrade code every time I change my version? I thought I had read that this should never be changed.

Any ideas?

Thanks.

Thierry
  • 6,142
  • 13
  • 66
  • 117
  • 1
    If you know all the possible UpgradeCodes and ProductVersions, can't you make your own Upgrade elements to locate and upgrade them all? WiX MajorUpgrade may already be enough, but you can list everything in Upgrade elements if it's not. – PhilDW Oct 13 '14 at 15:57
  • @PhilDW Thanks for the feedback. I'll look into it further. I've never done an upgrade before and I'm just about to finish the actual setup, so I'm at the gathering info stage. – Thierry Oct 14 '14 at 11:35

2 Answers2

19

I figured out the answer after a lot of googling!! Windows Installer doesn't take into account the 4 number of the version which is what I was using i.e. 5.0.0.18.

It only looks at the first 3 sets of number making the version number. Once I changed my version to 5.0.18.0 to 5.0.19.0, it worked immediately with the code posted in the question and it removed the previous version and installed the newer one over it.

Note that I've actually removed the above code and ended up using the MajorUpgrade instead as it was all I needed:

<MajorUpgrade
  AllowDowngrades="no"
  AllowSameVersionUpgrades="no"
  IgnoreRemoveFailure="no"
  DowngradeErrorMessage="loc.NewerVersionInstalled"
  Schedule="afterInstallInitialize"/>

Hope this helps someone else!

Thierry
  • 6,142
  • 13
  • 66
  • 117
8

Here is the documentation for the AllowSameVersionUpgrades attribute of the MajorUpgrade element. It contains pertinent information. The emphasis is mine.

When set to no (the default), installing a product with the same version and upgrade code (but different product code) is allowed and treated by MSI as two products. When set to yes, WiX sets the msidbUpgradeAttributesVersionMaxInclusive attribute, which tells MSI to treat a product with the same version as a major upgrade.

This is useful when two product versions differ only in the fourth version field. MSI specifically ignores that field when comparing product versions, so two products that differ only in the fourth version field are the same product and need this attribute set to yes to be detected.

Note that because MSI ignores the fourth product version field, setting this attribute to yes also allows downgrades when the first three product version fields are identical. For example, product version 1.0.0.1 will "upgrade" 1.0.0.2998 because they're seen as the same version (1.0.0). That could reintroduce serious bugs so the safest choice is to change the first three version fields and omit this attribute to get the default of no.

This attribute cannot be "yes" when AllowDowngrades is also "yes" -- AllowDowngrades already allows two products with the same version number to upgrade each other.

Setting this attribute to yes is probably not what you want, though, because, according to the third paragraph, version 5.0.0.18 would be seen as an upgrade over version 5.0.0.19. Set this attribute to no and use the third product version field to only allow upgrades.

qxn
  • 17,162
  • 3
  • 49
  • 72