Normally, when you want InstallShield to be able to perform a MAJOR UPGRADE on an install package, you have to change both the “package code” and the “product code”, and of course, the product version. However, you’ll normally leave the “Upgrade code” the same.
If you do this, InstallShield will install your new “version” as a new product, but it will also detect the existence of the previous version due to the Upgrade code, and force an uninstall of the previous version. I’ve actually blogged about this before here.
That’s exactly what I was expecting when I started testing the latest version of our package (and the first that was intended to support upgrades), and I was a bit surprised and perplexed when it popped up into maintenance mode of the previous version!
Somehow, I could start the install by dbl clicking on the MSI of the new version, but the maintenance mode of the previous, installed, version would get started?! What the hell?
I started digging through verbose logs, called Macrovision, the works, and nothing seemed to fix it.
Then, I happened to notice mention of a package code in the logs that I didn’t recognize. I checked my new version’s properties and the package code didn’t match what was in the log.
Where the heck was it getting this other package code from?
So, I did a search through the project and it turned up here, under the releases screen!
Turns out, at some point in the past, this package code had been set, which overrides the package code defined in the Summary Info Stream screen above, when I build this particular release.
Since package codes should normally change with each build, everything was getting screwed up.
I set the “Generate Package Code” option to Yes, and cleared the package code from the releases screen, recompiled and all was well.
I suppose this is an easy mistake to make, but it’s one that left me scratching my head for more than just a few minutes.