Partitioning a project into multiple solution

Question

I'm managing a mid-size project in VS2010 (and TFS2010). We have separate teams for different parts, and a team for a "common" part which will provide frameworks and such. Source structure:

• Common
• +--- CommonLibrary1
• +--- CommonLibrary2
• +--- etc.
• Part1
• Part2
• etc.

Requirements:

• A dev in the "Common" team should use Common.sln that contains only Common code
• A dev in the "Part1" team should use part1.sln that contains part1. It references stuff from Common, and should be able to build that stuff (same for part2, etc.)
• If a dev in the "Common" team create a new "CommonLibrary3" project, I only want to update Common.sln - I don't want to touch Part1.sln, etc.
• TFS build should always build everything

Non-requirement:

• TFS-build of just Part1. All of this is a single project, and is always released together.
• Separate management of parts.

Sub-optimal solution I know of:

• Add Common.sln to part1.sln - seems like VS just copies all project from Common.sln into part1.sln, so projects later addede to Common are not included.

• Replace solution files with MSBuild target files - http://sedodream.com/2010/03/19/ReplacingSolutionFilesWithMSBuildFiles.aspx. I guess that would work, but I want the devs to update solutions from VS, not hand-edit MSBuild files.

The TFS Guide books I found calls this a "Partitioned Solution", but doesn't specify how to actually achieve it.

Any recommendations?

Answer 1

In TFS 2010 build definitions you can refer to:

• Multiple source control folders to include in your build workspace
• Multiple solutions files to build in your build process

So (if I understand your question correctly), regarding TFS team build you have no issues.

The only challenge you have left is that (maybe) on any development system of part1 or part2 developers, that developer should be able to also build the Common.sln. As long as that developer has read access to the common branch, the local workspace can contain both source code bases and both can be build by the developer.

So:

• Common developer has RW access to Common, only R access to Part1 or Part2 (to test impact of changes),
• Part1 developer has R access to Common, RW access to Part1 and no or R access to Part2,
• Part2 developer has R access to Common, no or R access to Part1 and RW access to Part2

This should enable your scenarios.