WiX References: Ready for “Real” Development?
NOTE: The following article assumes familiarity with C#, Visual Studio Team System 2008, and Windows Installer XML (WiX) 3.0 tools.
It was going so well. There I was happily creating an installer for an upcoming product release related to Commerce Server 2007, when all-of-a-sudden "bam". The WiX compiler (called Candle.exe) threw a compile-time exception: "CNDL001: Item has already been added…". The problem? Turns out I have two projects with the same name in my solution – albeit in different subfolders. And, as is often done with build scenarios to maintain project references that apply both in the developers’ IDE (Visual Studio Team System 2008) and on the build server, I’m using WiX variables in the form of $(var.Common.TargetDir), where Common is the name given to both projects in question.
After hunting up and down through all the Internet and all the pertinent forums and the WiX-users mail list I found myself scanning many an article concerning reference errors using the linker (Light.exe) or the decompiler (Dark.exe) – but nothing related to Candle. Yet I’m surprised; solutions can have project names that are identical – particularly if they’re large. Ours isn’t particularly large, but the phrase "Common" is being used to refer to a couple of namespaces, and it seems appropriate for the assemblies in question. Encountering this has thus got me wondering if WiX has any other surprises that may come along down the road to derail either the tools, architecture or approach being used to generate the installers for our wonderful new product. It is a beta, although one derived from an already-stable product (WiX 2.0).
You may ask – "why use a beta open-source product"? Well, at this point the subject installer is a prototype. But even so, the reality is that there’s a lot of other strengths WiX offers, at least on paper. Admittedly, I’m still a bit of a noob with WiX too and perhaps one of the forum readers will be able to offer some constructive advice. But WiX’s .wxs files are simply XML files that, among other things, get translated into parameters of Candle.exe on the command-line (e.g. candle.exe -dDebug -d"DevEnvDir=… -dCommon.ProjectPath=D:\Projects\MyProjectName\etc\Common.csproj"), and the command-line generator appears to not offer any way to differentiate between projects of the same name. In fact, it may be technically wrong to blame WiX itself for this, since we could simply drop to the command-line ourselves and/or script the directives so that the WiX variable "Common.*" isn’t used more than once, but this creates issues for automated builds using WiX 3.0, what was once called ‘WiX Votive’ in concert with Microsoft Team Foundation Server and Visual Studio Team System 2008.
More to come on this in the days ahead…