tags:

views:

178

answers:

2

I'm writing a new major upgrade of our product. In my installer I start by finding configuration settings of the previous version, then I'd like to uninstall the previous version.

I have found several guides telling me how one should make a MSI suitable for such upgrades.

However, the previous was not an MSI.
It was not according to best practices.

It does, however, in registry HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{GUID} specify an UninstallString.

Using a RegistrySearch I can easy find the command below, which I store in UNINSTALL_CMD.

RunDll32 C:\PROGRA~1\COMMON~1\INSTAL~1\PROFES~1\RunTime\10\01\Intel32\Ctor.dll,LaunchSetup 
    "C:\Program Files\InstallShield Installation Information\{GUID}\setup.exe"
    -l0x9  -removeonly 4:  

I cannot get the hang of the CustomAction needed to perform the actual uninstall.

       <CustomAction Id="ca.UninstPrev" Property="UNINSTALL_CMD" ExeCommand="" />

The MSI logs says:
Info 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: ca.UninstallPrevious, location: RunDll32 C:\PROGRA~1\COMMON~1\INSTAL~1\PROFES~1\RunTime\10\01\Intel32\Ctor.dll,LaunchSetup "C:\Program Files\InstallShield Installation Information{GUID}\setup.exe" -l0x9 -removeonly, command:

Anyone seeing what I am doing wrong here?

Regards
Leif

+3  A: 

I did application repackaging for a couple years at Continental Airlines where I did SMS pushes to an 18,000 seat forest. I frequently had a legacy application in the wild that was not installed using MSI that I needed to get redeployed using MSI and once that was done I supported major upgrades going forward.

These previously deployed apps typically had very broken and misbehaved uninstallers. Instead of calling these, I would use SMS to query the forest to get all the deployed versions. I would then deploy those old packages to a integration lab and work out what it was each installer did to the machine and write my own aggregated "forced cleanup" custom action that was capable of wiping the various versions of the application off the machine.

I executed this custom action prior CostInitialize so that when the new MSI did it's costing it wouldn't be influenced by the crap that was no longer on the machine. This worked for me because I pushed packages as System and I didn't have to worry about elevation issues. If you want to be fully UAC compliant you would want to run this custom code from a prereq package and either have your users run it manually or wire it into a bootstrapper to run prior to your MSI.

Christopher Painter
+1  A: 

After a good nights sleep I found my error. If you really read http://wix.sourceforge.net/manual-wix3/wix_xsd_customaction.htm the answer was there.

I was trying to make a type 50 custom action, launch an executable already installed on system.

Property specifies the full path to an executable to launch

ExeCommand specifies the command line arguments for this executable above.

And my fault was that I did place the full exe+command line in the Property field.

/L

leiflundgren
Could you post the code that got this working for you?
JProgrammer