A custom task for building WiX under MSBuild (TFS)

My name is Shawn (Hempel) and this is my first submission to the Tranxcoder blog, which is a little ironic since I think it was my idea in the first place. Nonetheless, at least now I am officially “on the board” (and the team can stop razzing me about not posting.)

It seems I’ll be continuing on a running theme of writing about making Team Foundation Server work for us in new and scary ways. If you’re wondering why so much of our blog has centered on that topic, I think it’s two parts: 1) in many ways TFS customization is neither easy or intuitive so as we struggle to make things work, we want to share that with the development community; and 2) since our build process has little to do with the logic in our products, it’s easy to put this stuff out here without worrying about giving away intellectual property. That said, there will probably be more non-build related content as time goes on – we’ll just change variable names to protect the innocent. Alright, on to the good stuff…

As previously mentioned by Richard, we use the WiX toolset to generate Windows Installer binaries (MSI/MSM) for our applications. Personally, I find the recent builds of Votive (WiX’s Visual Studio integration package) to be quite helpful and easy to work with. One of the things it does very well is enable a simple F5 installer build. What it does not do, however, is help you in any way once you decide to graduate from building on the desktop to incorporating an installer build in your TFS processes. Specifically, there will almost certainly be some trouble with the relative and/or absolute paths used in your WiX source files to locate the build outputs to package. Read on to find out how we first solved that problem in a way that made it hard to sleep at night, and subsequently replaced it with a robust, maintainable solution.

WiX, MSBuild, and Build Verification, Part 1

Probably the least thought about, and planned for process in the development cycle is the installer. Since few projects get completed early, time for a well planned installation takes a back seat to the main development effort. However, we’ve all heard over and over that the customer’s first impression of your product will be your installer. At Tranxition, we were given the time to research the various installation products currently available, and decided to with WiX for a number of reasons.

Why WiX?

WiX has a couple great advantages. It integrates seamlessly with Visual Studio. This means it can be included in our nightly build process simply by including our installation projects into our Visual Studio solution. It produces an .msi file, allowing our installer to work on all Windows versions we need to support. Also, we get the installer repair and uninstall options for free. Speaking of getting things for free… WiX is free. Yes, a free open source Microsoft originated project.

You say nothing is ever free? That is somewhat true, there are some disadvantages. Documentation is scarce, you will depend heavily on blogs to learn the product, and figure out your issues. As an open source product, it has bugs (that so far I’ve been able to work around), but some times I’ve had to go back to an older installation, or needed to manually edit the project files. However, we have multiple configuration of our final product, seven different released products. The differences are mainly to the installer GUI, differing help files, and a couple customer specific DLLs. WiX works beautifully with these different configurations, and we don’t need to create a separate project per installer.

Over the next few months, I will detail our WiX installation scripts and configuration, the integration of our WiX projects into our MSBuild process, along with our build verification process. This first article, I will describe our installers, our build configurations, how we use the project configuration to create each of our product releases, and why this might help you decided to also use WiX.