advanced installer custom action action data

No need to further complicate an installer package that uses binary CAs by adding more binary CAs. Because the UILevel values of 2 through 5 probably aren’t the typical verbosity levels an application might accept, a CA might be necessary but you could just as easily use type 51 CAs to set a common property, conditioned on the UILevel, and use that common property in the command line arguments. The UILevel could also be passed directly to the command line to the EXE rather than requiring a DLL that alters the command line depending on what arguments your application accepts. It fails to document a common mitigation, exposed in WiX as CAQuietExec for example, of using a DLL CA to capture output from the process and putting that output into the Windows Installer log.

In several places it describes writing a DLL to launch the EXE and do whatever is required to mitigate a problem.

The analysis which the Windows Installer team posted isn’t complete when it comes to mitigations, however. You can read more about managed CAs from Rob Mensching and find more guidelines on my blog, which is a summary of what we use internally. Typically these EXE CAs are standalone configuration utility applications that are installed with the product or are managed EXEs where developing them as EXEs yields the benefit that the required CLR version can be loaded. How are they bad? Let the Windows Installer team count the ways.ĭuring internal audits we question any EXE custom actions (CAs) but inevitably some make it into the product. Windows Installer custom actions that launch executables (base custom action type msidbCustomActionTypeExe, 0x2) are typically bad and should be avoided.

Advanced installer custom action action data