Another Method for using solution-specific binaries subdirectories

A problem that comes up over and over again (see forums posts here, here, etc.) with Team Build v1 is that it is very difficult to compile individual solutions and/or individual projects within a solution into their own output directories.  I did a post last week on passing custom properties to individual solutions – one of the uses for this functionality is addressing this issue. 

A clever hack that addresses this issue was submitted to an internal Microsoft DL yesterday by Guido Pica, who works for Microsoft Consulting Services in Italy.  The idea is to use Team Build’s built-in ConfigurationToBuild logic to trick it into doing this work for you.  Here’s Guido’s solution in his own words:

Another quick way to get this is to customize Solution Configurations:

In Solution Configuration Manager, create a new solution configuration (name it as you want the subfolder named ex.: FirstSolution, etc.)

Usually you want to Copy from “Release” default configuration

DESELECT the option to create project configuration, cause this should remain *ONLY* a solution configuration, and should not be propagated to projects.

Then, in TFSBuild.proj, add all custom solution configuration to be processed as Flavors:


    <ConfigurationToBuild Include=”FirstSolution|Mixed Platforms”>


      <PlatformToBuild>Mixed Platforms</PlatformToBuild>


    <ConfigurationToBuild Include=”SecondSolution|Mixed Platforms”>


      <PlatformToBuild>Mixed Platforms</PlatformToBuild>



This way, the team build process will try to compile each solution against each solution configuration, but having each solution just his own configuration, this will be the only one really processed for that solution, skipping all the others and creating his own right subfolder.

Hope I been clear enough.

The trick here is that the ConfigurationToBuild item group in Team Build is expected to contain solution configurations, and not project configurations.  Solution configurations are essentially just a collection of project configurations, and critically can also specify whether or not individual projects get built at all.  So – the idea here is just to create several solution configurations which build only one project and then let Team Build do the work of putting the binaries into their own subdirectories.  Note that if you use “Any CPU” as the platform it won’t even insert the bogus “Mixed Platforms” directory into the mix. 

This solution is only really helpful when: (a) you have just one solution and want to copy individual project outputs into their own subdirectories, (b) you have a small number of projects, and (c) you don’t have automated unit tests (tests are also run per configuration, which is unlikely to work here).  If your build meets these conditions, however, this approach can allow you to solve the custom subdirectory issue without having to override CoreCompile, do any crazy machinations in the AfterDropBuild target, etc.  I should also note once more that this sort of thing will be much easier in Orcas, and shouldn’t require any hacks like this.

Thanks to Guido for the nice idea!

Comments (2)

  1. J.D. Meier on New Video: What Is – New in Team Foundation Server Source Control and New Video: What Is…

  2. A common complaint with Team Build v1 was that it ignored the output paths specified for individual projects