Udostępnij za pośrednictwem

Modifying the ConfigurationFolderPath RecursionType in Team Build 2008

  • Artykuł

In TFS 2008, TfsBuild.proj files can be located anywhere in source control, not just in $/TeamProject/TeamBuildTypes, as was required in TFS 2005.  As a result, we changed the default recursion type used to download files from the configuration folder path (the location of TfsBuild.proj) to RecursionType.OneLevel, meaning that only the contents of the exact directory of TfsBuild.proj are downloaded.  The rationale here is that if you for some reason decided to put your TfsBuild.proj file at $/TeamProject, a fully recursive download would get the entire contents of the repository for that team project, which is probably not what you would want!  In some cases, however, you may wish to do a fully recursive download (if you store custom task assemblies in a subdirectory under your configuration folder path, for example), so we did provide a backdoor for changing this behavior.  In particular, you can set the ConfigurationFolderRecursionType key in TfsBuildService.exe.config on your build machine to "Full" to get full recursion.  Something like:

<add key="ConfigurationFolderRecursionType" value="Full" />

...in the appSettings portion of the config file should do the trick.  Make sure to restart the service after making the change, and the next build should do a fully recursive download.

Comments

  • Anonymous
    February 13, 2008
    Excellent tip.   I wondered how it determined only to get the files in the folder the build existed in.Is there a method to get other files into that folder?  Say a shared file used by multiple builds?For example, we use Team Build to Deploy to QA virtual machines.  Each QA users has their own build definition.  That way they can track work items in their build, etc.  We now have 18 of those builds.  They are all very similar except a different rsp file, and different value for the Assigned To field in the WorkItemFieldValues property.When we make a change by adding another solution,  upgrading to TFS 2008, etc, it’s very tedious to go through 18 TFSBuild.proj file.  It would be nice to have those files point to a shared file using the Import task, most likely 1 level up from the current location in source.  Checked into source of course, I don’t want to manually copy this file to the build machines.
  • Anonymous
    March 15, 2008
    In TFS 2005 subfolders of your team build type folder were copied recursively to the build temp directory
  • Anonymous
    March 29, 2008
    TfsBuild.proj files can be located anywhere in source control in Team Build 2008. That is the reason
  • Anonymous
    April 14, 2008
    I am prepping for next weeks VSTS session. Check here for more on the event. As part of that, I wanted
  • Anonymous
    September 09, 2008
    Like Rick, I am trying to point several TFSBuild.proj files to a common Import file. It would be really useful to be able to reference a shared location, such as one folder up from the proj file. That way I could have several build configurations, each living in its own folder, and share the common values.Do you have any advice on how to achieve this, or is it impossible? Thanks.
  • Anonymous
    December 30, 2008
    As an approach - I plan to try very soon, use one TFSBuild.proj file and conditional imports for each build defintion.  All these files could be kept in a "TeamBuild" team project in source control.  With this approach, every team build will pull down all the build files automatically.Has anyone attempted something like this?
  • Anonymous
    June 10, 2009
    +1 to the comments about being able to modularize the TFSBuild Process.  It is too bad we can't do that somehow.
  • Anonymous
    June 24, 2009
    The comment has been removed
  • Anonymous
    June 25, 2009
    Sorry for the lack of response on the various comments here...  In TFS 2008, there is no mechanism for putting MSBuild tasks/targets into a shared folder in version control - the two options are to put them into your various TfsBuild.proj folders or to install them to a known location on each of your build machines.  Obviously there are pluses and minuses to each approach.In TFS 2010 we have made a number of improvements here - I'll be doing a blog post on the topic at some point in the near futurue with more information, but everything mentioned in the comments here as desirable should be covered.