custom uninstall for app
Working with a Microsoft Outlook 2007 plug-in called Salesforce Connect. I've created an MSI using Wise Package Studio 7's Setup Capture. The program's default uninstall behavior leaves behind a number of directories and registry entries that I'd like to remove.
My first try at tackling this to do the following:
- use WiseScript Package Editor to create my own uninstall exe
- edit the original installation package so it copies my custom uninstall exe to the target PC
- edit the original installation package so the HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall registry key points to my uninstall exe
But when I run the uninstall from Add/Remove Programs, it's uninstalling the program using the old registry value and not running my custom-made uninstall exe.
Haven't attempted to do this sort of thing before, so am I going about it the wrong way? Do I need to edit my MSI and add custom actions to achieve my goal?
My first try at tackling this to do the following:
- use WiseScript Package Editor to create my own uninstall exe
- edit the original installation package so it copies my custom uninstall exe to the target PC
- edit the original installation package so the HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall registry key points to my uninstall exe
But when I run the uninstall from Add/Remove Programs, it's uninstalling the program using the old registry value and not running my custom-made uninstall exe.
Haven't attempted to do this sort of thing before, so am I going about it the wrong way? Do I need to edit my MSI and add custom actions to achieve my goal?
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
pjgeutjens
12 years ago
Hi Ron,
I must be missing something here... you're saying you made an MSI and are building a custom uninstall.exe for the final cleanup operation. I would suggest incorporating the necessary cleanup operations in the MSI, be it using the RemoveFile and/or Registry table, or even conditioned CA's if you wish, and uninstalling with a regular msiexec /X
Rgds,
PJ
I must be missing something here... you're saying you made an MSI and are building a custom uninstall.exe for the final cleanup operation. I would suggest incorporating the necessary cleanup operations in the MSI, be it using the RemoveFile and/or Registry table, or even conditioned CA's if you wish, and uninstalling with a regular msiexec /X
Rgds,
PJ
Posted by:
RonW
12 years ago
PJ, you weren't missing anything. I tried your suggestions and have it all working (after going to Google multiple times and flailing around just a bit), so many thanks for the advice.
Just have one question related to best practices.
I'm removing any folder the app leaves behind under C:\Documents and Settings, and am accomplishing that with a VBScript that I'm running via a Custom Action.
I currently have the Custom Action sequenced in the "Execute Immediate" table, with a property of REMOVE~="ALL", and have placed this immediately prior to the "RemoveFolders" Standard Action in the MSI.
I'm not super-familiar yet with running custom actions, so does that sound correct? The two things that are a mystery to me are where to place the action in the installation sequence, and which area I should include it in (I'm using Wise Package Studio 8, by the way): User Interface, Execute Immediate, or Execute Deferred.
Just have one question related to best practices.
I'm removing any folder the app leaves behind under C:\Documents and Settings, and am accomplishing that with a VBScript that I'm running via a Custom Action.
I currently have the Custom Action sequenced in the "Execute Immediate" table, with a property of REMOVE~="ALL", and have placed this immediately prior to the "RemoveFolders" Standard Action in the MSI.
I'm not super-familiar yet with running custom actions, so does that sound correct? The two things that are a mystery to me are where to place the action in the installation sequence, and which area I should include it in (I'm using Wise Package Studio 8, by the way): User Interface, Execute Immediate, or Execute Deferred.
Posted by:
cygan
12 years ago
for your vbs to work
use the binary table(type 6)
condition should be REMOVE="ALL" sequence after installvalidate
use the binary table(type 6)
condition should be REMOVE="ALL" sequence after installvalidate
Posted by:
pjgeutjens
12 years ago
Personally I would schedule this action "late" in install immediate, ie after InstallFinalise, or in Deferred as one of the last actions.
this way you allow Windows Installer to do its full uninstall during the Deferred sequence, and then afterwards (anything in InstallImmediate after InstallFinalise gets run after the deferred stuff) you run your script for the final cleanup. Since all the actions that actually change anything get run in Deferred, the MSI will already have run through the removefiles, removeregistry and similar actions...
To be complete in this, it is generally considered to be bad form to put any actions that have a physical impact on the machine in the Immediate Sequence, hence the alternative of scheduling late in Deferred.
PJ
this way you allow Windows Installer to do its full uninstall during the Deferred sequence, and then afterwards (anything in InstallImmediate after InstallFinalise gets run after the deferred stuff) you run your script for the final cleanup. Since all the actions that actually change anything get run in Deferred, the MSI will already have run through the removefiles, removeregistry and similar actions...
To be complete in this, it is generally considered to be bad form to put any actions that have a physical impact on the machine in the Immediate Sequence, hence the alternative of scheduling late in Deferred.
PJ
Posted by:
anonymous_9363
12 years ago
am I going about it the wrong wayYes. As Pieter said in his first response, the accepted way is to use the RemoveFile and RemoveRegistry tables. No faffing with sequences, user versus system context, blah, blah, blah - it just works.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.