Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Can we upgrade 1.0.0.0 to 1.0.0.1 while changing product code?

I'm asked to upgrade ver 1.0.0.0 to 1.0.0.1. By default, when I tested with a dummy installer, if we change the product code, both 1.0.0.0 and 1.0.0.1 would install side by side.

But if we do the ver 1.0.1.0 (while changing product code), it would do the upgrade. Here is my upgrade segment:

   <Upgrade Id="{354E9DAE-EB70-4BCC-BD93-AC20ACE3F370}">
     <UpgradeVersion
      Maximum="$(var.ver)"
      Property="DOMAJORUPGRADE"
      MigrateFeatures="yes"
      IncludeMinimum="yes"/>
   </Upgrade>

Question: Is there any method to upgrade 1.0.0.0 to 1.0.0.1?

Actually, I'm given a scenario like this:

  1. When installing 1.0.0.1 on top of 1.0.0.0, then 1.0.0.0 needs to be upgraded.
  2. When installing 1.0.0.0 on top of 1.0.0.1, the 1.0.0.0 needs to fail.
  3. When installing 1.0.0.1 on top of 1.0.0.1 with different product code (only possible in development builds), the existing 1.0.0.1 needs to uninstall.
like image 770
Farrukh Waheed Avatar asked Dec 04 '22 11:12

Farrukh Waheed


2 Answers

Checkout the help topic MajorUpgrade Element:

The following is said about the AllowSameVersionUpgrades attribute:

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.

Tim's answer is 95% correct. I really don't suggest changing only the 4th version. That said, there is a way to mitigate the "accidental downgrade" bug mentioned above. Write a MajorUpgrade rule that does not detect the same version. Then write a custom action that does an additional check for products that are greater in the fourth field and share your UpgradeCode. Set or append this detected ProductCode to the ActionProperty. Schedule this custom action betweeen FindRelatedProducts and RemoveExistingProducts and you'll get the desired behavior that Windows Installer was never designed for.

like image 179
Christopher Painter Avatar answered Jan 11 '23 03:01

Christopher Painter


No, because MSI ignores the revision part of a version number. MSI sees versions 1.0.0.0 and 1.0.0.1 as being exactly the same because it's only looking at major, minor and build bits of the versions, i.e. 1.0.0 which are the same in both.

ProductVersion property

like image 37
Tim Owers Avatar answered Jan 11 '23 03:01

Tim Owers