MSI nested installations
Has anyone else been creating MSI packages that call multiple MSI packages as nested installations? I have been successfully creating these 'MSI wrappers' to deal with the likes of vendor MSIs that contain more than one MSI.
What I have discovered is that although the nested MSI files appear in the Add/Remove programs, they cannot be uninstalled individually. The only way to remove them is to uninstall the 'parent' MSI that put them there in the first place. This is fine as long as everything goes smoothly.
If, however, one of the nested MSI installations fails but the others complete then the Parent MSI also fails to install, but indoing so does not roll back the nested MSIs that it installed successfully. Since these nested MSIs were installed by the parent, they cannot be removed individually as previously stated (to rectify the machine to its previous state). Therefore, the only way to remove them is to get the parent wrapper to reinstall completely successfully to then uninstall it again.
My question is - is there a way around this anomoly? Do i need to modify my MSI wrappers in such a way that if any of the nested MSI installations fail then it will roll back cleanly uninstalling the ones that did install successfully. If there is not a way to do this (or as an alternative) - is there a way to forcably uninstall an MSI that was installed via a nested installation without needing its parent MSI that called it?
What I have for each nested MSI is a custom action that installs it and a custom action that uninstalls it. Then I sequence the Install custom actions to run during an install (using the condition NOT Installed) and I sequence the Uninstall custom actions to run during an uninstall (using the condition REMOVE=ALL). This works perfectly as long as all the nested MSIs themselves install and uninstall successfully.
I think what I need to do is add another condition so that if any of the Install custom actions fail, then all of the Uninstall custom actions are run - thus with the net effect of rolling everything back.
Am I thinking along the right lines with what I've said above? Anyone have any other ideas/comments?
Hope I've described the problem clearly enough - failrly new area of MSI technology for me at the moment. Thanks
Alan
What I have discovered is that although the nested MSI files appear in the Add/Remove programs, they cannot be uninstalled individually. The only way to remove them is to uninstall the 'parent' MSI that put them there in the first place. This is fine as long as everything goes smoothly.
If, however, one of the nested MSI installations fails but the others complete then the Parent MSI also fails to install, but indoing so does not roll back the nested MSIs that it installed successfully. Since these nested MSIs were installed by the parent, they cannot be removed individually as previously stated (to rectify the machine to its previous state). Therefore, the only way to remove them is to get the parent wrapper to reinstall completely successfully to then uninstall it again.
My question is - is there a way around this anomoly? Do i need to modify my MSI wrappers in such a way that if any of the nested MSI installations fail then it will roll back cleanly uninstalling the ones that did install successfully. If there is not a way to do this (or as an alternative) - is there a way to forcably uninstall an MSI that was installed via a nested installation without needing its parent MSI that called it?
What I have for each nested MSI is a custom action that installs it and a custom action that uninstalls it. Then I sequence the Install custom actions to run during an install (using the condition NOT Installed) and I sequence the Uninstall custom actions to run during an uninstall (using the condition REMOVE=ALL). This works perfectly as long as all the nested MSIs themselves install and uninstall successfully.
I think what I need to do is add another condition so that if any of the Install custom actions fail, then all of the Uninstall custom actions are run - thus with the net effect of rolling everything back.
Am I thinking along the right lines with what I've said above? Anyone have any other ideas/comments?
Hope I've described the problem clearly enough - failrly new area of MSI technology for me at the moment. Thanks
Alan
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
ab2cv
19 years ago
I'm now thinking that Rollback custom actions might be the way to go - except that I cannot get these to work. The windows installer always complains of an unsupported CA type (error 2723)
Alternatively, I've also read that nested installs should rollback automatically on failure. The problem is, I can only get nested installs to work if I schedule them to run before InstallInitialize and I think that rollback logging only runs between InstallInitialize and InstallFinalize (where my nested installs refuse to run).
Alternatively, I've also read that nested installs should rollback automatically on failure. The problem is, I can only get nested installs to work if I schedule them to run before InstallInitialize and I think that rollback logging only runs between InstallInitialize and InstallFinalize (where my nested installs refuse to run).
Posted by:
ab2cv
19 years ago
ORIGINAL: oofemioo
Rollbacks must be explicitly included in Custom Actions.
Thanks for the response. Would you be able to expand a little on what you've said, as I'm no expert in this area?
Alan
Posted by:
ab2cv
19 years ago
OK, so I've had no luck getting Rollback custom actions to work, but I have found another way to solve my problem, so I thought I'd post my findings here.
I realised that if I sequence my nested installations to run somewhere inbetween InstallInitialize and InstallFinalize, then there would be a chance that they would be included as part of the rollback of the main MSI install. The best place I found to sequence them was between 6401 and 6599 (after publishproduct and just before installfinalize for a WinINSTALL created MSI). If I sequence my nested installs here, then what happens is, each MSI installation is validated in turn before commencing installation of the first one (ie. it skips through each of the MSI installations 'gathering required information' checking that there are no problems with each of the nested installs. If it finds a problem with one of them, then the whole installation is halted and none of them are installed. If they are all OK, then the installation continues starting with the first one in the sequence)
Alan
I realised that if I sequence my nested installations to run somewhere inbetween InstallInitialize and InstallFinalize, then there would be a chance that they would be included as part of the rollback of the main MSI install. The best place I found to sequence them was between 6401 and 6599 (after publishproduct and just before installfinalize for a WinINSTALL created MSI). If I sequence my nested installs here, then what happens is, each MSI installation is validated in turn before commencing installation of the first one (ie. it skips through each of the MSI installations 'gathering required information' checking that there are no problems with each of the nested installs. If it finds a problem with one of them, then the whole installation is halted and none of them are installed. If they are all OK, then the installation continues starting with the first one in the sequence)
Alan
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.