Files used by source control integration in VSS and VS .NET

There are a couple of files used by VisualStudio and SourceSafe for source control integration.
Before describing what is stored in them w.r.t. source control, let me emphasize one thing: DO NOT DELETE THESE FILES !
If you think that you will "unclutter" your hard drive by deleting these files, think again! You will do more harm than good, and will risk breaking the source control integration or other source control related features.

Solution file (<Solution>.sln)

	GlobalSection(SourceCodeControl) = preSolution
		SccNumberOfProjects = 2
		SccProjectName0 = \u0022$/Solution1\u0022,\u0020HBAAAAAA
		SccLocalPath0 = ..\\..
		SccProvider0 = MSSCCI:Microsoft\u0020Visual\u0020SourceSafe
		CanCheckoutShared = true
		SccProjectFilePathRelativizedFromConnection0 = SubFolder\\Solution1\\
		SolutionUniqueID = {50843811-C224-4A03-8FFF-C527B6AFE5AA}
		SccProjectUniqueName1 = ClassLibrary1\\ClassLibrary1.vbproj
		SccLocalPath1 = ..\\..
		CanCheckoutShared = true
		SccProjectFilePathRelativizedFromConnection1 = SubFolder\\Solution1\\ClassLibrary1\\
	EndGlobalSection

Project files (<Project>.vcproj, <Project>.vbproj, etc)

The format of the project file depends from one project to another. What's common to all the project is that they persist 4 settings related to the source control integration:
- the local path: the unified root path calculated by Visual Studio that will be used as the scc connection root
- the project name: the path in the scc database matching the local path's enlistment
- the aux path: usually the path to the source control database
- the scc provider name

The 4 strings may have dummy "SAK" values, indicating the project is under source control (in which case it's the source control provider's job to track the real location of the project in the source control database)

        SccProjectName = "SAK"
        SccLocalPath = "SAK"
        SccAuxPath = "SAK"
        SccProvider = "SAK"

or may have real values, when Visual Studio cannot find a msscprj.scc file or the scc provider cannot track the project's file extension.

        <SccProjectName>"$/Test.root/Test/Test", IQAAAAAA</SccProjectName>
        <SccLocalPath>.</SccLocalPath>
        <SccAuxPath></SccAuxPath>
        <SccProvider>MSSCCI:Microsoft Visual SourceSafe</SccProvider>

Connection hint file (<Solution>.vsscc) - notice the double 's', different from solution hint file that uses tripple 's'

This file is created by VisualStudio when the solution file does not reside in the solution connection folder. For instance, if a solution C:\temp\Subfolder\Solution1\Solution1.sln contains only a solution item C:\temp\File.txt, and this solution is added to source control, then the solution's connection folder will be c:\temp (the folder that contains all the files in the solution).
The .vsscc file should only exist in the source control database, and never on the local disk (well, only temporarily). The file is used during OpenFromSourceControl operations: when the user selects a sln file to open from source control, and in the database there is a .vsscc file with the same name, VisualStudio will get it locally and read it. The source control integration will open the connection using the SccProjectName0 database folder stored in the .sln file, and will move or get the solution file locally in the subfolder indicated in the .vsscc file, then will open the solution on local disk from this subfolder. The rest of the files in the project will be retrieved incrementally after that.

The .vsscc file is a Unicode text file containing a 'Jay0' signature followeb by the relative path from the connection root to the solution's parent folder. Here is an example:

	Jay0Subfolder\Solution1

Solution hint file (<Solution>.vssscc)

This is a Utf-8 file that is always created by source control integration for a controlled solution. (see also Project Hint Files)

	{
	"FILE_VERSION" = "9237"
	"ENLISTMENT_CHOICE" = "NEVER"
	"PROJECT_FILE_RELATIVE_PATH" = "relative:SubFolder\\Solution1"
	"NUMBER_OF_EXCLUDED_FILES" = "2"
	"EXCLUDED_FILE0" = "ExcludedTextFile.txt"
	"EXCLUDED_FILE1" = "ExcludedTextFile2.txt"
	"ORIGINAL_PROJECT_FILE_PATH" = ""
	"NUMBER_OF_NESTED_PROJECTS" = "0"
	"SOURCE_CONTROL_SETTINGS_PROVIDER" = "PROJECT"
	}

These Utf-8 files are to their related projects the equivalent of the solution hint file to the solution. The vspscc and vssscc files have similar formats and contain similar fields.

	{
	"FILE_VERSION" = "9237"
	"ENLISTMENT_CHOICE" = "NEVER"
	"PROJECT_FILE_RELATIVE_PATH" = "relative:SubFolder\\Solution1\\ClassLibrary1"
	"NUMBER_OF_EXCLUDED_FILES" = "0"
	"ORIGINAL_PROJECT_FILE_PATH" = ""
	"NUMBER_OF_NESTED_PROJECTS" = "0"
	"SOURCE_CONTROL_SETTINGS_PROVIDER" = "PROVIDER"
	}

