Team Foundation Build Property for Build Folder

Question

Using TFS 2010 I need to build a solution that depends on a couple of other solutions held in different team projects. I'm editing my build definition and I create a list of "Projects to Build'. When it comes to build the parent solution I get an error because it's unable to reference assemblies created by the other solutions. So I go back to edit build definition and add /p:ReferencePath="c:\builds\3\referencedproject\binaries\" to the "MSBuild Arguments" Build process parameters.

Problem is, I don't want to hard code the c:\build\3. I guess there may be a $() property I can use in its place - can anyone please advise?

The other problem I have is that the 'Main' project and the two other projects that it references live at the same level in the source code. As far as I can tell, I have to set the source control folder to be the level above this - which happens to be the root. This means that TFS Build does a get of all the projects on the root - which includes dozens of projects that are not required for my build. It's not a critical issue since it makes no attempt to compile these non-related projects but it does increase the time for the build cycle to complete. Is this only way to avoid this to "group" the projects that are required for my build into a different TFS source folder?

Answer 1

I'll start with problem 2 as this should be easiest to solve.

You have 2 options both involve changing the workspace mapping of your Build Definition.

You don't have to map at the folder "above", you can map individual folders so if your source looks like this.

$/TP/SolutionA

$/TP/Folder1/SolutionB

$/TP/Folder1/SolutionC

$/TP/Folder2/SolutionD

and you only want to include SolutionA and SolutionC in your build, you could set the workspace up as follows.

This will get just the code you need and preserve the relative paths between them.

Another option is to use cloaking, you map the "Root" folder and then cloak any folders you want the build to ignore.

Both of these methods will restrict the amount of source being downloaded when the build runs, and also prevent "continuous" builds from starting when checkins occur in the folders that haven't been mapped / Cloaked.

---

Problem number 1.

As Dylan suggests, probably the best thing to do is to use Binary References between solutions. Especially solutions in seperate team projects.

Check out my answer to this question for a full description.

Answer 2

For the references issue there are a few options. The most common one taking an explicit dependency on a specific version by checking in the binary to TFS.

For example, if you have Team Project A that has a dependency on Team Project B, I would assume they are setup as separate projects because they evolve differently, probably have different teams working on them, and have different release cycles. The common approach to managing this dependency is to checkin B.dll into Team Project A (usually in a lib folder specifically for this purpose), then use a file reference from within Project A's solution/projects to the dll in the lib folder.

This approach lets the Project A team explicitly choose which version of B.dll they wish to depend on, and make an explicit decision to adopt newer versions of B.dll on their own timetable.

For the other question of how to have a build definition download only select source code paths, you can specify multiple lines in the Workspace mapping screen when setting up a build definition. For example you could have the following:

$\ProjectA -> $(SourceDir)\ProjectA
$\ProjectB -> $(SourceDir)\ProjectB

This would download Project A + B but not C.