Solution Root: Source Control for Multi-Project Solutions in Visual Studio .NET 2003
Visual Studio Core Team
Summary: This article describes the solution root concept, introduced in Microsoft® Visual Studio® .NET 2003, for solutions under source control. The solution root is a single binding point for all contents of a Visual Studio .NET solution that is created when a solution is added to source control. Visual Studio automatically creates the bindings for you, therefore reducing the number of steps needed to configure source control for multi-project solutions. (6 printed pages)
Based on feedback from customers and Visual Studio partners, Source Code Control Integration (SCCI) in Visual Studio .NET 2003 includes a series of updates to various features. This article examines the solution root concept and its effects on source control features, as well as the rationale behind them. Let's start with defining some terminology.
Terminology varies widely across source control systems. This paper uses the terminology in Software Configuration Management Patterns: Effective Teamwork, Practical Integration by Berczuk & Appleton.
Workspace Corresponds to the location on each individual developer's machine where his or her own version of files in a source control system is stored. This is known as working folder in Microsoft Visual SourceSafe®.
Repository The shared location where the source control system stores all files being versioned. This is known as database in Visual SourceSafe.
Directory A container of files in the source control repository, which corresponds to a folder in users' local file system workspace. This is known as project in Visual SourceSafe.
Many source controls systems work by mirroring the contents of a file system folder, (also known as a workspace) into a directory in the repository. That file system folder is bound to that directory in the repository such that any changes to either one are reflected in the other.
In the following figure, the binding is established at the "Solution1" folder level:
Figure 1 Binding in source control systems
The Solution Explorer in Visual Studio .NET uses a reference-based mechanism to specify the contents and structure of a project or solution, regardless of the actual structure of the files in the file system. It is possible for the file system structure to be radically different from what you see in the Solution Explorer, such as the file structure created for ASP.NET Web projects.
For example, the following figure shows a solution that contains both an ASP.NET Web project and a console application project. The file system structure is quite different from the logical view provided by Solution Explorer, because the Web application is physically located in the Internet Information Server \wwwroot directory, which can be on a different disk drive — or even on another computer — from the one containing the solution file.
Figure 2 Logical (Solution Explorer) and physical (file system) view of a Visual Studio .NET solution
In cases like the one shown in the preceding figure, a common binding for a solution cannot be determined and multiple bindings are required. The following sections describe the differences in the way Visual Studio .NET 2002 and Visual Studio .NET 2003 handle multiple bindings.
In Visual Studio .NET 2002, independent bindings are created by the following process.
- Visual Studio determines the Longest Common Path (LCP). The LCP is the first common parent directory of the solution file and non-Web projects in the same drive volume as the solution file. For example, the LCP between c:\dev\solutions\solution1 and c:\dev\projects\project1 is c:\dev.
- One binding is created for the LCP.
- A binding is created for each non-Web project file in a different drive volume or network location.
- A binding is created for each Web project
For example, in figure 2, there would be two bindings created with the source control repository. The first binding would bind to the LCP (\Visual Studio Projects\Solution1, in this case), and would include the solution file and all the files in the ConsoleApplication1 project because the project resides on the same volume as the solution and a common path was successfully determined. The second binding would use the \wwwroot\WebApplication1 folder, and would include all the files in the WebApplication1 project. The following figure shows the bindings that Visual Studio .NET 2002 creates between the disc structure in our example and the source control repository:
Figure 3 Visual Studio .NET 2002 mapping of a solution in the source control repository
The approach implemented in Visual Studio .NET 2002 requires that whenever a project with multiple bindings is added to or opened from source control, the user has to map every single binding. In the case of Enterprise Template projects or Web projects, this might result in multiple prompts to "Add To" or "Open From" during these operations.
Visual Studio .NET 2003 introduced the concept of a solution root in source control. Solution root enables Visual Studio to automatically create the bindings for the user, hence reducing the amount of mappings the user needs to establish when either adding a solution to source control or opening a solution from source control. It also eliminates additional prompts when performing "Add To" and "Open From" source control operations.
The solution root is nothing but a single binding for all contents of a Visual Studio .NET solution that is created when a solution is added to source control.
By default, the structure of a solution with a solution root in the repository follows this pattern:
- A directory named after the solution with the .root extension appended to it (this is the Solution Root).
- A subdirectory of the solution root that corresponds to the LCP (Longest Common Path).
- An additional subdirectory of the solution root for each binding point.
The following figure shows the repository structure created by Visual Studio .NET 2003 for the solution from figure 2.
Figure 4 Visual Studio .NET 2003 mapping of a solution in the source control repository
This behavior is offered by default when you install Visual Studio .NET 2003. If you prefer the behavior from Visual Studio .NET 2002, you can revert to it by adding the following registry key to your system: [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\SourceControl] "DoNotCreateSolutionRootFolderInSourceControl"=dword:00000001
Note Before you modify the registry, back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, read article 256986 in the Microsoft Knowledge Base entitled "Description of the Microsoft Windows Registry" at http://support.microsoft.com/default.aspx?scid=kb;EN-US;256986.
- Click Start, click Run, type Regedit, and then click OK.
- Open HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1\SourceControl
- Select key
DoNotCreateSolutionRootFolderInSourceControl, click Edit, and then click Modify.
- In the Value data box, change 0 to 1, and then click OK.
Visual Studio .NET 2003 introduces the concept of a solution root in source control. The solution root is the location in the source control repository where all the contents of the solution are stored. It also eliminates additional prompts when performing "Add To" and "Open From" source control operations, thus reducing the amount of mappings you need to establish when you add a solution to source control or open a solution from source control. It also helps keep things organized in the repository by keeping everything in the solution in one directory.
Note At the time this article was written, not all source code control providers implemented support for creating solution roots. Please contact your source code control provider vendor for further information. The Visual SourceSafe 6.0d provider does support solution roots.
Berczuk, Stephen P. with Brad Appleton. Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Addison-Wesley, 2003.