cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
SMM-OSSI
Level 3

ProductCode and UpgradeCode out of sync

Background:

  • VS 2015 C# WinForm application
  • InstallShield 2015 Professional
  • InstalScript MSI project


We have an installer where the setup files have gotten their ProductCode and UpgradeCodes out of sync from previous versions.

The chronology of the builds goes something like this:

1.0.0.0

  • ProductCode: {ABC-123}
  • UpgradeCode: (DEF-456)


1.0.0.1

  • ProductCode: {ABC-123}
  • UpgradeCode: {GHI-789} (Changed)


1.0.0.2

  • ProductCode: (JKL-012) (Changed)
  • UpgradeCode: {GHI-789}


So from version .0 to .1, the UpgradeCode was modified. From version .1 to .2, the ProductCode was modified. I am now ready to deploy version 1.0.0.3. It has the same ProductCode and UpgradeCode as 1.0.0.2:

1.0.0.3

  • ProductCode: (JKL-012)
  • UpgradeCode: {GHI-789}


At this point, all earlier versions are installed out there somewhere. So I have some users on v1.0.0.0, some on v1.0.0.1, etc.

The question is, is there any way to configure InstallShield so that I can get all of them back on the same ProductCode and Upgrade code so that going forward, I can run proper updates? By a proper update, I mean that when the setup exe runs, it notifies the user that this is an update and then only updates files as needed.

As it is now, if a user on a version prior to the ProductCode change (<1.0.0.2), and runs 1.0.0.3, it does not recognize this as an upgrade and installs the new version along side the old one. However, if they have 1.0.0.2 (on the new ProductCode) and run 1.0.0.3, it works fine. This is all expected, as I understand that the installer recognized different ProductCodes as different products, but what I need is a way to get everything back in sync with the latest setup file.

Lastly, our setup file includes options to select specific features and a custom option selector. If it does a fresh install, or anything other than a proper upgrade, these panels show up in the installer with the original default settings. We want to avoid having these pop up during an upgrade, which is why it is so important to get the setup file back in sync so that upgrades are upgrades and fresh installs are fresh installs all around. Oh, and we want to avoid having the user uninstall/reinstall the product because the user may not know aforementioned setup options the second time around.

Thanks in advance,
Scott
Labels (1)
0 Kudos
(6) Replies
chad_petersen
Level 9

I do this sort of thing quite a bit. I recently combined 4 various MSI installers into one, but still wanted to remove the older flavors which each used their own UpgradeCode and ProductCode and Versions were all over the place.

If you look under the Media node at the Upgrade choice then once selected - in the middle pane if you right-click on "Upgrade Windows Installer Setup" and choose "Add Major Upgrade Item" then it lets you specify the UpgradeCode of one of the other packages. Choose "Products having another Upgrade Code" and paste in the GUID from one of them. Do the same for any number of other packages you want it to detect. In the Advanced tab in the right hand pane if you say "Detect Only" = "No" then it will uninstall that other package for you.

I hope that helps some.

Chad
0 Kudos
chad_petersen
Level 9

0 Kudos
SMM-OSSI
Level 3

Chad,

Thanks for your help on this!

1.0.0.0

  • ProductCode: {ABC-123}
  • UpgradeCode: {DEF-456}


1.0.0.1

  • ProductCode: {ABC-123}
  • UpgradeCode: {GHI-789} (Changed)


1.0.0.2

  • ProductCode: {JKL-012} (Changed)
  • UpgradeCode: {GHI-789}


1.0.0.3

  • ProductCode: {JKL-012}
  • UpgradeCode: {MNO-345} (Changed)


I took your advice and added a Major Upgrade item to the installer for each old UpgradeCode. So I added one for {DEF-456}, one for {GHI-789} and one for the current one. I also specified to apply to 'Any earlier version'.

It still doesn't upgrade properly. Here were my results:

1.0.0.0 -> 1.0.0.1: Recognized and ran upgrade. Upgraded existing to proper version.

1.0.0.0 -> 1.0.0.2: Did not recognize upgrade. Both versions ended up getting installed.
1.0.0.1 -> 1.0.0.2: Did not recognize upgrade. Both versions ended up getting installed.

1.0.0.0 -> 1.0.0.3: Did not recognize upgrade. Both versions ended up getting installed.
1.0.0.1 -> 1.0.0.3: Did not recognize upgrade. Both versions ended up getting installed.
1.0.0.2 -> 1.0.0.3: Recognized and ran upgrade. Upgraded existing to proper version.

It's like that ProgramCode is a point at which it just won't recognize it as the same program, regardless of the UpgradeCode. I also looked at the link you specified and played around with the other nodes in the version number. In those cases I also got mixed results, however I was never able to get earlier versions with different product codes to be recognized as upgrades (in some cases it would not prompt for the upgrade, but the end result was that it showed the correct version in Programs & Features - so I presume it uninstalled and reinstalled).

If you have any other suggestions, please let me know. Otherwise, do you know of any quality resources where I can read more in-depth about upgrades, versions, etc? I have visited a lot of sites but nothing I've found provide good details with examples.

Thanks again,
Scott
0 Kudos
chad_petersen
Level 9

Take a deep breathe, you are very close. This does work, really. I do it a LOT. I have newer MSIs remove older products that are not at all the same UpgradeCode and ProductCode family.

Upgrade is really a misnomer. It is going to uninstall the other older products and versions and install the newer one, not necessarily in that order. If it is not uninstalling the older stuff then make sure you have two things.

1. DetectOnly set to No

2. Version numbers that change in their first 3 nodes. MSI ignores the 4th version node for upgrades. You can read about this on the Internet in plenty of places. Here's one I like best since this is Microsoft saying it

https://msdn.microsoft.com/en-us/library/windows/desktop/aa370859(v=vs.85).aspx

Specifically it says:

Note that Windows Installer uses only the first three fields of the product version. If you include a fourth field in your product version, the installer ignores the fourth field.

Then start running with it writing out a verbose log file and see what it says around "FindRelatedProducts" and "RemoveExistingProducts". Also see that the PROPERTY you defined, whatever that name is, is in the LOG file showing the GUID of the product it found.

0 Kudos
chad_petersen
Level 9

If you did already ship all of those older versions and specified only a change in that fourth field then I can not offer you a solution. It doesn't work well like that. MSI definitely enforces starting off on the right foot.

Sorry, I thought you were talking about something hypothetical you had noticed and I thought these were not out in the wild yet. But, it sounds like they might have shipped like that.

Chad
0 Kudos
SMM-OSSI
Level 3

Take a deep breathe, you are very close
LOL! You sound like you know me. 🙂

I think that the version number is what I was missing. As soon as I tested with versions where one of the first three changed, it started doing an upgrade instead of installing both versions. However, there was still the issue of the upgrade message not popping up in these cases ('This setup will perform an upgrade of 'Application'. Do you want to continue?'). Do you know if there is a way to enable this message again? Again, it works when upgrading to alike product codes, but if the product code is different, and one of the first three version numbers changed, it does not display this message but does do the upgrade.

Any ideas on how to get that message back?

Thanks again,
Scott
0 Kudos