There seem to be two major types of upgrade situations out there. The first type is where a company truly wants their existing products to be upgraded to their newest product. In this case, an upgrade or patch installation is created.

The second type is where a company, for whatever reason, does not create upgrade installations for new versions of their products. When each new version comes out, they require users to uninstall any older versions first, then install the new version of their product. There could be many reasons why they do this. Sometimes, they just don’t have the installation experience in-house to create an upgrade installation. So, they require users to uninstall older versions before installing new ones.

If you are in the second type of upgrade scenario, and your intent was not to create an upgrade installation, then you may go nuts trying to figure out why it is happening. “Why, oh why, does InstallShield think I am doing an upgrade when I don’t want to do one?”

About this time you start to think that life is not fair, and if you can just make it through this situation, you’ll promise to be a better person in the future. But only IF you make it through this situation.

In the first upgrade scenario, you should consult the InstallShield Help and learn what Windows Installer codes you need to change for the upgrade you are creating.

In this second upgrade scenario, you should consult the InstallShield Help and learn the ramifications of changing Windows Installer codes when creating upgrades. I know you don’t think you are doing an upgrade installation, but you are going to have to look at this sometime. So, do it now.

If you are in the second type of situation, ask yourself if you did the following:

• You copied the previous installation project, let’s say for the 2009 version, and just changed the date in the strings to show 2010. However, you did not change the Product Version, the Product Code, the Upgrade Code, or the Package Code. InstallShield sees that one or more of the codes are the same, and it thinks you are doing an upgrade. This is not InstallShield’s fault. When you create an upgrade, you have to follow the rules for the specific type of upgrade you are doing, and change the Windows Installer codes (GUIDs) accordingly.

In consulting, I see this a lot. I’ve gotten several calls where a company is trying to create an installation for the new version of their product, and when they test the installer, InstallShield thinks it’s doing an upgrade. Often this is because the installation was created by one person who is no longer with the company, and a second, third, or fourth person is now working on the same installation project, trying to get it working for the new product. Installation projects have a way of getting passed around from person to person in a company. Nobody wants to be stuck doing them.

If the Windows Installer codes are not the culprit of your problem, another possibility is the ISPreventDowngrade custom action. Go to the Upgrades view and expand the Upgrade Windows Installer Setup node. This custom action is placed there by InstallShield in Basic MSI and InstallScript MSI projects.

ISPreventDowngrade prevents a person from installing an earlier version of a product over a later version of the same product. One cure would be to delete this custom action. You’d be surprised that a lot of problems go away when you do this. However, ISPreventDowngrade is there for a reason, so I don’t recommend deleting it unless you really know what you are doing.

Another possibility in the Upgrades view is that the original creator of the installation may have tried to do an upgrade, but couldn’t figure it out, so they just gave up. The result being that a half-configured upgrade is still in the Upgrades view. If so, that could be the cause of your problem.

Next time you have this type of problem, check the Windows Installer codes, and the Upgrades view. Between these two areas, you will probably find the culprit of your problem.

Be Sociable, Share!

•