Passing custom properties to individual solutions in Team Build

Gautam Goenka posted an article on this topic way back on April 20, 2006.  It included a targets file which overrode the standard Team Build CoreCompile target and allowed user-specified properties to be passed into the MSBuild tast that Team Build uses to build the solution in the SolutionToBuild item group.  This approach is fine if you want to pass the same custom property values into each solution in the SolutionToBuild item group, but what if you want to pass different property values into each solution?

Manish Agarwal posted an article that could help get you started here.  His goal was to enable redirecting assemblies to solution-specific subdirectories, but it was easily extendable to passing other user-specified properties on a solution-specific basis.  Unfortunately, it also some problems, including breaking the calculation of errors/warnings during the compilation phase of the build.

Before pressing on, I should say that we do not recommend overriding the Core* targets in a Team Build build.  The primary reason here is that you will almost certainly be broken after you upgrade to Orcas if you override these targets, since most of them will be changing radically in that new version.  See this post by Buck Hodges for more details here.  The good news here is that the issues that caused people to override the Core* targets in Team Build v1 have been addressed in Orcas, so you should no longer find it necessary to do this sort of thing.

Having said all that, attached you will find a new CoreCompile override that will allow you pass custom property values into each solution via solution-specific metadata.  For example, if you wanted each solution to be signed with a different key file you could do something like:

    <SolutionToBuild Include="$(SolutionRoot)\foo.sln">
SolutionToBuild Include="$(SolutionRoot)\bar.sln">

NOTE:  My original example here, which purported to put individual binaries into individual subdirectories, was broken!  Thanks to Esteban Garcia for pointing this out, and sorry for any trouble I might have caused anybody...  If you want to put your binaries into individual subdirectories, try out the new attachment and do something like:

    <SolutionToBuild Include="$(SolutionRoot)\foo.sln">
SolutionToBuild Include="$(SolutionRoot)\bar.sln">

To use this modified CoreCompile target, just:

  1. Download the attached CoreCompileOverride.targets file and check it in alongside TfsBuild.proj.  (Alternatively, you can install this file somewhere on your build machine(s) and modify the import directory in step 2)
  2. Add an <import> statement to your TfsBuild.proj file - something like: 
    <Import Project="$(MSBuildProjectDirectory)\CoreCompileOverride.targets" />

  3. Add your custom properties to each item in the SolutionToBuild item group.

Hopefully you'll find this useful!  Let me know via comments if you run into any issues with the attached file, etc.


Comments (12)
  1. Rob Caron on New Team System Articles on MSDN. Aaron Hallberg on Passing Custom Properties To Individual…

  2. Buck Hodges says:

    Aaron Hallberg took a month off after the birth of his daughter, Stella . Now that he’s back, he’s got

  3. EstebanFG says:

    Hi, you need to add a backslash at the end of the property value:


    My build aborted because of that…easy fix.  

    The one issue that I’m having is that the folders are being created at the root of the drive where my files are dropped (\servernamef$), but i was expecting it in \servernameshareTeam ProjectBuild TypeBinariesPlatformToBuildDebug…any ideas?  Just like always, the individual assemblies still get dropped in the regular directory.

  4. Garry Trinder says:

    Thanks – I updated the example to include the trailing backslashes.  

    I’m not sure about your drop location issue, however. Why don’t you send me email (via and we can try to work it out outside of the comments section here…

  5. A problem that comes up over and over again (see forums posts here , here , etc.) with Team Build v1

  6. rmchale says:

    In order to get a new directory per project, I’ll need to create a new solution for each project?

  7. Garry Trinder says:

    With this approach, that is correct.  In Orcas, a new directory per project will be fairly straightforward – see the following forum post for info:  In Team Build V1, I have not come up with a simple way of supporting this behavior without also breaking something else…

  8. Marc-Andre Gosset says:

    The CoreCompileOverride conflicts with other tasks that depend on CoreCompile. AssemblyInfoTask is one such example.

    To fix it, simply locate <CoreCompileDependsOn/> (line 6) in file and change it to the following :




  9. If you use Team Foundation Server and haven’t seen the Setup and Admin FAQ .&#160; Do yourself a favour

  10. AGUMBE says:

    Hi Aaron,

    I have 2 separate MSBuild projects that I have been running individually(manually). Now I am looking forward to use a team build server. As you have mentioned in this post, I have added the flllowing in by TFS project file:


     <SolutionToBuild Include="$(SolutionRoot)OngoingScriptsMSBuildScript1.proj">



     <SolutionToBuild Include="$(SolutionRoot)OngoingScriptsMSBuildScript2.proj"/>




    However, in both my MSBuildScript files, I am not getting the value of the property "RootFolder" as "C:myroot" … but they are always empty.

    If I run the following command however, it works just fine:

    msbuild MSBuildScript1.proj /p:RootFolder=c:myroot

    Please note that I am using Visual Studio 2005 Team System

  11. こんにちは! フォーラム オペレーターの服部清次です。 前回の更新から少し時間が経ち、 あっという間に2月も後半に入 ってしまいましたが、皆さん、いかがお過ごしですか? 今日は、久しぶりに、 MSDN

Comments are closed.

Skip to main content