cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jaredfx
Level 4

Uninstall InstallScript install during MSI install

I've created a 'Basic MSI Project' with IS 2009 Premier for a new product which will be a replacement for an older product. The old product install was created using an 'InstallScript Project' with IS 11.2. The new install works great other than the fact that I need to uninstall the old product prior to installing the new one. How can I best accomplish this? I'm new to InstallShield, so any help would be appreciated. Thanks.
Labels (1)
0 Kudos
(3) Replies
mberterm
Level 7

Please see the help topics "Launching Executable Files" and "Creating the Response File".

Since Major Upgrades in the Upgrade view are used only to target existing MSI based packages, it may be easiest to use a custom action to call the uninstall of the existing InstallScript package.

For guidance, there are a couple of other threads that talk about this.

Perhaps in this type of scenario:
A. Add an entry in the 'System Search' view to look for something (ie, file or registry entry) specific to the previous package
B. Configure the search to merely place the results into a property
C. Add a 'launch EXE' custom action (see the help topic above).
D. The command to be executed is the uninstall command for your previous package (A convenient way of quickly finding that is to look through HKLM\Microsoft..\Software\CurrentVersion\Uninstall. Find your product's key and look to the 'uninstall string' data.)
E. Use the property from B. as the condition for the custom action of C.
F. Sequence the custom action somewhere between AppSearch and CostInitialize in the User Interface sequence, with the In-Script Exection property configured as 'Immediate Execution'.
0 Kudos
Sairen
Level 7

I'm just curious as to why you would put the uninstall of a previous application in the UI sequence. The dialog when you cancel an install assures the user that the system has not been modified, after all. My understanding of best practices is that any change that modifies the system should go into the Execute sequence as a deferred action. Even the major upgrade's RemoveExistingProducts action is at least in the Execute sequence. I'd be terribly put off by an installer that removed the old product before I'd even officially told it to install the new one.

Absolutely not saying you're wrong here, obviously, but I'm definitely wondering what I've missed, so thank you for clearing up my confusion!
0 Kudos
mberterm
Level 7

Sairen you are correct to point out some of the drawbacks and limitations--effectively hard coding a rigid approach.

There are always assumptions which may or may not work for a given customer or deployment scenario...

One possible assumption is that the installation of the new product will be completed successfully. Then the uninstallation of any existing product(s) should be done as early in (or even before) the installation process so as to make the target machine as 'clean' as possible. However, this may not provide for the best customer experience as in the case you mention; an aborted installation.

To improve the experience, you can include instructions for a manual process or additional dialogs with sufficient conditional logic in order to prompt, confirm and then execute the uninstallation.

In a controlled environment (eg, a corporate deployment) the choice is already made and know and many of the assumptions can likely be baked in.

It seems to me that in a retail/consumer environment it would be best to include as much information, documentation and conditional logic as is helpful.
0 Kudos