WiX v2 nearing completion

I was reading on Rob Mensching's blog that WiX v2 is nearing it's final release. Congratulations Rob! He went on to talk about some of the remaining bugs to be stomped out when this little bit caught my attention:

The CustomActions have always been more work to implement, debug and fix. It isn't just that they are written in C++ (the rest of the WiX toolset is written in C#) but the problems being solved in the CustomActions are harder. Creating actions that participate properly in a compensating transaction takes a lot of effort. The effort that pays off once we get it right because no one ever has to write it again. Developers can write a couple lines of declarative statements and have a transacted installation process.

This in a nutshell touches on the core principals of Windows Installer:

Transactional Data Driven Installation Patterns implemented by built-in Standard Actions and Extensible by Custom Actions.

Standard Actions... The kool-aid that takes awhile to swallow until you like the taste. I'll admit it, I did script based installs for years before I converted to MSI and I didn't particularly think that MSI was the right way to go back in 1999. I remember a youthful version of myself working at Robbins-Gioia having a disagreement with a fellow developer ( I wish I could remember your last name Zhao ) over this subject. He felt MSI was the way to go and I felt that it was just another example of Microsoft taking over another industry and not trusting me to write a proper install. It took being offered a position in Enterprise Engineering with Continental Airlines to realize just how problematic `bad installs` were out in the production environment and that MSI really had a leg up in terms of respect with technology directors responsible for tens of thousands of computers spread all over the world.

After being forced to drink the kool-aid, I eventually learned to appreciate developing with components that accelerate development with less plumbing, increased reliability and decreased testing. However there were still times when the patterns simply don't meet all of your needs and this is where Custom Actions come into play. But wait, I'm not talking about those quick and dirty Custom Actions that we have all written over the years. You know, the ugly ones that we all first start out writing like a Script CA that self registers and starts an C++ ATL service because we can't get the COM and Service patterns to work. These types of Custom Actions are the ones that made the Windows Installer team cringe in fear at the very thought of extending the API with the ability to run user code. I'm talking about the kind of robust, bulletproof Custom Actions ( I call them Quasi-Standard Actions or Enterprise Framework CustomActions) that strictly adhere to the design guidelines that Standard Actions follow. The kind that Rob was talking about.

In case your not familiar with WiX, the CustomActions he's referring to deals with WiX's ability to install websites and read/write XML files. Basically WiX has a way in it's schema to describe these resources and then transform them into custom tables that get processed by C++ Type 1 Custom Actions. ( As an aside, I noticed that these patterns are not directly supported in the configuration views of WiXAware yet.) Done properly they are every bit as good as standard actions. If you use InstallShield you've probably noticed that Macrovision does pretty much the same thing. The reality is very few of us have the skill or free time to implement these correctly. This is why we so often settle for 80% solutions that take 20% of the time to implement. We understand the risks, accept them and move on to solve other problems. But it IS really nice when your tools have invested the time to be nearly 100% solutions that only take 1% of the time to implement. After all this is why we drank the kool-aid in the first place.

Ok, now it's time for me to take off my Microsoft fanboy hat and give a couple loving Marine Corps 1-2 back jabs:

Windows Installer is failing to keep up with today's modern use cases.

Windows Installer is failing to keep up with modern programming languages.

Let's face it. Modern programming languages such as .NET have been obsoleting the registry and INI files with XML config files. The widespread adoption of n-Tier architectures have spread the use of IIS for ASP.NET websites and web services. While it's great that WiX and InstallShield are implementing these patterns, the job should really be done by the Windows Installer team directly in the API as standard actions and tables. As for Rob's comment about it not just being that the custom actions are written in C++, I think he's understating that a little. The reality is modern programming languages such as CLR 2.0 with feature rich frameworks such as .NET 2.0 make programming a breeze when compared to C++ with MFC. MSI is really stuck in the stone age here. .NET has been out for a very long time and it even comes preinstalled with Server 2003 and Vista. It's also very common place on XP and even Windows 2000 machines. IMHO, It's really time for MSI and .NET to get with the program. MSI needs to embrace the use cases that .NET introduces and MSI needs to add the ability to create bulletproof custom actions using managed code. It's also time for .NET to get with the MSI program and play nicely within the well thought out principals of Windows Installer. Remember those ugly CA's that I talked about? That's what the framework seems to think setup is about when you look at alot of .NET classes such as the ServiceController and Installer classes.