Here is the explanation of fields in the vspscc/vssscc files:
- Enlistment_Choice (Never == regular project or solution, Compulsory = web project in isolation mode)
- Project_File_Relatie_Path: the path of the solution's (or project's) folder relative to the root of the source control connection used by that solution/project
- Number_Of_Excluded_Files and Excluded_FileXXX : The list of files excluded from source control in the project. For solution, this is the list of files excluded from source control in the Solution Items/Solution Folders projects. The file names are relative to the solution's folder.
- Original_Project_File_Path: Used for web projects in isolation mode (empty for the rest of projects and solution), this is the path of the project for the user who craeted the project and added it to source control. It helps creating the correct/new enlistment mappings when opening just the project from source control.
- Number_Of_Nested_Projects: Self explanatory, you'll see this different than 0 for instance in web projects in VS2002 (which nested a WebUI and Web???) - Source_Control_Settings_Provider: Provider or Project, indicating where should VisualStudio expect to retrieve the source control binding for the related project (in the mssccprj.scc file created by the provider, or in the project file persisted by VisualStudio)

This file is used by Visual Studio to store settings that are user-specific (not shared amongst different team members working on the same solution). Source control integration package stores in this file user-specific settings like:
• the path to the source control database: each team member may access the same database differently, e.g. for SourceSafe one user can access it as "D:\Program Files\Microsoft Visual SourceSafe 6.0", while another may access it via a file share "\\alin-home\SourceSafe\". When scc settings have to be persisted by VisualStudio, VS writes the SccAuxPath in the project files as empty string and instead it will write the AuxPath in the suo file, per-user.
• flags that indicate whether you're working Disconnected or not (see File/SourceControl/ChangeSourceControl dialog)
• web projects translations paths: when adding a web project to a solution, the solution will contain the web path of the user who created this web, let's say http://localhost/MyWebProject1. When this solution is added to source control and is opened by a second user, this user is prompted to select an enlistment for the web projects. Using Set Project Location dialog, this second user can pick a location like http://alin-home/WebProject1/. Notice that sln file cannot be modified to retarget the web location for this second user, because otherwise first user would have problems opening his web enlistment. Source control intrgration package will store this path in the suo file. If you accidentally delete the suo file and your solution contains web projects, you may unknowingly end up working on other teammate's files, or may simply fail to open the websites.

MSSCCPRJ.SCC - This file is created by MSSCCI-compliant source control providers

This file is created by source control providers like Visual SourceSafe if they can track the location of certain files in the database. A provider creates this file if it can store the AuxPath and ProjectName bindings for a file.

To help the source control integration in VisualStudio, a source control provider needs to track the location of solution and project files. When the provider is able to track the source control location of a project file, the source control bindings of that project will not be written in the project and solution file (dummy 'SAK' strings will be used instead as a signature in this case). This helps scenarios like Branching, when the project will automatiicaly be bound to the branched location without the user having to use the File/SourceControl/ChangeSourceControl dialog to retarget the new branch. Also, creating mssccprj.scc may help keeping the source control integration working even when the users don't use source control integration properly (when they Get projects using VSS standalone instead of using the integration commands OpenFromSourceControl)

In SourceSafe the list of files that will be tracked can be configured using SourceSafe Explorer in Tools/Options/FileTypes/CreateSCCFile.

Here is an example of a mssccprj.scc file content:

	SCC = This is a Source Code Control file

	[ClassLibrary1.vbproj]
	SCC_Aux_Path = "D:\Program Files\Microsoft Visual SourceSafe 6.0"
	SCC_Project_Name = "$/Solution1/SubFolder/Solution1/ClassLibrary1", PBAAAAAA

For a description of mssccPrj.scc file format you can consult the most recent MSSCCI specification.

VssVer.scc or VssVer2.scc - These are binary files that are specific to Microsoft Visual SourceSafe

Visual SourceSafe 6.0d and older creates VssVer.scc in each folder that contains source controlled files.
This file is used to establish 1:1 relations between the local parent folder and a project in a VSS database. Getting files from multiple VSS projects into the same local folder is not a good practice, and is not recommended, as the content of these VssVer*.scc files will be overwritten with each get operation.

VssVer.scc contains the version numbers, timestamps and checksums of the files in the matching SourceSafe project that have been got in the local folder. If this file is deleted, merge operations will not function correctly.

Visual SourceSafe 8.0 creates VssVer2.scc instead of VssVer.scc. In addition to the informations stored in VssVer.scc, this file stores the names of the files in the database and the parent folder at the time last Get operation was performed. Visual SourceSafe 8.0 tries to protect this file from being deleted accidentally by marking it hidden, read-only and system. If this file is however deleted, operations like 3-way merge, checkout local version, rename and deletes propagation and synchronization (in VisualStudio) will not function correctly.

See here more information on the format of VssVer.scc and VssVer2.scc files.

%USERPROFILE%\Local Settings\Application Data\Microsoft\WebsiteCache\Websites.xml - Visual Studio 2005 web project bindings

In VisualStudio 2005 web projects don't have an associated project file, so VisualStudio 2005 had to store project-specific settings like the source control bindings in a different location. While bindings are stored in the solution file, a copy of the project bindings is also stored in this WebSites.xml file. This allows opening web projects without a solution; web projects will still be able to connect to the correct source control location. The source control information stored in this file is equivalent with the information stored in the project file by the projects that track their files using a project file (vbproj, vcproj, etc).