Earlier today I was discussing with someone that I found out you can use a custom action in Visual Studio Setup projects to execute your own Installer classes that you would normally run using InstallUtil (which works great for a new project I am working on).
Said person suggested that I avoid custom actions at all costs though, stating that the moment you need to use custom actions you need to come up with your own solution and said that this is something that is recognised by many people and has been for a long time.
I have had a search around and can't find a single forum in which anyone has expressed concerns about this, and I just want to know if anyone knows of any reason why custom actions should not be used?
I want to ensure I'm using the most reliable solution possible in my new project, and this has given me some concerns about my current approach, however the person I was discussing it with couldn't give me an example of why it's a bad idea, so I just want confirmation as to whether what they said holds water or not.
I have a lot of reasons but it's a long and subjective conversation. Here are a couple links to get you started. In summary the thing to keep in mind is to maintain the declarative native of MSI ( author table data driven, transactional custom actions ) and work really, really hard to not introduce fragiltiy to your installer. Because of the design of InstallUtil / Installer class custom actions, they are simply a non-starter. Use WiX's DTF ( Deployment Tools Foundation ) managed custom action project types ( C# / VB.NET ) instead.
Managed Code CustomActions, no support on the way and here's why
Custom actions are (generally) an admission of failure
Note, for the first link, the "technical" portion is OBE due to the release of DTF. The strategic portion is somewhat optimistic IMO and discussed more in the second link. Here's also some background from my own blog: