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.

Here is a picture of our LiveManage solution in Visual Studio. On the right, you can see the two installer projects: LiveManageInstaller and LiveManageSharepoint. The sharepoint installer is what is released to customers. The client installer (LiveManageInstaller) is embedded as a file in the sharepoint (LiveManageSharepoint) installer. I will go into details about this later, but a couple things to notice is that the installer projects are part of our product solution. This concept helps with the realization that the installer needs to be developed along with the product.

Dependencies

Again, since the installers are a project within a Visual Studio solution. The project dependencies can be easily set up to build all the product binaries first, then the installers. Since we have two installers, the dependencies between them are just a matter of a checkbox. The developer can build the installers as easily as building code.

Configuration

The configuration can be particularly useful. For the most basic of uses, you can create a debug, and release version of the installer. The debug installer would contain the debug version of DLLs, EXEs,… in order to help developers track down product issues. To include the debug or release versions of files in the installer, the Candle tab has a ‘Define constants’ section. I defined a variable named Build. (See arrow in Visual Studio picture). This compile time definition allows me change the location of the files to include within my WiX components. In my debug version, $(var.Build) will be replaced with my “Build=” value. Therefore, for debug configurations, it will pick up the LmCoreSv.dll in the debug directory, and for the release configuration, it will pick up the release version.

<Component Id=”LmCoreSv.dll”
   Guid=”FD36C532-643A-4347-AF50-AC6404A2AFF6″>
   <File Id=”LmCoreSv.dll” Name=”LmCoreSv.dll” 
      KeyPath=”yes” 
      Source=”$(var.BinariesLoc)$(var.Build)\LmCoreSv.dll” />
</Component>  

Using these type of configuration settings, you can see how custom configurations can be easier with WiX then other installer products.

This can be very handy for branding installers for particular customers. We have a couple customers that will redistribute the product under their own brand. Changing the install GUI banners can also be set by defining a compile definition. In the localization file, I override the banners with our own banners.

<WixLocalization Culture=”en-us” …
    <String Id=”AdvancedWelcomeEulaDlgBannerBitmap”
            Overridable=”yes”>LM_Bmp_Banner</String>
    <String Id=”BrowseDlgBannerBitmap”
            Overridable=”yes”>LM_Bmp_Banner</String>
    <String Id=”CustomizeDlgBannerBitmap”
            Overridable=”yes”>LM_Bmp_Banner</String>

Then I set the location of the banners, based on the definition of the variable ‘Branding’. So, looking back at the Visual Studio picture, our Eval Release configuration has ‘Branding=Tranxition’. When compiled, the result will be the inclusion of the TranxitionUpperBanner.bmp in the place of the default upper banner for the installation screen.

<Binary Id=”LM_Bmp_Banner”
    SourceFile=”$(sys.SOURCEFILEDIR)$(var.Branding)UpperBanner.bmp”/>

In addition to changing file locations, WiX provides if/then/else functionality. In the sample below, I can skip the inclusion of the FileRestore.ocx into the installer for the Evaluation version of the product. You should avoid having too many of these littered throughout your WiX scripts, but this works well if you currently have to create a new installer projects for each slightly different installer.

<?if $(var.Configuration) != “Eval” ?>
    <!—-Eval build does not include the File restore component–>
    <Component Id=”FileRestore.ocx”
               Guid=”F7E0CDA7-E16C-4667-A728-F43C9E8C29A7″>
         >>various component data<<
    </Component>
<?endif?>

This article just gives a taste of how WiX can be used to produce easy customizations of your installers. My next article will detail ways of integrating your WiX projects in your nightly build process.