Managed Custom Actions with Visual Studio 2010 and WiX 3.0

As covered by InfoQ earlier, WiX 3.0 will be shipping with Visual Studio 2010. WiX is much more flexible than the Visual Studio Setup Project currently available today and it supports managed code to interact with the Windows Installer. Authors can use C#, VB.NET or any other .NET programming language. This also enables debugging which has been a major pain point for installation creators.

By supporting managed Custom Actions (CA’s) using Deployment Tools Foundation (DTF) in WiX, developers no longer need to use C++ or scripting (VB Script or JavaScript) to author CA’s. DTF has a managed .NET wrapper on top of the msi.dll giving users access to the complete MSI API. A CA method in C# looks like this:

[CustomAction]
public static ActionResult CustomActionName(Session session)
{
...
}

The CustomAction attribute is used to tag the method as a CA. The Session object is what gives developers access to the Windows Installer API allowing them to query the MSI database, access properties etc. This is very similar to what you see in existing CA’s done by scripting or C++.

To use the above CA in WiX it will have to be registered in a WiX project:

<CustomAction Id="someID" BinaryKey="someKey" DllEntry="customActionName" Execute="immediate"  Return="check" />
<Binary Id="someKey" SourceFile="someCustomAction.CA.dll" />

Executing the CA in the UISequence can be done like this:

<InstallUISequence>
  <Custom Action="someID" After="CostFinalize" Overridable="yes">NOT Installed</Custom>
</InstallUISequence>

WiX 3.0 also provide a set of default actions which in reality are CA’s but available to all users of WiX. Some areas where default actions are available:

• IIS
• Com+
• MSMQ
• SQL

A complete list can be found in the WiX 3.0 documentation.

As an example, here’s the WiX source code needed to create a new web site in IIS:

<iis:WebSite Id='DefaultWebSite' Description='Default Web Site'>
  <iis:WebAddress Id='AllUnassigned' Port='80' />
</iis:WebSite>

Many have asked why the Windows Installer team does not support managed Custom Actions. Rob Mensching (Dev Lead on WiX) explains:

…a year ago I posted the outcome of the managed code Custom Action discussion I had with Carolyn (MSI Dev Manager) and a couple Windows architects. To sum up that blog entry they had two issues. First, the technical issue was that managed code Custom Actions needed to be run in a separate process. Second, the Windows platform has a strategic goal to reduce the number of Custom Actions.

When I posted that blog entry, DTF suffered from both issues. A month or so after the blog entry, Jason had addressed the technical issue by implementing the necessary interprocess communication mechanisms to move the managed code Custom Actions into a separate process but still be able to communicate with the Windows Installer.

InstallShield also has support for managed Custom Actions in their 2009 version, but they have a different solution where Rob’s two points above is not solved, and debugging is not possible. Christopher Painter explains why he thinks DTF is better:

1. DTF solves the problem of tatooing the msi process with a fixed version of the CLR.
2. MakeSfxCa is more flexible and intuitive when dependencies.
3. The MSI interop object model is simply better from a C# coders perspective.
4. The hosting process has an easy debugging story.
5. Being open source it's easier to see problems and get resolutions to issues even if that means doing it yourself.
6. There is no vendor lockin. You can build and consume custom actions in a variety of ways including integration with InstallShield. (That's the way I roll.)

WiX 3.0 are getting close to release. Currently there are some bugs that need to be fixed, and they are waiting for the Visual Studio team so they can start to integrate Votive (the Visual Studio add-on). The latest version 3.0.5006.0 can be downloaded from their weekly releases.