Introducing Source Control
Visual Studio supports source control using the Visual Studio Integration Protocol (VSIP) layer in its Integrated Development Environment (IDE). VSIP can host a variety of source control packages, usually implemented as plug-ins written to the appropriate protocols. An example of a source control plug-in is the SourceSafe LAN plug-in supported by Visual SourceSafe. For details of this plug-in, see the Visual SourceSafe Help.
Note
Visual Studio refers to source control packages as plug-ins, although they can be implemented as other types of software modules.
Visual Studio source control is simply an environment for third party source control plug-ins. Therefore its functionality is only activated by installation of a plug-in. To use a third-party source control plug-in, you must usually install the third party application and/or the source control plug-in(s) on the client and server machines for your site. Once they have been installed as indicated by the third party instructions, their functionality will be available through Visual Studio. The operations that are enabled are variable, depending on the source control plug-in. You must see your third party documentation for package-specific operational details.
See "Overview (Source Control)" in the Visual Studio Help for design details of source control in Visual Studio. This section of the Help also provides all the information you will need for developing a third-party source control package that is compatible with Visual Studio.
Basics of Source Control Support in Visual Studio
Basic source control support in Visual Studio includes setting of source control plug-in and environment options, plug-in switching, database access, and versioning for and manipulation of Visual Studio projects, solutions, and files and associated metadata. Source control in Visual Studio also enforces protocols for the control of database accesses, for example, the Lock-Modify-Unlock work style, in which a user who wants to modify a file must check it out exclusively.
It is important to remember that you should use source control in Visual Studio mechanisms to interact with a source control plug-in. Do not use other client applications presented by the third party furnishing the plug-in, for example, Visual SourceSafe Explorer. Proper use of the source control mechanisms in Visual Studio ensures that only correct files are added to source control and that your Visual Studio project and solution files are updated with the correct plug-in-specific details.
Source Control Plug-in Configuration and Switching
Visual Studio source control supports configuration and plug-in switching through the Source Control entry in the Options dialog box. This entry is accessible by selecting Options on the Tools menu of Visual Studio. You will use the Options dialog box to select the plug-in that you want to use for source control, and set up environment options for that plug-in.
Before you and your team can take advantage of source control features in the Visual Studio IDE, you must:
Determine if any source control plug-ins are available.
If the source control plug-in that you want to use is not installed on your computer, install the third-party product that supports the plug-in and restart Visual Studio to register it.
Create a source control database according to the functionality of the particular plug-in.
Send a link to the database location to all team members.
Database Access
Basic database access commands, for example, Check Out and Add to Source Control, are available in the File menu of Visual Studio. However, these commands are only activated after you have chosen the source control plug-in that you want to use. When you use one of the basic database access commands, the plug-in that you have chosen invokes the corresponding third-party functionality and/or environment to complete the associated operation.
Some access operations are active with only the plug-in selected, while other operations are only available when you have also selected a Visual Studio project, solution, or file in Visual Studio's Solution Explorer. For example, you can use an Add to Source Control command once you have chosen a plug-in. However, to use a Check In command, you must have an item selected in Solution Explorer.
File Handling by Source Control
You can add the following files to Visual Studio source control:
Solution files (*.sln).
Project files, for example, *.csproj, *.vbproj files.
Application configuration files, based on XML, used to control run-time behavior of a Visual Studio project.
Files that you cannot add to source control include the following:
Solution user option files (*.suo).
Project user option files, for example, *.csproj.user, *.vbproj.user files.
Web information files, for example, *.csproj.webinfo, *.vbproj.webinfo, that control the virtual root location of a Web project.
Build output files, for example, *.dll and *.exe files.
Namespace Change Propagation
Visual Studio source control supports namespace change propagation in source control plug-ins. Change propagation applies to delete, rename, and move operations. When you request an operation for which change propagation is enabled, the source control plug-in changes your working copy of the source-controlled item, the master copy in the database, and the copies of other users when you check in the item and the other users retrieve it.
How Source Control Handles Solutions and Projects
When you add a solution or project to source control, the first thing a source control plug-in must do is identify a unified root for the item being added. This root is a path to the parent directory for all working folders and files making up the solution or project.
A unified root generally maps to a physical path on disk. However, if a solution contains files or projects that reside on more than one disk drive, there is no physical folder to which a unified root can map. A solution can span drives but a source control unified root cannot. To support this situation, Visual Studio source control supports the concept of a super-unified root. This type of root is a virtual container beneath which all projects and files in a source-controlled solution are located.
When you add a solution using a source control plug-in with advanced capabilities, the plug-in creates an empty solution root folder in the database. This folder will contain all items in a source-controlled solution. By default, this folder is <solutionname>.root.
Note
When you add a single project to source control, a .root folder is not created.
Use of the solution root provides the following benefits:
Fewer Prompts. The solution root minimizes the potential number of source control bindings for a solution and thus minimizes user prompts when you add a solution to source control and perform other tasks.
Project Encapsulation. The solution root ensures that all projects in a solution can be readily identified as belonging together, even when one or more of the projects reside on different partitions or computers.
You can disable the creation of the <solutionname>.root folder, but doing so is not recommended. For more information, see How to: Disable Creation of the <solutionname>.root Folder.
Solutions in Visual Studio are either well-formed or not. A well-formed solution is one for which the hierarchical structure on disk matches its structure in Solution Explorer. All projects in a well-formed solution are stored in subfolders of the solution folder on disk. If the solution is well-formed when you add it to source control, the source control plug-in creates a folder beneath *.root folder to contain the master copies of the solution file (*.sln) and solution user option files (*.suo) for the solution. Finally, the source control plug-in creates a folder beneath the .sln folder for each additional project in the source control database.
If a solution is not well-formed, the source control plug-in creates a folder for the solution and its initial project. Then folders for each additional project are created in parallel to the solution folder.
Views of a Solution or Project
Visual Studio provides three distinct views of a source-controlled solution or project: design, source control, and physical. Many source control tasks are easier to perform when there is a one-to-one mapping between the individual elements of these views. However, if you create your solutions and projects and add them to source control using the default settings in Visual Studio, your solutions and projects will not necessarily be organized in the same way on disk as they are in Solution Explorer and in the database.
The design view of a solution or project, which you see in Solution Explorer, is a logical depiction of the contents of a solution or project. Generally, the design view is tidy and meaningful. Unnecessary files are hidden and files from many different physical locations are pressed into a single project container.
The source control view of a solution or project, which you see in a standalone application, such as Visual SourceSafe Explorer, is also a logical view of a solution or project. However, the source control view is not necessarily a reflection of the logical view.
The physical view of a solution or project, which you see in Windows File Explorer, is unlikely to reflect the hierarchical structure of either the logical or the source control view.
The following guidelines can help you achieve organizational fidelity between the design, physical, and source control views of your source-controlled solutions and projects:
Create a blank solution first, and then add projects to it. This helps you maintain the logical parent-child relationship between a solution and its projects in storage. When you then add the solution to source control, the source control view and design view will both mirror the solution hierarchy on disk.
Give each solution a unique and descriptive name that differs from the name of each of the contained projects.
Avoid adding link files to a source-controlled solution or project.
If possible, store all files in a solution or project on one disk drive.
Source Control Connections and Bindings
Visual Studio defines a connection as a live data link between Visual Studio and a database server. When you add a solution or project to source control, your source control plug-in copies the item and all of its contents from disk into the database. One source control folder is created for each folder containing a solution or project file. After adding the item, the source control plug-in binds your local working copy of a solution or project to its version in the database.
Every source-controlled solution has at least one source control binding. However, an item can have multiple bindings and require multiple connections to the database. The number of bindings and connections depends on how you create the solution initially and whether or not its projects and files are all saved on the same partition.
As an example of bindings and connections, think of a well-formed source-controlled solution, with multiple projects, as a house with several rooms. When you build the house, you can install a single high-speed data line from one room to the street. You install a router behind a firewall to distribute the data feed to other rooms and you pay an Internet service provider to connect your house to the Internet.
You might think of a source control binding as representing the single data line created for the house. When you open a source-controlled solution, a connection is created across that binding. The connection establishes a handshake between your working copy of the solution on disk and the master copy of the solution in the database.
If a source-controlled solution is not well-formed, you can look at it like a house in which every room is connected to the Internet directly. Internet charges are more expensive than in the single-connection house, maintenance costs are higher, and switching to a different Internet service provider is much more difficult and time-consuming.
Ideally, a solution and its projects share a single source control binding. Single-binding solutions are more manageable than multiple-binding solutions. They are easier to:
Disconnect from source control in order to work offline.
Connect to the database after reconnecting to the network.
Branch in one step.
You can create a multi-project solution with a single binding by creating a blank solution before adding its projects. You can also do this by selecting the Create Directory for Solution option in the New Project dialog box when creating a solution-project pair.
If you create a solution-project pair in one step and do not select the Create Directory for Solution option in the New Project dialog box (off by default), a second binding will be created when you add a second project to the solution. One binding is created for the initial project and the solution. Additional bindings are created for each additional project.
Source Control Terminology
The Visual Studio documentation uses a number of terms to describe source control features and concepts. The following table defines some of the common terms.
Basis version
The server version of a file from which a local version is derived.Binding
Information that correlates a working folder for a solution or project on disk to its folder in the database.Branching
Process of creating a new version, or branch, of a shared file or project under source control. Once a branch has been created, the two versions under source control will have a shared history up to a certain point and divergent histories after that point.Conflict
Two or more different changes to the same line of code in situations where two or more developers have checked out and edited the same file.Connection
A live data link between a source control client (for example, Visual Studio) and a source control database server.Database
Location where all master copies, history, project structures, and user information are stored. A project is always contained within one database. Multiple projects can be stored in one database, and multiple databases can be used. Other terms commonly used for a database are repository and store.History
Record of changes to a file since it was initially added to source control. With version control, you can return to any point in the file history and recover the file as it existed at that point.Label
User-defined name attached to a specific version of a source-controlled item.Local copy
File in a user’s working folder to which changes are saved until a check-in occurs. A local copy is sometimes referred to as a working copy,Master copy
The most recently checked-in version of a source-controlled file, as opposed to the local copy of a file in your working folder. Other terms for master copy are server version and database version.Merging
Process of combining differences in two or more modified versions of a file into a new file version. Merging can affect different versions of the same file or changes made to the same file version.Shared file
A file having versions that reside in more than one source control location. Other terms for a shared file are copy and shortcut.Solution root
An empty folder in a database that contains all items in a source-controlled solution. By default, this folder is <solutionname>.root.Super-unified root
A virtual container beneath which all projects and files in a source-controlled solution are located. For example [SUR]:\ is the super-unified root of a source-controlled solution containing projects that are located in [SUR]:\C:\Solution\ProjOne and [SUR]:\D:\ProjTwo.Unified root
A path to the parent directory for all working folders and files in a source-controlled solution or project. For example, C:\Solution is the unified root of a source-controlled solution containing files that are located in C:\Solution, C:\Solution\ProjOne and C:\Solution\ProjTwo.Working folder
Location where your local copies of source-controlled items are stored, usually on your own computer. Another term for a working folder is workspace.
See Also
Tasks
How to: Disable Creation of the <solutionname>.root Folder