26.04.2015 Views

Team Development with Visual Studio Team Foundation Server

Team Development with Visual Studio Team Foundation Server

Team Development with Visual Studio Team Foundation Server

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

How to Use a Single-Solution Strategy<br />

If you work on a small system, consider using a single <strong>Visual</strong> <strong>Studio</strong> solution to contain<br />

all of your projects. This strategy simplifies development because all of the code is<br />

available when you open the solution. This strategy also makes it easy to set up<br />

references, because all references are between projects in your solution. You might still<br />

need to use file references to reference third-party assemblies (such as purchased<br />

components) that are outside your solution.<br />

Additional Resources<br />

• For more information, see “Chapter 3 – Structuring Projects and Solutions in Source<br />

Control” in this guide.<br />

How to Use a Partitioned-Solution Strategy<br />

If you work on a large system, consider using multiple <strong>Visual</strong> <strong>Studio</strong> solutions, each<br />

representing a subsystem of your application. These solutions can be used by developers<br />

to work on smaller parts of your system <strong>with</strong>out having to load all code across all<br />

projects. Design your solution structure so that any projects that have dependencies are<br />

grouped together. This enables you to use project references rather than file references.<br />

Consider creating a master solution file that contains all of the projects, if you want to use<br />

this to build the entire application.<br />

When working <strong>with</strong> multiple solutions, use a flat file structure for all of your projects. A<br />

typical example is an application that has a Microsoft Windows Forms project, an<br />

ASP.NET project, a Windows service, and a set of class library projects shared by some<br />

or all of those projects.<br />

You can use the following flat structure for all projects:<br />

• /Source<br />

• /WinFormsProject<br />

• /WebProject<br />

• /WindowsServiceProject<br />

• /ClassLibrary1<br />

• /ClassLibrary2<br />

• /ClassLibrary3<br />

• Web.sln<br />

• Service.sln<br />

• All.sln<br />

By keeping the structure flat, you gain a lot of flexibility and the ability to use solutions<br />

for presenting different views of the projects. Designing the physical folder structure<br />

around solution files is very hard to change, especially if you realize that you need to<br />

reuse a class library from another solution.<br />

Note: If you are building <strong>with</strong> <strong>Team</strong> Build (which relies on MSBuild), it is possible to<br />

create solution structures that do not include all referenced projects. As long as the entire<br />

solution has been built first, generating the binary output from each solution, MSBuild is

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!