Modifying the ConfigurationFolderPath RecursionType in Team Build 2008

re: Modifying the ConfigurationFolderPath RecursionType in Team Build 2008

aaronhallberg — Thu, 25 Jun 2009 15:35:55 GMT

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.

re: Modifying the ConfigurationFolderPath RecursionType in Team Build 2008

Martin Moe — Thu, 25 Jun 2009 12:37:44 GMT

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 :-|).

re: Modifying the ConfigurationFolderPath RecursionType in Team Build 2008

Vaccanoll — Thu, 11 Jun 2009 00:01:01 GMT

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

re: Modifying the ConfigurationFolderPath RecursionType in Team Build 2008

BobHardister — Tue, 30 Dec 2008 18:52:28 GMT

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?

re: Modifying the ConfigurationFolderPath RecursionType in Team Build 2008

freshr — Tue, 09 Sep 2008 20:23:24 GMT

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.

My custom tasks/targets are not getting download in TFS 2008 - error MSB4019

Ahmed Salijee — Tue, 15 Apr 2008 10:35:37 GMT

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

Team Build 2008 Downloads One Level Only

Maor David — Sat, 29 Mar 2008 22:45:26 GMT

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

TFS 2008: Team Build doesn't get subfolders of team build type folder by default

Visual Studio Team System (VSTS) Blog - by Neno Loje — Sun, 16 Mar 2008 04:05:06 GMT

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

re: Modifying the ConfigurationFolderPath RecursionType in Team Build 2008

Rick Glos — Thu, 14 Feb 2008 00:11:07 GMT

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.