8 replies to this topic

[Glytzhkof]

I am trying the following:
* 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.

[luke_s]

You should be able to *upgrade* you install from version 2.0 to 1.0. This will only not work when the upgrade table is set to detect the versions that it will upgrade from.

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.

[Stefan Krueger]

Looks like what happens is this:

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.
  

[zazzo77]

Hi, Its been two years since this was posted so Im very hopefull that it has been solved. This is a big problem for us, our installation is about 600-700 files and cross sharing files left to right.

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

[Stefan Krueger]

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)

[unknown]

[VBScab]

IMV, there's nothing to fix.

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.

[Glytzhkof]

I agree with Stefan, this is a short sighted design from Microsoft. Major upgrades are integral to the operation of Windows Installer - in fact it is my preferred type of upgrades and I always try to avoid minor upgrades. When the CostFinalize standard action isn't really compatible with major upgrades of all types, I do think this is a design shortcoming of MSI.

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.

[ktbrownusa]

I'm running IS2011, and have found that the major upgrade doesn't downgrade very well. This all seems very odd that it is only one-directional. I have the major update doing a full uninstall of the application in both the first installation 1.0 and the upgrade 2.0. I would think if you went from 2.0 to 1.0, a complete uninstall would be preformed before the installation continues.

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?


Kevin

Edited by ktbrownusa, 06 September 2011 - 20:28.