Installshield 10.5 Prevent Downgrade

Hi!
Keep product code always the same.

Change package code if You wan't to install different version:

Here are some reading from these codes from Windows Installer help files:

Package Codes
The package code is a GUID identifying a particular Windows Installer package. The package code associates an .msi file with an application or product and can also be used for the verification of sources. The product and package codes are not interchangeable. For details, see Product Codes.


No two nonidentical .msi files should ever have the same package code. It is important to change the package code because it is the primary identifier used by the installer to search for and validate the correct package for a given installation. If a package is changed without changing the package code, the installer may not use the newer package if both are still accessible to the installer.

The package code is stored in the Revision Number Summary Property of the Summary Information Stream. Note that letters in product code and package code GUIDs must be uppercase. Utilities such as GUIDGEN generate GUIDs containing lowercase letters. The lowercase letters in these GUIDs must be changed to uppercase to be used as a product code or package code.

Although it is common to ship an application that has the same package code and product code, the two values can diverge as the application is updated. For example, including a new file with the application would require updating the installation database to install the file. If the changes are minor a developer may choose not to change the product code, however, a different .msi file is needed to install the new file and so the package code must be incremented. Conversely, a single package can be used to install more than one product. For example, the installation of a package without a language transform could install the English version of the application and the installation of the same package with a language transform could install the French version. The transform is distinct from the .msi file that determines the package code. The English and French versions could have different product codes and the same package code because they are both installed with the same .msi file.


Send comments about this topic to Microsoft
***************

Product Codes
The product code is a GUID that is the principal identification of an application or product. For more information, see the ProductCode property. If significant changes are made to a product then the product code should also be changed to reflect this. It is not however a requirement that the product code be changed if the changes to the product are relatively minor.


The 32-bit and 64-bit versions of an application's package must have different product codes. If any 32-bit component of an application is recompiled into a 64-bit component, a new product code must be assigned.

If a server exposed in the PublishComponent Table is recompiled from 32-bits to 64-bits, the GUID in this table may also need to be changed so that 32-bit and 64-bit clients can identify the appropriate qualified component category. In this case, the product code must also be changed.

Note that letters in product code GUIDs must be uppercase. Utilities such as GUIDGEN generate GUIDs containing lowercase letters. The lowercase letters in these GUIDs must be changed to uppercase to be used as a product code or package code. For more information, see Changing the Product Code.

The package code is a GUID identifying a particular Windows Installer package. The package code associates an .msi file with an application or product and can also be used for the verification of sources. The product and package codes are not interchangeable. No two nonidentical .msi files should ever have the same package code. Although it is common to ship an application that has the same package code and product code, the two values can diverge as the application is updated. For more information, see ProductCode.

**********
Send comments about this topic to Microsoft

UpgradeCode Property
The UpgradeCode property is a GUID representing a related set of products. The UpgradeCode is used in the Upgrade Table to search for related versions of the product that are already installed.
This property is used by the RegisterProduct action.

Remarks

It is strongly recommended that authors of installation packages specify an UpgradeCode for their application.

**********

Regards!
Matti

The simplest way to make it work without changing too much of the way you do things now would be to have each version that gets installed make a registry entry with it's version somewhere under HKLM.  Then write a quick custom action that does version checks of the already installed version vs the one being installed.  If the one being installed is less, punt out of the install.

This is of course, just the 'quickest' way I can think of and by no means is saying that the above post is incorrect in the way you 'should' version your products.  But we all know that in the real world what matters is that it works when we want it to work.  If you want any help on checking the registry etc, please feel free to post here and I can track down some examples.

Hi and thanks for the replies..

@Matti:
Your post is correct and I already know all that but unfortunately it doesnt help with my issue. The choice of changing the product code or not merely affects whether the new installation will behave as a minor or major upgrade. I need to keep my current functionality which performs a major upgrade every time.

@jmcmunn:
Actually, this is more or less what I am already doing, with the only difference that I am checking the previous version directly from the executable rather than the registry. This works fine at the moment but I am still interested in finding the "proper" way. I am sure Installshield retrieves the existing product's information at some point. There has to be a way to access them..

Well, normally Installshield will prevent older versions from installing over simply by checking a flag for the 'maximum' and 'minimum' versions that an upgrade can actually uninstall/reinstall.  If you know ahead of time what the version of each of your major upgrades will be then you should be able to set the maximum version to match itself.  Does that make sense in your scenario?

This would effectively keep any given install from reinstalling itself over anything newer than itself.

This doesnt work either.
It still installs normally and replaces the files with the ones in the older version setup.
The only difference from before is that now I have 2 entries in the Add/Remove programs.

That's because of the change in product/package codes.  If it truly is a different 'product' Windows Installer is going to go ahead and install it.

So if you truly require new codes as you are doing now, you'll have to stick with what works, and not worry about the 'correct' way to do it.  In Installshield's mind the 'correct' way would be different management of the GUIDS for product/package/upgrade codes I'm certain.  But since you can handle the major upgrades with your own logic, seems fine to me unless you ever needs some sort of Windows validation or something.

Yeah, well thats true. However we had faced random problems in the past when trying to perform an upgrade without changing the Product Code and we are following the Major upgrade policy ever since so its not likely to change this atm..

Either way, we have derailed from my original question which was about a way to retrieve the version of the old installation through installscript or any other means. It would be usefull if there was a way to do that.