nathan.stark1.55249416640094E12 asked a question.
Two Programs, One Upgrade Code
Today, we migrated over to our new InstallShield 2009 installer. My company is new to InstallShield, so my understanding (as it is now my responsibility) of it is weak. Previously our program, which is in beta, has been distributed as a plain ol' MSI file. We decided that our next release would be instead be a Basic MSI project via IS9. After constructing it and testing it however, I've found a slight issue, which is more or less a fairly large problem.
Among other tests, I tried these 3 major conditions:
1) A fresh install using the IS9 installer
2) An upgrade install from the IS9 installer to an "upgrade" IS9 Installer
3) An upgrade install from our plain old MSI installer to the IS9 Installer
The first two went fine. The last one however resulted in the "upgrade" not being run. Instead, the normal IS9 setup was run. This resulted in two different installations of our program on the target machine. Between the MSI that was already installed, and the MSI contained in the IS9 installer, the differences were that the version had been updated, the product code changed, and the package code changed. The Upgrade code however is identical. During my work with plain MSI files, it was my understanding that two products installed with an MSI could not be installed at the same time if their Upgrade Code was the same.
So, what's going on here? Is my assumption wrong?
How do I get the IS9 installer to "Upgrade" or act as an update to the plain MSI file I've been distributing (and previously updating) to many clients already?
Thanks for the assistance
I *assume* it works the same here but obviously my assumptions are suspect.
If two products have different product codes but the same upgrade code, one can update the other if you teach the Upgrade table about the relationship. The Upgrades view in the InstallShield environment makes it easier to set this up.
There's an "Updating Applications" section of the online help that should clear some things up.
You really don't want to let any per-user installs slip out into the wild as servicing them is really hard ( impossible ).
The Upgrade Code stays constant between all releases of a code, while the product code changes per-version. Anything with an identical product code is treated as the same version, preventing any installation (and allowing uninstallation via product code) of the installed product. Anything with an identical Upgrade code can be installed again, but it acts as a replacement or update to the originally installed product. If this is a "major" or "minor" upgrade as far as MS is concerned, I don't know. But it does prevent it.
"
While an UpgradeCode typically never changes, A ProductCode may or may not change from version to version depending on if you want to service the upgrade as a Major Upgrade or a Minor Upgrade. The PackageCode changes EVERY build.
Don't Change the PackageCode and you get Maintenance UI experience.
(remaining examples assume changing PackageCode)
Change the ProductCode and you end up with a double install ( this is how multiple instance MSI works )
Change the ProductCode, wire up the Upgrade Table, change one of the first three fields of ProductVersion ( a.b.c.d ) and install in the same context ( per-machine or per-user ) and you end up with a Major Upgrade. Mess one of those up and you end up with the above double install.
Don't Change the ProductCode and you end up with a Minor Upgrade ( or small upgrade but there isn't much difference between those two. )