0
votes

I am working on an MSI installer using installshield 2016. I am trying to add a custom action to the uninstall, that runs a tool before de-installation of the software. The tool is installed with the software and needs to run in administrator mode. The tool is intended to run some manual clean-up actions before de-installation starts.

I've added a custom action using the custom action wizard using "New EXE > Path referencing a directory". INSTALLDIR is defined in the directory table and contains the user-defined installation path. The name of the .exe and parameters are substitutes.

Working Directory: INSTALLDIR
File Name & Command Line: tool.exe /action parameter1 parameter2 parameter3
Return processing: Synchronous
In-Script execution: Deferred Execution in System Context
Execution schedulintg: Always execute
MSI type number: 3170
Run During Patch Uninstall: No
Install Exec Sequence: After AnotherCustomAction
Install Exec Condition:

Note: AnotherCustomAction is set to execute after InstallInitialize. It is very similar to this one, but executes properly.

(I know the install exec condition should ultimately be REMOVE="ALL", but I removed that at some point to be sure that wasn't causing problems)

The INSTALLDIR property is written to the registry during installation; I've added AppSearch and RegLocator entries to make sure it is read back.

I've run the installer with logging enabled, and I see the following:

MSI (s) (30:14) [13:57:19:162]: Executing op: ActionStart(Name=RunTool,,)
MSI (s) (30:14) [13:57:19:162]: Executing op: CustomActionSchedule(Action=RunTool,ActionType=3170,Source=C:\Installation Test\,Target=tool.exe /action parameter1 parameter2 parameter3,)
MSI (s) (30:14) [13:57:19:162]: Note: 1: 1721 2: RunTool 3: C:\Installation Test\ 4: tool.exe /action parameter1 parameter2 parameter3
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: RunTool, location: C:\Installation Test\, command: tool.exe /action parameter1 parameter2 parameter3

If I got to the folder C:\Installation Test\ and manually run tool.exe /action parameter1 parameter2 parameter3, everything works as its supposed to. At some point, someone suggested that maybe the problem is that there is a space in the installation path, but a new attempt with a path without spaces did not fix it.

Any idea what is going wrong here? Is this the right approach?

I can't provide the project itself (company policy) but I'll try to answer any additional questions you may have.

2
Where is AnotherCustomAction scheduled? Is this CA scheduled between InstallInitialize and InstallFinalize?Christopher Painter

2 Answers

0
votes

I only have experience with using InstallShield 2015, and have found custom actions to be a bit tricky at times, I actually just wanted to post this in comments (but my rep too low) for you to try rather than an answer so hopefully people won't downvote me too harshly if this doesn't work.

At first, have your return processing set to Synchronous (Ignore exit code), then even though you may specify the correct folder, try setting the path explicitly in Filename and command, and surround your filename and arguments separately in quotes.

Example:

Working Directory: INSTALLDIR

File Name & Command Line: "[INSTALLDIR]tool.exe" "/action" "parameter1" "parameter2" "parameter3"

I've not used MSI type 3170, but have used this for types 1122, 1058, and 1250.

As Christopher mentioned you will also want to look into scheduling, but wrapping in quotes shouldn't hurt.

Best of luck.

0
votes

The most likely issue is that you are running the CA unimpersonated so that it is elevated. This means that it is running with the System account, so the failure is probably associated with running with this account instead of from the shell in interactive user context. As System, it won't have access to any meaningful user locations (such as Desktop folder and others, HKCU) and cannot interact with the interactive user's desktop (for security reasons, same as system services not allowing interact with desktop). It won't have a working directory (because the default is set by explorer and that's not how you are running), and it won't have network access. Basically you need to run your code with the system account and see the failure points, or maybe you'll see something from that list in your code.