View Full Version : Major release attempted downgrade

10-31-2005, 07:25 PM
I have a situation where we released a dot-1 version. Eventually Dot-2 will come along (as a full install major release--different ProductCode, same UpgradeCode). If you install Dot-2 first, then later install Dot-1...it will install. Windows Installer will currently allow this.

A new, second ARP item will exist (same name), but no files will be replaced because they contain earlier versions and/or modification dates (luckily). I suppose custom App Registry values could change...(no good).

The Upgrade table exists within both installations...and properly contains the VersionMax value. I guess I don't understand how this can occur. Is there anything that I can do to prevent a major release downgrade (ie: Dot-1 over Dot-2)??

10-31-2005, 10:55 PM
Preventing an Old Package from Installing Over a Newer Version, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/preventing_an_old_package_from_installing_over_a_newer_version.asp

I wish that I had known about this before we released Dot-1. Anyone have any ideas on how I can prevent an old package from installing over a newer version...and it's too late to alter the old package?

11-01-2005, 05:22 AM
When a product is uninstalled through a major upgrade (by RemoveExistingProducts), a property is set: UPGRADINGPRODUCTCODE. I believe this property contains the ProductCode of the new version.

Your newer version could check if UPGRADINGPRODUCTCODE contains the 'rogue' product code, then raise an error.

11-01-2005, 12:17 PM
I checked (via testing with verbose logging), and the UPGRADINGPRODUCTCODE property doesn't exist, upon installating the Dot-1 over the Dot-2. I also found that I have 3 files inadvertently set to: 'always overwrite'...so the Dot-1 downgrade replaces these files.

2 Questions;
1.) How to stop the Dot-1 downgrade
2.) If it can't be done, how to set the files within Dot-2 and beyond, so that they are not ovewritten by a downgrade?

I'm getting desperate. Maybe within all future releases I can set a Registry value somewhere, that contains the Dot-1 ProductCode...so that when Dot-1 runs it senses that it exists already and quits...any ideas?

11-01-2005, 01:11 PM
My mistake, I thought that v1 was doing a major upgrade over v2: you can stop that by failing inside the v2 uninstall.

But when no uninstall takes place, you need to figure out another way to generate an error during install. For instance, if v1 has a launch condition, v2 might change the system in a way that this condition is never met. Hundreds of errors exist, so you've got plenty to choose from.

11-01-2005, 01:19 PM
Only one LaunchCondition...OS related.

11-02-2005, 04:40 AM
What about this method for enforcing an error:

Create a new, empty, project with the SAME ProductCode as v1, but a DIFFERENT PackageCode. Your v2 (and every further version) installs this package as a child install.

Now, when the user attempts to install v1, he should get an error message like "Another version of this product is already installed".

If this is the case, you should do a lot of work to make this approach fully work:
* Remove ARP listing of child product
* Handle uninstall of parent product (child should be uninstalled so user can install v1)
* Handle rollback
* Handle Admin sequence
* Check upgrading of v2

Not an easy job though...

11-02-2005, 02:10 PM
That would be a Minor or Small upgrade, requiring REINSTALLMODE='vomus' (caching the new install and replacing) to be included on the commandline. The problem with doing a Minor or Small upgrade via a full install (not a patch) is that it cannot work for both a clean full install and/or an upgrade. REINSTALLMODE should always = 'omus' upon a new install, which must be set before msiexec is launched.

This is too bad...the only safe method of providing a CD that can be a full install and an upgrade is to make the upgrade a major.

11-02-2005, 02:45 PM
Your intention is to prevent installation of v1 after installation of v2, or did I misunderstand your question?

If you want to prevent a downgrade even when v1 itself does not prevent this: v2 install should install something, so that when the user attempts to install v1, he gets an error. That something (which is a child install with same product code) should enforce an error.

You can also create a child install with same product code and same package code, in that case Windows Installer will not start the v1 setup, but the v2 child setup instead. The v2 child setup can then show an error.