I have this multi-project solution in Visual Studio 2013 and one of the projects is a Windows Installer project. It uses WiX (Windows Installer XML) 3.8 and when I rebuild the solution, the final result is a nice .MSI file that will install the executable bits from the other projects.
To get the files that need to be bundled with the installer, I copy the files that I need from the project bin folders to a folder in the WiX project named “files”. This folder is not part of the project or the solution and is not in source control. I started out with a prebuild event of the WIX project that did the following:
- Delete the files folder. I just assume that everything in the folder is obsolete
- Robocopy the deployable files from a WPF project to the files folder.
- Robocopy an ASP.Net MVC 4 project to the filles folder
- Run ctt.exe (Config Transformation Tool) to clean up the web.config file and set some default values.
- Run the WiX Harvest tool, heat.exe, to generate a .wxi include file of all of the files in the files folder.
Using robocopy makes it easy to just the files that you want and not include the files that are not needed for deployment.
With Windows Installer, every object that gets installed has to be defined in a WiX source file. You get end up with stuff that looks like:
Which is hideous to do by hand. You can run heat.exe on a folder and it will generate that the include file for all the files in that folder for you. In my prebuild event, I had the following lines:
The 5th line is the heat command line. The various command line options are documented here. This ran without any problems on my dev machine. Hilarity ensued when I tried to make a build from our TFS server. I was getting build errors when it executed heat.exe
heat.exe: Access to the path 'C:\Builds\31\VSTancillary\FleetVision_Dev\Sources\WixSetupProject\adminfiles.wxs' is denied.
That was annoying. During the build, heat was recreating the adminfiles.wxs file each time. Since that file was in source control, it was set to read only on the build server. That caused heat.exe to abort out since it couldn’t recreate that file. Our build engineer suggested using the attrib command to clear the read only bit. The light bulb (LED, should last longer than incandescent) flickered above my head and I realized that since that file was in source control, I didn’t need to created it on the build server. I just needed to set the build so that heat didn’t run on the build server.
There are probably a few ways of doing this, I went with setting it up so that heat would only get run for debug builds. Our build server is only doing release builds, this would work for me. So I moved the prebuild code out of the project property settings and implemented them as individual MSBuild tasks.
The first part of doing that was to install the MSBuild Extension Pack from CodePlex. I did that to get a RoboCopy task for MSBuild. Robocopy is very powerful tool for copying and synching up files, but has this one little quirk. It return 1 as a success code. Everything else on Planet DOS returns 0 for success and non-zero values to indicate an error. The MSBuild.ExtensionPack.FileSystem.RoboCopy task knows about that quirk and prevents MSBuild from reporting a robocopy success code as an error. Lots of good stuff in the Extension Pack, you’ll want to have one in your toolbelt.
When you install WIX, you get WIX specific extensions for MSBuild. The task for heat is called HeatDirectory. The HeatDirectory equivalent of the heat.exe command line that I was using looks like this:
The first element is Condition, which is comes with MSBuild. By setting the value to ” ‘$(Configuration)|$(Platform)’ == ‘Debug|x86’ “, MSBuild will only execute that task when the condition evaluates to true.
That worked perfectly, but only for the first time. After doing one debug build, the next build bombed out on the RoboCopy task. There was a problem with the files being in use. If I restarted VS, I could do another build. If I commented out the HeatDirectory task, the build would work. I went to the WIX site and sure enough, this was a known bug. The heat.exe was keeping the file handles open for the files that it read.
By default, HeatDirectory was running heat.exe from within the Visual Studio process. This was the fast way to execute heat, but you pick up any handle heaks from the heat.exe. In one of the comments to the bug report, a work around was suggested. Add RunAsSeparateProcess=”true” to HeatDirectory. This forces heat.exe to be run as a separate process and the leaked handles get flushed when that process ends.
That took care of the problem. While this is a known bug, the comments associated with that bug made it clear that it’s not going toget addressed any time soon.
So what is CTT? It is a command line version of the XDT transform that Visual Studio uses when it transforms web.config from web.release.config and web.debug.config. It’s another good tool.
If you are still reading this, here is the final version of the prebuild events