Search code examples
windows-installeruninstallationcustom-action

What Should the Sequence Position be for a Custom Action Type 18 for Uninstalls?

Where in the InstallExecuteSequence table sequence should a Custom Action Type 18 (execute an app that is part of the installation) be placed so that it only runs during the uninstall because the "REMOVE="ALL" or an "Installed" condition has been applied to it - so it doesn't get deleted before running?

Solution

  • WiX Mock-Up

    What tool do you use? Here is a quick WiX snippet:

    Synchronous, deferred execution in system context, ignore exit code, run on all types of uninstalls (also major upgrade uninstalls) and running before the RemoveFiles Action:

    <CustomAction Id="RunExeUninstall" FileKey="notepad.exe" ExeCommand="" 
              Return="ignore" Execute="deferred" Impersonate="no" />

<...>

<InstallExecuteSequence>
   <Custom Action="RunExeUninstall" Before="RemoveFiles">REMOVE="ALL"</Custom>
</InstallExecuteSequence>

    Orca: The above should yield something like this in the CustomAction table when viewed with Orca:

    | Action: RunExeUninstall | Type: 3154 | Source: Filename.exe | Target: |

    Some CA Details

    Generally before the standard action RemoveFiles and running synchronously - so that the EXE custom action thread needs to complete before the setup's main thread can continue (or the main tread will likely uninstall the files before you are done in your EXE CA).

    I normally set error processing to ignore exit code for uninstall custom actions (or rollback could kick in unexpectedly - putting your install back on the box by undoing the uninstall - making the setup un-uninstallable and possibly un-upgradable as well - minor upgrades should still work, but major upgrades can fail).

    Does this custom action make changes to the system? (as opposed to just checking or logging something). Then it should have a corresponding rollback custom action, inserted prior in the sequence to your main custom action, undoing its changes if the setup is aborted manually (when you ignore exit code, the CA itself should not trigger rollback, but the setup can still be cancelled manually by the user, or by other CAs that check exit code - or some runtime failure not related to your custom actions - out of disk space, disc errors, etc...).

    If you make changes to per-machine locations (unwriteable for standard users) you need to run with elevated rights (deferred execution in system context).

    There are many pitfalls here. Note that rollback can be disabled by policy or property - causing rollback and commit custom actions to never run. I'll add some links at the bottom.

    Some Links (very good):