Why a Custom Action May Not Run
When it appears that a custom action in your install package or patch isn’t executing, you have to consider a couple of reasons. If the action has a condition in the Condition column of InstallUISequence table, the InstallExecuteSequence table, or any of the other sequence tables, the condition may have evaluated to False. In a verbose log you would see a line similar to the following.
MSI (s) (74:08) [10:05:28:015]: Skipping action: DDSE_CA_Uninstall_InstallExecuteSequenceStarts (condition is false)
Another common reason exists for binary custom actions: missing dependencies. When a binary custom action appears to work on your developer machine – and you really shouldn’t test on your developer machine unless you’re always changing the package code – but not on a test or client machine, this is likely the reason. If you find that setting the MsiBreak environment variable doesn’t prompt for a debugger, this only strengthens the case of missing dependencies.
Run depends.exe on your custom action server .dll file or .exe file on the machine where the custom action doesn’t appear to run. Missing dependencies will cause the dependency walker to display an error dialog, an error to be printed in the bottom message window, and a yellow question mark icon next to the missing dependency in the dependency navigation tree. Common missing dependencies are msvcr71.dll and msvcr80.dll – Visual C++ 7.1 and 8.0 runtimes, respectively – and pgort80.dll – a library linked into your executable when you instrument your project in Visual Studio 2005 for profile-guided optimizations. With missing implicit or forward dependencies, your executable cannot be loaded. You might instead consider statically linking what dependencies you can, such as the C runtime (CRT).
Another common mistake is when executable custom action servers depend on libraries to be installed, but the files haven’t actually been installed yet. Files are installed during InstallFinalize after InstallFiles has scheduled files to be installed via the installation script. You might consider scheduling InstallExecute or InstallExecuteAgain after InstallFiles if your immediate custom actions require that dependencies to be installed are actually installed first.