So you’ve created an upgrade item with InstallShield (mine is 11.5), you’ve set everything up right as far as you can tell, and when you run in to upgrade a previous version, the installer pops up the “Modify/Repair/Uninstall” screen of the old version
Aha! You say. Forgot to change the Package code. So a GUID Generate and rebuild later, you try again and this time get this:
You got the Package Code different, Upgrade and Product Code the same in the two versions, and you’ve got a Major Upgrade item setup and configured to recognize the proper Old version number range.
What’s up?
Come to find out, the IS help is a little confused on this topic. When you create a MAJOR UPGRADE to your installation (which, if my experience is any indication, almost EVERY upgrade is a major upgrade), you need to change both the Product Code and the Package Code! But here’s the trick, the Upgrade Code stays the same.
Why? Because appearently, a Major Upgrade is considered an entirely new Product, even though it’s not, because you intend it to upgrade older versions of the product.
But MSI doesn’t use the Product Code for that, it uses the Upgrade Code for that purpose.
So, basic rule is:
When you create a new Version of your app’s installation with InstallShield (or any MSI based Installer, I suspect), be sure to:
- Make sure you have an Upgrade Item setup to recognize the proper version range
- Make sure you generate a NEW PACKAGE CODE guid
- Make sure you generate a NEW PRODUCT CODE guid
- Make sure you DO NOT modify the UPGRADE CODE guid (basically, you almost never modify the Upgrade Code guid)
- Kneel before the holy altar and make an offering to the MSI gods.
Here’s a handy table from a Macrovision support site article that also might help. Basically, it illustrates when a particular code needs to be changed (the X’s), based on what kind of upgrade the new version of your install is.
| Update Type | Package Code | Product Version | Product Code | Upgrade Code |
|---|---|---|---|---|
| Minor Upgrade without Patching | X | |||
| Minor Upgrade with Patch | X | X | ||
| Major Upgrade | X | X | X |
You know, I whipped out an install in InnoSetup in, like, 5 minutes. And it’s free.
16 Comments
Oooooh, Installshield. I hates it I does, with a hideous white-hot passion. Not the product so much as the Suits that have subverted the place.
I used Express for years, and was moderately satisfied. Then I wanted to upgrade to the next edition, and discovered there was no direct upgrade path — neither to the new Express or to Installshield. I was told I had to buy the whole thing from scratch, as if I was a new user.
Bah, I said. I remember that day clearly. I distintctly said "Bah".
Then I went and downloaded Inno and built a new installation script in, like you said, a few minutes.
INF-Tool is also quite nice, though it looks & acts terribly dated. But gosh darn it makes small / fast installers that simply *work*. I think I paid $99 for the pro version of INF-Tool, since the free one didn’t give me enough bells and whistles.
Then there is something to be said for self-installing executables. I have a few projects where I simply bundled up the .OCX controls I needed in a resource file, unpack them during the first run of the .EXE, and register them myself using DLLRegisterServer. One customer was so freaked out by not needing an installer that I simply build a wrapper around the thing that copied the .EXE into the desired folder then invoked it. I think they call those "batch files". 🙂
Hi Ralf
Hehe. Funny you mention "self installing" executables. I’ve got a rant or two about that, to be sure! My stand on installers has pretty much always been "the smaller the footprint, the better." Probably comes from years and years of being in the commercial product development space.
Depending on the app, you may or may not be able to get away with it, but, no installer beats any installer hands down.
I investigated an app called Thinstall ages ago, when it was basically a one man shop. Very impressive stuff. Looks like he’s now into the Application Virtualization arena, which is hot right now.
That thing could literally turn a very complicated installation into a single-EXE runnable app that needed no install! Even if you were using things like MSXML and the ADO libraries and had to include them in your installation. It basically created a virtual machine around your application.
Very cool. And freakin’ $$$$!
Heh. I’m not advocating the all-in-one EXE approach for everything.
But it seems silly to fire up Installshield to deploy one .EXE and two tiny .OCX controls. The installer engine adds more overhead than the size of the binaries combined! So for these projects I do the DLLRegserver thing.
What’s an installer buy you anyway? Convenience? Control? It’s certainly not performance nor space-savings… the stuff Installshield turns out is bloated. And what the heck is it doing when it’s "preparing to install"? Defragging my harddrive? 90 seconds of wild thrashing so I can click "I Accept" on the license agreement? Even Winzip works faster than that.
Yeah, it’s probably the guy who configured the particular setup. He included everything he thought I might need, including DirectX9 and all the ADO service packs back to Office 2000 (beta) JUST IN CASE. In several languages.
I rant. But ranting’s fun. 🙂