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?
0 Comments   [ + ] Show Comments


Please log in to comment

Community Chosen Answer

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


Answered 09/22/2011 by: pjgeutjens
Red Belt

Please log in to comment
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.


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.
Answered 09/26/2011 by: RonW
Third Degree Blue Belt

Please log in to comment
for your vbs to work

use the binary table(type 6)
condition should be REMOVE="ALL" sequence after installvalidate
Answered 09/26/2011 by: cygan
Fifth Degree Brown Belt

Please log in to comment
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.

Answered 09/27/2011 by: pjgeutjens
Red Belt

Please log in to comment
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.
Answered 09/27/2011 by: VBScab
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity