It has been nearly three years since I did any Wix work and I’m pleased to say things have moved on a *LOT*! I have too many memories from the old days of faffing around trying to pick up the correct DLL’s to incorporate into my installer based on the Build Configuration. Integrating with Team Build was far more work than it should have been. I am pleased to say that all those problems have gone away with Wix 3.5 Release Candidate.
I downloaded WiX and Votive as a combined package from the above link and installed it. I then created a project that would install my modeling framework & code generators. Any projects whose outputs you want to include in your installer you simply add as a Reference to your Wix project:
WiX has a cool feature called ‘harvesting’ (via heat.exe). Heat.exe will look at the Project References in your Wix project, identify their outputs and dynamically create a Wix fragment to include those outputs as part of your installer. To enable Heat for a given reference, you just select that Reference and set Harvest to True:
But I don’t use it. Any changes made to the generated fragment are lost between builds and new Component ID’s are generated. That does not appeal to my anal-retentive personality!
However, we can still leverage the features in other ways. One of my pet peeves in the old days was trying to identify the location of DLL’s to include in my Wix project: Debug? Any CPU? Release? And what if I did it as part of Team Build – everything might simply be placed in the Binaries folder. My installer needs to be able to locate the correct files.
Wix 3.5 solves this problem elegantly.
If you build within Visual Studio 2010, you will see some output like this:
(The window is scrolled off WAY to the right… the above line is part of the candle.exe call).
Notice the variables created for each and every project referenced by your Wix project! There’s a whole host of them for the project, targetdir, platform and so forth. Now all I need to do to pick up the DLL for my installer is to use that variable within WiX:
Regardless of the Build Configuration in use, it will now pick up the DLL’s for Debug, Release, Any CPU – and within Team Build too, without any extra work. Very kool! This makes it almost free to create installers for a Debug (Checked) version of your product.
However, if you’re building your software on a 64-bit system you might get this error:
Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'file:///C:\Program Files (x86)\Windows Installer XML
v3.5\bin\candle.exe' or one of its dependencies. An attempt was made to load a program with an incorrect format.
There are lots of ways to fix this (and if you’re a Consultant being paid by the hour, I suggest you try a few!) but the easiest way is to modify the MSBuild Platform in the Build Definition to X86: