Structuring Projects and Solutions in Team Foundation Source Control

Many of the default folder conventions used by Visual Studio when creating new solutions and projects are not optimized for team development and for use with TFS source control. Rather than accepting the defaults when you create new Visual Studio projects and solutions, you should give careful consideration to your local and server-based folder structure.
Objectives

• Structure projects for effective team development in Microsoft Visual Studio Team Foundation Server (TFS) source control.
• Know when to use multiple solutions and when to use a single solution.
• Identify appropriate structures for small, medium-size and very large teams.
• Keep server-side and client-side folder structures synchronized.
• Choose a strategy for unit test structure.
• Create a folder structure that supports various branching scenarios.
• Identify files are added to source control and maps local files to source control.

Strategies for Solution and Project Structure
The three most common strategies used to structure solution and project files are:

• Single solution. If you work on a small system, create a single solution and place all of your projects within it.
• Partitioned solution. If you work on a large system, use multiple solutions to group related projects together. Create solutions to logically group subsets of projects that a developer would be most likely to modify as a set, and then create one master solution to contain all of your projects. This approach reduces the amount of data that needs to be pulled from source control when you only need to work on specific projects.
• Multiple solutions. If you are working on a very large system that requires dozens of projects or more, use multiple solutions to work on sub-systems but for dependency mapping and performance reasons do not create a master solution that contains all projects.

Keep the following considerations in mind when designing a project and solution structure:

• Each project generates an assembly at build time. Start by determining what assemblies you want to create and then use this to decide what projects you need. Use this to determine how to factor your codebase into projects.
• Start with the simplest single solution structure. Only add complexity to your structure when it is really necessary.
• When designing a multi-solution structure:
• Consider project dependencies. Try to group those projects that have dependencies on one another as part of the same solution. This enables you to use project references within your solution. By using project references instead of file references, you enable Visual Studio to keep build
• configurations (debug/release) synchronized, and to track versioning to determine when projects need to be rebuilt. Try to minimize the number of cross-solution project references.
• Consider source sharing. Place projects that share the same source in the same solution.
• Consider team structure. Structure your solutions to make it easy for teams to work on a set of related projects together.
• Keep a flat project structure so that it is easy for you to group projects into solutions without needing to make file system or source control folder structure changes.