Partilhar via

Passing custom properties to individual solutions in Team Build

  • Artigo

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">
      <Properties>SignAssembly=true;AssemblyOriginatorKeyFile=C:\foo.snk</Properties>
    </SolutionToBuild>
    <SolutionToBuild Include="$(SolutionRoot)\bar.sln">
      <Properties>SignAssembly=true;AssemblyOriginatorKeyFile=C:\bar.snk</Properties>
    </SolutionToBuild>

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">
      <Subdirectory>foo</Subdirectory>
    </SolutionToBuild>
    <SolutionToBuild Include="$(SolutionRoot)\bar.sln">
      <Subdirectory>bar</Subdirectory>
    </SolutionToBuild>

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.

CoreCompileOverride.targets

Comments

  • Anonymous
    March 21, 2007
    Rob Caron on New Team System Articles on MSDN. Aaron Hallberg on Passing Custom Properties To Individual...
  • Anonymous
    March 21, 2007
    Aaron Hallberg took a month off after the birth of his daughter, Stella . Now that he's back, he's got
  • Anonymous
    March 28, 2007
    The comment has been removed
  • Anonymous
    March 28, 2007
    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 http://blogs.msdn.com/aaronhallberg/contact.aspx) and we can try to work it out outside of the comments section here...
  • Anonymous
    March 29, 2007
    A little while back I posted this question in MSDN Forums: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=731301&amp;SiteID=1...
  • Anonymous
    April 04, 2007
    A problem that comes up over and over again (see forums posts here , here , etc.) with Team Build v1
  • Anonymous
    April 04, 2007
    In order to get a new directory per project, I'll need to create a new solution for each project?
  • Anonymous
    April 05, 2007
    With this approach, that is correct.  In Orcas, a new directory per project will be fairly straightforward - see the following forum post for info: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1418143&SiteID=1.  In Team Build V1, I have not come up with a simple way of supporting this behavior without also breaking something else...
  • Anonymous
    May 28, 2008
    The comment has been removed
  • Anonymous
    August 01, 2008
    If you use Team Foundation Server and haven't seen the Setup and Admin FAQ .&#160; Do yourself a favour
  • Anonymous
    February 09, 2009
    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:<ItemGroup> <SolutionToBuild Include="$(SolutionRoot)OngoingScriptsMSBuildScript1.proj">   <Properties>RootFolder=c:myroot</Properties> </SolutionToBuild> <SolutionToBuild Include="$(SolutionRoot)OngoingScriptsMSBuildScript2.proj"/>   <Properties>RootFolder=c:myroot</Properties> </SolutionToBuild></ItemGroup>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:myrootPlease note that I am using Visual Studio 2005 Team System
  • Anonymous
    February 16, 2009
    こんにちは！ フォーラム オペレーターの服部清次です。 前回の更新から少し時間が経ち、 あっという間に２月も後半に入 ってしまいましたが、皆さん、いかがお過ごしですか？ 今日は、久しぶりに、 MSDN