This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Uninstalling MSI from installation of another MSI
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 22, 2013
06:44 AM
Uninstalling MSI from installation of another MSI
I want to uninstall a lower version of a MSI while installing newer version. The problem here is that the newer MSI cannot perform an Upgrade as the older MSI has a custom action to that doesn't allow it to be uninstalled using Upgrades. Hence, I wrote a simple script to uninstall it: msiexec /x {Product Code} /qn
Now, when I include this script in a Custom Action of the newer MSI, it throws an error saying that Another program is being installed. Please wait until that installation is complete, and then try installing this software again
As a workaround for this, I did the following things:
1) Run the custom action in UI sequence, after Cost Finalize. But this wont work in case of silent installations.
2) When the custom action is run in Asynchronous mode, the 2 processes (viz., installation of newer MSI and uninstallation of older MSI) run independent of each other and it may happen that newer installer may finish installation first and then older will be uninstalled. This is also not expected.
Please advice as to what can be done in this case.
Thanks in advance,
Shodhan
Now, when I include this script in a Custom Action of the newer MSI, it throws an error saying that Another program is being installed. Please wait until that installation is complete, and then try installing this software again
As a workaround for this, I did the following things:
1) Run the custom action in UI sequence, after Cost Finalize. But this wont work in case of silent installations.
2) When the custom action is run in Asynchronous mode, the 2 processes (viz., installation of newer MSI and uninstallation of older MSI) run independent of each other and it may happen that newer installer may finish installation first and then older will be uninstalled. This is also not expected.
Please advice as to what can be done in this case.
Thanks in advance,
Shodhan
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 22, 2013
07:50 AM
I have not had to fix an older msi that will not uninstall yet, but my understanding is that the recommended best practice to resolving broken Major Upgrade:
1) Create a new build of the same version of the 'old' MSI correcting the problem, typically by disabling the CA that is causing the problem.
2) Deploy this new build of the old msi by updating the cached package on the user's machine, using msiexec /fv
3) Then you can deploy a 'new version' of the msi as a Major Upgrade, without hitting the uninstall problem.
I think it is common to wrap steps 2 and 3 in a bootstrapper.
1) Create a new build of the same version of the 'old' MSI correcting the problem, typically by disabling the CA that is causing the problem.
2) Deploy this new build of the old msi by updating the cached package on the user's machine, using msiexec /fv
3) Then you can deploy a 'new version' of the msi as a Major Upgrade, without hitting the uninstall problem.
I think it is common to wrap steps 2 and 3 in a bootstrapper.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 01, 2013
01:02 AM
Thanks for replying. The older MSI isn't broken, its just that a CA in it runs during uninstallation, that doesn't allow any higher versioned MSI (of same Upgrade code) to uninstall it. That's why major upgrade fails.
Your steps 1 to 3 would help, no doubt, but, if we make another build of the old msi, we'll have to run 2 MSIs (the newly built older one and the newer one). But we just need to run the newer msi and it should take care of uninstallation of older MSI.
As of now, we are running batch script to uninstall older MSI separately and then installing the newer MSI. I am looking for a something that I would do in the newer MSI itself that would take care of uninstall.
Your steps 1 to 3 would help, no doubt, but, if we make another build of the old msi, we'll have to run 2 MSIs (the newly built older one and the newer one). But we just need to run the newer msi and it should take care of uninstallation of older MSI.
As of now, we are running batch script to uninstall older MSI separately and then installing the newer MSI. I am looking for a something that I would do in the newer MSI itself that would take care of uninstall.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 01, 2013
09:45 AM
I did not mean to disparage your old MSI by using the term 'broken' to refer to your problem statement "as the older MSI has a custom action to that doesn't allow it to be uninstalled using Upgrades". When an old MSI has a behavior that prevents it from being updated the approach that I described of creating and applying a transform to the old MSI to first, to change its behavior, and then apply your new MSI, is the approach which various MSI 'expert' bloggers have recommended.
(I have seen this infor in several places, among others see: http://www.robertdickau.com/msi_tips.html)
I suspect that most folks would rather avoid this approach, as it is painful. Something else to consider in your new MSI, and certainly preferable to the above, is where do you have RemoveExistingProducts scheduled in your new MSI? If you make sure that it is scheduled after InstallValidate ( and prior to InstallExecute) then the upgrade behaviour should be similar to completly removing the old product first and then installing the new product.
(I have seen this infor in several places, among others see: http://www.robertdickau.com/msi_tips.html)
I suspect that most folks would rather avoid this approach, as it is painful. Something else to consider in your new MSI, and certainly preferable to the above, is where do you have RemoveExistingProducts scheduled in your new MSI? If you make sure that it is scheduled after InstallValidate ( and prior to InstallExecute) then the upgrade behaviour should be similar to completly removing the old product first and then installing the new product.
