April 29, 2008

You Can't Escape .NET

There is a reason that the experts are all unanimously saying that managed custom actions are a bad idea. You are free to ignore all that accumulated expertise but it doesn't seem like a wise thing to do.

The conversation of Managed Code Custom Actions once again came up on the WiX-Users list and naturally the thought police were out in full force faithfully enforcing the will of their Master, Rob Mensching. Rich's comment is my personal favorite. Has he really polled EVERY Windows Installer Expert or is he just taking the opinion of a few vocal experts who happen to work for Microsoft as settled law? I know many of the experts that I speak to are in favor of Managed Code CA's as are (currently) 72% of my readers who have voted on the topic.

This question isn't a dead horse, it's an 800lb Gorilla that will not go away, will not be ignored and will not keep quite. Managed Code is the future of Windows development and it's time MSIrecognizes that 100% declarative is a great goal but it will never succeed and that writing tomes of C++ code is not what developers expect in 2008. Thank God InstallShield feels differently.

And just so I know I'm not loosing my mind, here is the opinion of GreenAJ as expressed on the WiX-Users list:

I have head people preach diligently about the evil of managed custom actions.

Let me just say a few things. Often we need tools such as SMO to better configure a database and the "in-box" custom action in Wix don't do quite what you need. In some of the installs I have worked on, I need to migrate old databases, Restore, Detach, Attach, run very large batch scripts, hook into the batches to echo "Print" SQL statements to the MSI logs.

Also, setting up a Web Service in IIS7 is unsupported.

In comes .NET in a Custom Action to the rescue. This logic can now be coded in a more affordable way than vast tomes of C++.

What I have font to work greatly is to use a Unmanaged C++ harness to load .NET assemblies and run the custom action logic. The C++ harness uses the unmanaged .NET API for setting up the app domain and firing off the .NET code in the assembly. All the .NET code is run as a DLL custom action. NOTE: These are not the "Installer Components" that leave their carcasses in the installed product. They are simple extracted in the install, ran, and then deleted (the DLLs are loaded by the unmanaged C++ in another App Domain so they can be chucked).

1 comment:

I think that the MSI folks also need to come to grips with another hard realization... today's installation developers are not all developers. I for one come from a scripting background, and found my niche developing installers because these days a lot of focus is spent on solid distribution methods and installations development has by and large been my full-time job for a year and a half now.

What this means that I can script just fine, and I can put together MSIs and InstallScript installers, but I don't know C++. People who do know it don't want to be writing installers. So for me, being able to write a CA in C# is by far a better option than learning a very complicated language that I won't actually use that much.