I have a custom action that adds files to the installation directory. When the program is being uninstalled, another custom action tries to remove those files, so that the installation directory can be deleted.
The problem is that my custom uninstallation action runs after the removal of standard install files, so the installation directory is left there, although it's empty.
The config looks similar to this:
<CustomAction Id="AddFilesAction" BinaryKey="installerActions" DllEntry="AddFiles" Execute="deferred" Return="check" Impersonate="no" />
<CustomAction Id="CleanupAction" BinaryKey="installerActions" DllEntry="Cleanup" Execute="deferred" Return="check" Impersonate="no" />
<InstallExecuteSequence>
<Custom Action="CleanupAction" Before="InstallFiles">Installed</Custom>
<Custom Action="AddFilesAction" After="InstallFiles">NOT Installed</Custom>
</InstallExecuteSequence>
Can I make the CleanupAction
run before the msi starts removing installation files, so that the custom file is already removed and msi can remove the main installation dir?
The problem is that my custom uninstallation action runs after the removal of standard install files
That's because you have scheduled it before InstallFiles
, which comes after RemoveFiles
in a standard InstallExecuteSequence
. You can also open your MSI file in an editor like Orca or InstEd and have a look at the InstallExecuteSequence
table. Sort it by the Sequence
column to see the order of execution.
Can I make the CleanupAction run before the msi starts removing
installation files
Sure, just schedule it before RemoveFiles
:
<Custom Action="CleanupAction" Before="RemoveFiles">
(REMOVE~="ALL") AND (NOT UPGRADINGPRODUCTCODE)
</Custom>
Edit: I have also improved the custom action condition after Stein Åsmul made me aware of it. See his answer for the detailed reasoning.
In case you don't already know, WiX already has support for removing application-generated files which may be able to replace your custom action. It comes in the form of the RemoveFile
and util:RemoveFolderEx
elements.
In case these don't fulfill your needs, so you still need a custom action, I suggest to add temporary records for the files to be removed to the RemoveFile
table at runtime (in an immediate custom action!). This gives you the benefits of using the MSI engine for the actual file removal, i. e. automatic rollback if the user decides to cancel the uninstallation or when an error happens. I have done so in the past (before RemoveFolderEx
was invented), so if you need more information, just ask another question.
Short Answer: Your condition and sequencing seems to be wrong. Please schedule your cleanup custom action to run before RemoveFiles
and maybe set a better condition to make the action run only when desired (not in unexpected setup modes). Below I suggest (REMOVE~="ALL") AND (NOT UPGRADINGPRODUCTCODE)
. If you use this condition, please test thoroughly. This condition is explained below.
Quick Sample:
<InstallExecuteSequence>
<Custom Action="CleanupAction"
Before="RemoveFiles">(REMOVE~="ALL") AND (NOT UPGRADINGPRODUCTCODE)</Custom>
</InstallExecuteSequence>
Please be sure to read the details below as well. You might also want to tighten the condition for your copy files action - since it otherwise will run on major upgrade as well - which may or may not be what you want.
Custom Action Alteratives: Please avoid custom actions if you can - summary of some custom action problems - they are serious). Custom actions are the leading cause of deployment failure. Are you sure you need them? Very often there are other ways to achive what you implement in custom actions using built-in MSI features or WiX-specific constructs. Common examples are: installing services, deleting files, updating XML files or INI files, etc... Sometimes custom actions are necessary though - obviously. Zett42 has already written well about the alternatives, so I won't repeat it here - please check his / her answer.
RemoveFiles: There are further problems here - and I will try to describe these below - but files are uninstalled when the standard action RemoveFiles
runs. In other words you need to schedule the cleanup custom action to run before this standard action in the InstallExecuteSequence
.
Condition: Your condition Installed
for your cleanup custom action will make the custom action run on modify
, repair
and minor upgrade patching
in addition to uninstall
and major upgrade initiated uninstalls
. This is most likely not what you want. To specify to run on uninstall only, the most run-of-the-mill condition is REMOVE~="ALL"
. This will make the cleanup happen on a manually initiated uninstall and also on a major upgrade initiated uninstall (not what you want I think). You could try (REMOVE~="ALL") AND (NOT UPGRADINGPRODUCTCODE)
(run only on regular uninstall - not on major upgrade uninstalls).
Tips: Conditions are very easy to mess up - even for experienced WiX / MSI users. Some resources that might help:
- Common MSI Conditions Cheat Sheet (from Installshield, hotlink to actual PDF)
- How to add a WiX custom action that happens only on uninstall (via MSI)? (useful overview, a few hiccups or hard-to-explain details - especially relating to the
REMOVE
property - but in general OK as an overview and crash course)
Some Further Links (for reference):
- Wix Tools update uses old custom actions (some odd conditions analyzed)
- WIX Installer: Prevent installation on Windows Server 2012 R2 (You can use VBScript during debugging to analyze a condition at runtime - is it true at this point in the sequence, or not? - can be very effective for testing and debugging - the proof is in the pudding - sample towards bottom: "Property Debugger Demo" - and a newer sample here with actual code)
- Is it possible to run a custom action only in repair mode
- http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Conditions-for-Uninstall-Remove-Only-td4834010.html
I would not schedule your actions between InstallInitialize and InstallFinalize. Place your files before Initialize and cleanup your files after Finalize. Beware that you will lose your property values after InstallFinalize and you'll need to account for that.