Modifying the ConfigurationFolderPath RecursionType in Team Build 2008


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 (9)

  1. Rick Glos says:

    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.

  2. Anonymous says:

    In TFS 2005 subfolders of your team build type folder were copied recursively to the build temp directory

  3. Anonymous says:

    TfsBuild.proj files can be located anywhere in source control in Team Build 2008. That is the reason

  4. Anonymous says:

    I am prepping for next weeks VSTS session. Check here for more on the event. As part of that, I wanted

  5. freshr says:

    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.

  6. BHardister says:

    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?

  7. Vaccano says:

    +1 to the comments about being able to modularize the TFSBuild Process.  It is too bad we can’t do that somehow.

  8. Martin Moe says:

    Hi Aaron

    Brilliant. I was actually composing a mail to bharry after first experiencing a Woohoo! (Homer style) when we stumbled across this only to get a Bummer! when we did a smal test and saw the behavior described here, but my colleague found this posting before I managed to push the Send button.

    Now you have provided a solution. I was only wondering whether we could control this from the build type (say TFSBuild.rsp) instead of mucking aroung with the configuration for the build service. Seems obvious to me that this is something that you would want to control on a per build type basis.

    Actually, I just realized that this is probably not the case since we are already in an earlier stage of the process, before the processing of the build files themselves. What you need is to add this as a part of the Build Type definition along with the other stuff you can set there. I am hoping such a change is at least making it to VS2010 (but my hopes are not high :-|).

  9. Garry Trinder says:

    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.