About Windows Installer, the .NET Framework, and Visual Studio.
Rob Mensching, father of Windows Installer XML (WiX), blogs about why managed custom actions are a bad idea. Aaron Stebner follows up by saying (and has said before):
How do you know what's natively supported? Those who know me already know what I'm going to say: read the docs. The Windows Installer SDK has some information if you look for it, and you certainly should because setup and servicing cannot be taken for granted. Windows Installer is complex, but a powerful transactional installer. To help disseminate some of this information since it can be sparse, there are a number of good blogs to read about rules, experiences, and guidelines:
There are other things you should do when writing custom actions, and I am working with people throughout the company to define guidelines. In general, besides what Aaron and Rob are saying – along with not using script custom actions – you should consider the following:
Log. I'll say it again: log. The Windows Installer engine is quite stable and well secured, so the closest thing available to a crash dump is a verbose log. When run on Windows Installer 3.0 and newer, you can also turn on debug logging. You can use the system Logging policy to set "voicewarmupx" (easy to remember), along with the Debug policy for extra information such as the ever-handy sequence dump which shows you all the information generated to sequence patches. You can also specify logging on the command line or bootstrap developers can call MsiEnableLog(). There are a lot of great posts about parsing and understanding Windows Installer logs.
Heath Stewart has posted an item on his blog that I wanted to link to here so that hopefully more setup
Windows Installer custom actions that launch executables (base custom action type msidbCustomActionTypeExe