3

I have an Installshield project.

I added a major upgrade item and changed Product version , Product code and Package code.

After the installation with the new installer, the old version is still present (in Add / Remove)

I think it's related to the fact that my old version number was 1.0.4.23 and new one is 1.0.4.24 - is this a problem? Does major upgrade ignore such a small change in the version property?

In major upgrade common tab I chose Any earlier version

I remember doing this years ago with version numbers 1.1 and 1.2 and everything worked great, this is the main reason why I suspect the current issue is related to version numbers.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
Noam
  • 1,640
  • 4
  • 26
  • 55

1 Answers1

5

I think it's related to the fact that my old version number was 1.0.4.23 and new one is 1.0.4.24 - is this a problem? Does major upgrade ignores such a small change in version?

Yes, only the first three fields of the version number are significant for major upgrade. The fourth field is simply ignored.

This is stated in a note at the Major Upgrades MSDN page.

If you want to trigger a major upgrade, your new version number must be 1.0.5.0 or greater.

Edit:

As Christopher Painter points out:

There is a way around this if you must use all four fields. You can create a custom action that does your own implementation of FindRelatedProducts and sets the action property with a ProductCode that RemoveExistingProducts then acts upon.

The custom action could be implemented like this:

  1. Call MsiGetProperty to get the UpgradeCode of your product.
  2. Call MsiEnumRelatedProducts() to enumerate all products that have the same UpgradeCode as your product.
  3. Call MsiQueryProductState() to verify that the product(s) returned by MsiEnumRelatedProducts() are actually installed. I experienced some cases where MsiEnumRelatedProducts() returned orphaned products that were no longer installed. So the code will be more robust by double-checking the install state with MsiQueryProductState().
  4. Call MsiGetProductInfo() with INSTALLPROPERTY_VERSIONSTRING as the argument for the szProperty parameter to query the version of the installed product. Don't use INSTALLPROPERTY_VERSION instead, because INSTALLPROPERTY_VERSION is derived from only the first three fields of the version number, the problem which we want to avoid.
  5. When comparing version numbers, make sure you don't just compare the strings, but parse the strings into the fields that are separated by '.' and compare the fields individually.
  6. If you found a matching product that you want to replace, call MsiSetProperty() to set the ActionProperty to the ProductCode of this product that RemoveExistingProducts then acts upon.
zett42
  • 25,437
  • 3
  • 35
  • 72
  • Thank you for including reference in your answer. – Noam Dec 31 '17 at 15:20
  • 1
    There is a way around this if you must use all four fields. You can create a custom action that does your own implementation of FindRelatedProducts and sets the action property with a ProductCode that RemoveExistingProducts then acts upon. – Christopher Painter Dec 31 '17 at 21:50
  • 2
    @ChristopherPainter I have added the steps of a possible implementation of such a custom action. – zett42 Jan 02 '18 at 13:51
  • 1
    Cool. Just a design tip... you can write it data driven by querying the Upgrade table. You could also add a custom column to set a flag to process only certain rows. For each row, if has flag, get action property, query MSI, append action property. It's something I wish InstallShield did about 15 years ago. ;) – Christopher Painter Jan 02 '18 at 14:22
  • Exotic indeed :-). – Stein Åsmul Jul 19 '18 at 11:32