HaveComputerWillCode.Com

Welcome!
Life is a Non-Deterministic Finite State Automata
Automation ? (*pGeekiness)++ : Code /eneration;

November 14, 2010

Integrating WiX 3.5 into Team Build (TFS 2010) on a 64-bit system

Filed under: ALM,Programming — Tags: , , , , — admin @ 7:04 am

At the end of my previously related post, I gave a hacky-wacky way to get Wix 3.5 projects to build on a 64-bit Team Build system by setting the MSBuild Platform to ‘X86′ as part of the Build Definition:

Hardly acceptable! Running the whole build process under the 32-bit version of MSBuild might cause issues of it’s own. A better solution is to set the RunWixToolsOutOfProc property. So I don’t have to do this for every project, I modified it in the global wix2010.targets file (just search your drive for it, but it’s probably in Program Files (x86)/Microsoft/MsBuild/Wix):

  <PropertyGroup>
    <!-- Search for UserTargetsPath in your .targets file... -->
    <UserTargetsPath>$(MSBuildProjectFullPath).user</UserTargetsPath>
    <!-- ...and add this line to spawn all Wix applications in their own process space (ie: 32-bit) -->
    <RunWixToolsOutOfProc>True</RunWixToolsOutOfProc>
  </PropertyGroup>

You can then set the ‘MSBuild Platform’ in the previous screenshot to ‘Auto’. Of course, this will slowdown builds slightly on a 32-bit system because of the extra process spawning… so you might want to only set that variable if running under a 64-bit MSBuild process.

I’m guessing that eventually that property will be integrated into the released product so that builds on 64-bit systems work out of the box, but it certainly isn’t in the Release Candidate I’m currently using (3.5.2229.0).

L8r!

November 7, 2010

Integrating WiX 3.5 into Team Build (TFS 2010)

Filed under: ALM,Programming — Tags: , , , , — admin @ 4:56 am

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:

Enjoy!

Powered by WordPress