Run custom action of uninstalled application

Question

When performing an installation while there is already another version installed, we need to call a custom action that makes use of an exe of the old application (prior to it being removed). The custom action is responsible for removing an old scheduled task. How would one go about doing such a thing?

Answer 1

You can implement this in the upgrading installer.

The basic idea is you have a deferred custom action which will run only when WIX_UPGRADE_DETECTED property exists. This is set when you use the <MajorUpgrade> wix element in your product for upgrades. Then you can schedule your custom action before RemoveExistingProducts and it will be able to remove the scheduled task.

There are some caveats to this approach.

The first caveat is that this approach limits where you can schedule RemoveExistingProducts. You must schedule "afterInstallInitialize" or later.

If you do use "afterInstallInitialize" then scheduling your custom action Before="RemoveExistingProducts" will be fine. If you schedule RemoveExistingProducts later on in the install process you will probably need to shcedule your custom action Before="InstallFiles" in case the old exe or a file it might load is replaced by the new install.

A basic implementation of this might look something like this

<MajorUpgrade Schedule="afterInstallInitialize" DowngradeErrorMessage="A newer version of [ProductName] is already installed."/>

<CustomAction Id="CA_RemoveScheduledTask" BinaryKey="CustomActionsDLL" DllEntry="RemoveScheduledTask" Execute="deferred" Return="check" />

<InstallExecuteSequence>
    <Custom Action="CA_RemoveScheduledTask" Before="RemoveExistingProducts">WIX_UPGRADE_DETECTED</Custom>
</InstallExecuteSequence>

You may also need to pass in the install location to the custom action which can be access using the session's CustomActionData property. An example of how to do this can be seen here. This is just so you have the correct path for the exe location. Usually I get the install path via a registry key search.

Answer 2

There are at least two approaches that could be used longer term, because it's not normal to want to run a custom in another installed product.

1. If this executable is needed in both installs then it's a shared resource, and the executable and the custom action could be common to both installs (perhaps in a merge module to keep sharing properly).

2. It seems that the condition on calling the custom action in the older install might be incorrect if it's supposed to be called sometime during an upgrade or uninstall. For example, if it should be called when it's being uninstalled as part of an upgrade then condition the call on UPGRADINGPRODUCTCODE.