Question About Upgrading Chained Installers

[Telemak]

Hello, I observe problems with a major upgrade in the following scenario:

1. I add a simplest Chained App MSI Package (created as Basic MSI ) to the simplest Main App (created as Basic MSI with MSI 4.5 prerequisite).

This setup can be sucessfully installed on Windows XP SP2 test system.

2. Then I create a major upgrade of the Main App without changing anything in the chained MSI package. If I attempt to perform a major upgrade on the test system, the setup fails. Also changing PackageCode and version of the chained package and rebuilding the major upgrade of Main App does not solve the problem. Only if a chained installation is unistalled prior to performing a major upgrade, the setup gets accomplished successfully.

3. If I create a major upgrade of the chained installer and add this new msi (with a new product code) to the Main App installer, everything works correctly: the setup runs without problems and both appplications are upgraded.

I have verified this behavior with simplest installers using IS 2009 and 2010.

I have attached 2 installation log files created for the failed and successful installations. As can be seen in the failedsetup.log, the main app installer detects that the chained applciation with the same product code is installed and does not attempt to reinstall the chained installer. On the other hand, in case of sucessful setup the chained installer gets upgraded along with the main installer, if the product code of the chained installer differs from the one associated with the major upgrade.

Can anybody explain the cause of the problem and suggest the method of its resolution?

Thanks very much in advance!

[MichaelU]

It sounds like the problem has to do with the major upgrade removal of MAIN_v1 as part of MAIN_v2's install. Namely the default chained package removal condition will fire in this case, and remove CHAIN_v1. Now exactly what scenario results from this can depend on what other conditions you have, but generally you're between two main problem cases: MAIN_v2 thinks CHAIN_v1 is already installed so it doesn't, or the transaction started from MAIN_v2 may be unable to both uninstall and (re)install CHAIN_v1.

I think for your case I might recommend changing the remove condition for CHAIN_v1 (in MAIN_v1 and later) to include "... AND Not UPGRADINGPRODUCTCODE". You can then add an auxiliary chained package to the first MAIN_vX that needs to upgrade CHAIN_v1 and keep it around; so long as its install condition is false, it will never need the v1 source files. Its remove condition can optionally condition against the upgrade action property for previous MAIN_vX versions.

[Telemak]

Hello Michael,

Thank you for your preliminary analysis and the valuable suggestion to modify the remove condition by adding "... AND Not UPGRADINGPRODUCTCODE". This modification indeed allows for upgrading the main installer when the chained installer was not modified. I also checked the scenario with upgrading both installers with this condition and your method allowed for performing the "double major upgrade" as well without making any additional modifications in the main installer.

Yet, I would like to pose some questions in this respect:

1.Does the failure of the main setup in the major upgrade scenario described in my previous post occur due to a bug in the ISChainPackage... CAs implementation or one can find some references about its cause in the MSI documentation?
Why does the install log file not contain the explicit error reference?

2. Do you think that the suggested method of adding "...AND Not UPGRADINGPRODUCTCODE" to the remove condition should be added to the documentation or mentioned in an InstallShield KB article on chained installers?

3. It appears that ISChainPackage fails when it needs to uninstall CHAIN_v1 (along with MAIN_v1) in the MAIN_v1 -> MAIN_v2 upgrade scenario and then install CHAIN_v1(or CHAIN_v1.1 with the same ProductCode) integrated into the MAIN_v2 installer. If the ProductCode of the chained installer changes, everything works fine. Do you think the same problem would occur if one populates MSIEmbeddedChainer and associated MSI tables instead of ISChainPackage/Data tables or this problem is indeed specific to the population of ISChain... tables and implementation of ISChain... custom actions?

Thank you very much in advance for your reply!

[MichaelU]

I'm glad this handling of the conditions appears to work for your needs. One other approach to consider, if your CHAIN_v1 is really a third party dependency sort of thing, is to only install it (clear the Remove condition). Then either it will major upgrade itself later when you install CHAIN_v2, or you can add an empty remove chain for v1 when you add an install chain for v2. A third option may be to use a prerequisite instead, as those don't handle removals at all.

Re 1: Looking at the log, it appears that ISChainPackagePrepare schedules the removal, but then does not schedule the install because it believes the chained package is already (still?) installed. It's not an error but the result is about the same. I'm not certain what the full implications of major upgrade removals' multiple execution sequences are with regards to chaining, so I can't fully explain this one yet.

Re 2: I do think documenting this would be a reasonable addition to our KB, but I don't think it's necessarily a good default as the maintenance of this scenario is more intricate. The existing defaults work well for a locked-step major ugprade of, e.g., a productivity suite that's chained across several MSI files, and the changed one would potentially have problems. (If you depend on individual items in the suite upgrading their counterparts, skipping an MSI in the new suite might not remove the old one.)

Re 3: In my opinion there's no reasonable way to populate the MsiEmbeddedChainer tables other than a solution like ours. I'm not yet sure whether that could be tweaked to better handle this scenario. This is mostly because while one person may be very careful to handle several-package major upgrades in one way, another person will handle them differently. Each approach requires slightly different conditions or other handling, and has different failure modes when switching to another approach after the first package set has been released.

[Matthias1967]

Is there also a dependency on the positioning of RemoveExistingProducts?

I recently found that a Major Upgrade for the "Main" package works only if RemoveExistingProducts is scheduled before InstallInitialize. Is this a known issue, or may something have gone wrong from my side?

Regards

Matthias

[Tim_Mayert]

Hello,

I do not know if this is exactly the same issue as us, but we are running into a failure during a Major Upgrade of a Chain as well.

We have 5 main apps in our chain. 2 of these app installers (.msi) have removal conditions on them that will not allow them to uninstall if any dependency apps still exist on the system. So our original chain will install and uninstall these apps in the correct order. This works fine, but now we created a major upgrade that has the main chain as well as all chained .msi projects major upgrades.

So we are appling this major upgrade install over the original version and it fails because it tries running the first chained install in major upgrade mode and it will fail because of the uninstall condition if anything still exists. I know this was not that great to add to the installer, but we were not thinking correctly.....

Anyways we thought that the Major Upgrade of the main Chain would actually uninstall all products it installed first before installing all chained products that are built in to it. Is this what it is suppose to do???

In the log it shows the following command line:
MSI (s) (B0!68) [10:01:19:387]: PROPERTY CHANGE: Adding IS_CHAINER_POST_COMMANDLINE property. Its value is '/qb /x{9D81615E-B150-488B-90CA-1159E2113BE3} /qb /x{3ABF6865-E84E-4DAB-B730-0EB9E8F37EB1} /qb /x{ED0FF410-41B9-441F-B457-4AC81782E8BF} /qb /x{67E6410C-1E97-4D03-BEC2-8E83323A6BBD} /qb /x{0E5DD7A3-BE29-430C-970B-C553F4A58C39}'.

These are the correct product codes for the products installed and in the correct uninstall order, but this does not seem to get triggered.

So Again is a major upgrade of a chain suppose to uninstall everything it installed first before installing the chained products or is it suppose to simply uninstall it self, then reinstall it self and trigger the installs of the chained installer. At this point if they are major upgrades then they simply handle themselves???

If this is the case then I have to figure out how to get those 2 main products that do not uninstall to be uninstalled....

Thanks for any insight into Chained Major Upgrades...