Is there a way to control the uninstall order? I have 5 packages and let's say they are installed in order 1-5. I want to uninstall them in reverse order... 5-1 (or at least uninstall package 1 last). But the suite seems to uninstall in the same order as it installs. Is there a way to do what I need? If not, I may have to just not allow Remove and force the user to uninstall the 5 packages individually from ARP 😞
Hmm. This gets sticky. I think current behavior is a top-down processing of the packages, either installing, removing, or ignoring each package as it goes. While the case you describe is an obvious case (reverse the order if removing), where should removals be scheduled with regards to other installs in a maintenance?
I wonder if we can just do a reverse-order of all uninstalls, followed by a forward-order of all installs, or if there are cases where this would need to be overridden.
Michael, Yes, if we can just do a reverse-order of all uninstalls I think that would go a long way for me. I think I will not allow Modify/Repair from the suite. The user can do that in ARP in those few cases.
Can we make 'reverse-order of all uninstalls' happen? Thanks
I'm still trying to come up with a few concrete scenarios where this matters, so if you've got one, please describe it here.
The "best" concrete example I have is the .NET framework needs to be present for another package to work with the GAC. But that's a pretty bad example because no one installation should remove the framework. Got anything better?
I have a Support package that gets installed first. I would prefer to have it uninstalled last because when it is uninstalled it: 1. Removes our entry that we added to the Path environment variable. 2. Removes registry keys.
If anyone started a removal process and it was aborted after uninstalling the Support package, all the other packages would still be there but would not work correctly. Removing Support last makes for a more orderly removal.
Hmm, for this particular case I wonder if you could just make two similar copies of this package, one up front for installation, and one at the end for uninstallation. (By for X I mean only specify that operation so it won't do anything in the other case.)
Hmm. I wonder if this case is a bug in the plugin .msi files - how are you supposed to uninstall the plugin if you can't reinstall the main product? But that said, this is good feedback and I'm adding it to IOA-000066885.
At plugin uninstall the costing fails beacuse the main package has already been removed.
If they were removed in reverse-order to installation then it would not fail
I have an issue very similar to this. My current custom C#-based Install Wizard (which serves the same purpose as the Suite style project) takes care of uninstall order, but we want to get away from customized code like that. Glad someone has already requested this functionality. :cool:
Michael, Looks like there is enough interest to do 'Reverse Order Uninstall'. Will this be in the next release? You know what my next question will be 🙂
I'm adding my vote to get the Suites uninstall order reversed or even better made configurable.
The reason is that our Suite installs several 3rd party components we depend on first (JRE, Apache, Tomcat etc), then runs our MSI that also adds files and makes configuration changes to them etc. During the Suite uninstall, the 3rd party components are removed first and then our uninstall fails when it wants to 'un-do' the customization changes because the apps are already gone.
I can work around it by just not removing the customizations, but it's not ideal since I would like them to get reversed when we for example upgrade our MSI, but not touch the 3rd party content.
