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
- :
- Uninstall InstallScript install during MSI install
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
‎Oct 23, 2008
09:24 AM
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.
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 04, 2008
08:03 PM
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'.
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'.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 05, 2008
09:58 AM
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!
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!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 05, 2008
01:06 PM
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.
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.