Team Development with Visual Studio Team Foundation Server

• /Source
• /WinFormsProject
• /WebProject
• /WindowsServiceProject
• /ClassLibrary1
• /ClassLibrary2
• /ClassLibrary3
• Web.sln
• Service.sln
• All.sln
Keeping the structure flat provides a lot of flexibility and the ability to use solutions for
presenting different views on the projects. The physical folder structure around solution
files is very hard to change, especially if you realize that you need to reuse a class library
from another solution.
Reasons to use this structure include:
• Performance is improved when loading and building application sub-solutions.
• Sub-solutions can be used to create views on sets of projects based on development
sub-teams or boundaries of code sharing.
• You can use the master solution to build the entire application.
• You can easily map dependencies across projects in each sub-solution.
• It reduces overall complexity if the solutions are broken up logically. For example
breaking up the solution along technology or feature lines makes it easier for new
developers to understand which solution to work on.
The main reason not to use this structure is:
• Increased solution maintenance costs. Adding a new project might require multiple
solution file changes.
Multiple Solutions
If you work on a very large solution requiring many dozens of projects, you may
encounter solution scalability limits. In this scenario, break your application into multiple
solutions but do not create a master solution for the entire application because all
references inside each solution are project references. References to projects outside of
each solution (for example to third-party libraries or projects in another sub-solution) are
file references. This means that there can be no “master” solution.
Instead, you must use a script that understands the order in which the solutions need to be
built. One of the maintenance tasks associated with a multiple-solution structure is
ensuring that developers do not inadvertently create circular references between
solutions. This structure requires complex build scripts and explicit mapping of
dependency relationships. In this structure it is not possible to build the application in its
entirety within Visual Studio. Instead, you can use TFS Team Build or MSBuild directly.
Figure 3.3 shows the multiple solutions approach.