Downgrading using a major update
Posted 19 June 2003 - 20:57
* Install version 1.0.0 of a product
* Install version 2.0.0 of the same product (different product and package code)
This is a major upgrade and works fine. However, I thought that you can also use a major upgrade do to this (the upgrade table does not specify a max/min version):
* Install version 2.0.0 of a product
* Install version 1.0.0 of the same product (different product and package code)
This is also a major upgrade, the difference being that it is really a
"downgrade". I thought that this would work if I just put RemoveExistingProducts early enough in the installexecute sequence so there is no trace of the product when we get to reinstall. However, what happens in this case is that my "downversioned" main application exe is missing after installation.
It is as if the windows installer says: "I am not going to reinstall that old version of the application exe, even though I just removed the newer version". Is there any way to make this work? Maybe I can specify amus as reinstallmode instead of omus?
I suppose the implications of this are:
* Never install a "downgraded" file using a major update (probably the same with minor upgrades)
* Add a check to each installer that they are only allowed to upgrade "lower version numbers" (might be done automatically if you populate the upgrade table properly)
I like the idea of having my setup be able to "wipe out whatever exists" and then just install itself. It is not like most users have to downgrade, but then again I think that a file or two can "sneak into" your setup with a lower version number than what existed before, and then you are in trouble when using a major update.
Posted 20 June 2003 - 06:38
Is is possible that your install is not running an upgrade?
Check to see that the property that you are using in the upgade table is being set (either run with log mode, or add this property into the dialog and see what it is set to).
I really recoment running with log mode on, this should be able to tell you what windows installer is doing with the install/upgrade etc.
Posted 20 June 2003 - 10:09
CostFinalize determines which components should be installed. At this point, the newer version is still on the system. Therefore those components will not be marked for installation. However they will be removed during RemoveExistingProducts.
To me this looks like a bug or at least a short sighted design in MSI.
I don't think your solution of moving RemoveExistingProducts before CostFinalize is valid, for two reasons:
- On Win9X systems, CostFinalize will only run in the UI sequende, so RemoveExistingProducts will still be after CostFinalize, so I expect your downgrade will not work on 9X. On WinNT however CostFinalize will be executed in the UI sequence and again in the Execute sequence.
- The SDK states that RemoveExistingProducts must be sequences after InstallValidate, which in turn should be sequenced after CostFinalize. So your placement is against the docs, and I would not do that.
I don't have a nice solution for you. I see these options:
- Uninstall the existing version using a custom action. This would have to be in the UI sequence, so it will not work if your setup is run in silent mode.
- Change the component GUIDs and destination directories so that the existing files will not be referenced.
Posted 09 November 2005 - 17:48
Ive looked for a solution to this problem before and thought i saw a MS bugreport, but now I cannot find it anywhere.
Has this bug been solved in IS11 or the comming IS11.5 ?
Help is highly appreciated
Posted 10 November 2005 - 08:04
Posted 01 July 2011 - 11:33
|QUOTE (Stefan Krueger @ 2005-11-10 08:04)|
|It's not a bug in InstallShield but a problem in the Windows Installer engine. So only Microsoft would be able to fix it. But as far as I know they haven't (but I encourage you to contact them directly to verify it)|
I am using InstallShield 2008. Does anyone have any idea if this issue is fixed in MSI?
Posted 01 July 2011 - 12:21
In this situation, I'd use the client's deployment solution to uninstall the newer version before installing the older version. If there's no deployment solution in place, it's simple enough to build a wrapper around the uninstall/new (old? LOL) install.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.
Posted 07 July 2011 - 20:53
There is a "workaround" that I don't really want to recommend, but mention in passing. If you include the version number for the application in the application's installation directory - an action that is frowned upon by any good deployment specialist - you will be able to "decouple" the upgrade install and the existing install so that the CostFinalize action doesn't confuse the installation states of files. In essence you are making the INSTALLDIR a "moving target" and hence avoid CostFinalize identifying files as related at all. Not a good fix at all, but an acceptable workaround in cases where downgrading is essential (can't really think of a scenario where this is the case). Note that when you make the INSTALLDIR a moving target, this means that the absolute path to each file changes between upgrades. Accordingly you should change the GUID for all components with a keypath in the new path. This is because MSI is supposed to have a 1-to-1 mapping between a GUID and an absolute path across all releases. In practice this is not that important since major upgrades "wipe the slate clean", but in theory this is the correct way to do it.
My recommendation would be to author the upgrade table to ensure that there is "downgrade protection" in the MSI file. In other words that it will refuse to install over a higher version. This ensures that the uninstall of the prior version must be run separately before the "downgraded" setup can be installed.
Edited by Glytzhkof, 07 July 2011 - 20:56.
Posted 06 September 2011 - 20:19
Currenly, I am left with a partial installation (functional, but not what I would like), and two entries in the control panels installs. UPG code, the same, Product code and package code different.. version changes in the first 3 digits.
Interesting that it has been an issue for over 8 years. Is Microsoft listening?
Edited by ktbrownusa, 06 September 2011 - 20:28.