TFSBuild/MSBuild and Project Reference vs File Reference

Question

We Have a large VS solution using project references which is build by TFS Build like so:

Solution
- Project 1
- Project 2
- Project ...
- Project N

Because the solution is too large we have several smaller solutions which we use day to day:

SubSolution
- Project 1
- Project 19

The problem is that developers working on SubSolution find that it is not building because the project references could not be found, so they change the projects to use file references.

This then goes on to break the TFS Build which cannot find these file references because they have not been built yet (Even though the projects are in the same solution). Is there a way around this tug of war between the two types of references. What is the correct way of splitting out your solutions?

Answer 1

What is the correct way of splitting out your solutions?

Check out this chapter from the TFS guide by the Patterns & Practices team:

Chapter 3 - Structuring Projects and Solutions in Source Control

Pay special attention to this note to the "Partitioned Solution" scenario (which I believe you're actually trying to implement):

Unlike previous versions of Visual Studio, Visual Studio 2005 relies upon MSBuild. It is now possible to create solution structures that do not include all referenced projects and still build without errors. As long as the master solution has been built first, generating the binary output from each project, MSBuild is able to follow project references outside the bounds of your solution and build successfully. This only works if you use project references, not file references. You can successfully build solutions created this way from the Visual Studio build command line and from the IDE, but not with Team Build by default. In order to build successfully with Team Build use the master solution that includes all of the projects and dependencies.

Answer 2

Regardless of how you organise your build, developers should understand how references work, and be aware when they make changes to references that they shouldn't check those changes in unless they intended to make a change to the build process.

On the subject of organising your builds - as Dmytrol says, project references should work between solutions (As long as the target is already built, however that's also the case for file references anyway).

My advice would be to group your projects into small workable solutions and use project references within those solutions. Your main solution file / build can use project references too, however if you find project references between the smaller solutions too difficult to maintain you can use file references instead, and control the build order through project dependencies or the project build order (accessible within Visual Studio by right-clicking on a project in your solution).