Visual Studio .sln, .vcproj, .vcproj.vspscc, .vssscc files

[jfreidin]

Hi. We've just upgraded our production VSS database to a Vault repository. In the process of rebinding working folders, I've run into some of the previously reported problems, like caching of the bindings. I found that by getting rid of old .MSSCCPRJ.SCC, .ncb, .suo files, and rebinding, I was mostly able to get the new bindings to stick.

In some projects .vcproj SccProvider="SAK" ("Should Already Know"), whereas in others SccProvider="MSSCCI:SourceOffSite", which after rebinding became SccProvider="MSSCCI:SourceGear Vault Client". In a couple of cases, I found that by opening a project that I had rebound to Vault, not only would it revert to SOS, but it would reset SOS as my Default SCC Provider.

In some projects the vcproj.vspscc files have “SOURCE_CONTROL_SETTINGS_PROVIDER” = “PROVIDER”, whilst in others, “SOURCE_CONTROL_SETTINGS_PROVIDER” = “PROJECT". In at least once case I determined that if I didn't change "PROJECT" to "PROVIDER", I was unable to keep Visual Studio from reverting to SOS bindings, even after deleting all of the .MSSCCPRJ.SCC, .ncb, .suo files, and rebinding.

Some of our projects have a .vssscc file and others don't.

My questions:

1) What is the recommended configuration for maximizing Visual Studio binding robustness. I was hoping there would be a way to check in files so that after using the Vault client to get latest version into a new folder, Visual Studio would simply find the correct bindings. I realize this may not be possible and the recommended procedure is to Open from Source Control directly in Visual Studio.

2) What is recommended for .vcproj SccProvider, "SAK" or "MSSCCI:SourceGear Vault Client"? How do you control this from Visual Studio?

3) What's the difference between .vspscc and .vssscc? Some of our .vspscc specify that certain objects, like MIDL output aren't under source control. Do we need both of these files? Should “SOURCE_CONTROL_SETTINGS_PROVIDER” = "PROJECT" or "PROVIDER", and how is this controlled from Visual Studio?

You've done a great job on the Vault Client and Server. It seems like a significant improvement over VSS/SOS.

[lbauer]

1) What is the recommended configuration for maximizing Visual Studio binding robustness. I was hoping there would be a way to check in files so that after using the Vault client to get latest version into a new folder, Visual Studio would simply find the correct bindings. I realize this may not be possible and the recommended procedure is to Open from Source Control directly in Visual Studio.

When a Visual Studio project is created, the best practice is to add it to source control via "Add to Source Control." If a different user wants to work on the project, they should "Open from Source Control." These steps establish the proper bindings. Once user adds a project to source control or opens from source control, they can then open the project normally, since it now has bindings.

The Vault GUI Client does not generate any bindings. If you add with the GUI Client and try to open with Visual Studio, there may be errors and you would have to Change Source Control, bind, etc. Not recommended.

2) What is recommended for .vcproj SccProvider, "SAK" or "MSSCCI:SourceGear Vault Client"? How do you control this from Visual Studio?

I don't think this is something the user can choose, unless they manually edit the project files and source control files. This is determined by the source control provider and Visual Studio.

The reason you're seeing two different binding methods is probably because some of your projects were previously in VSS.

In versions prior to Visual SourceSafe 6.0c, when a solution within Visual Studio.NET was bound to source control, the binding information was stored directly inside of the .sln and .proj files.

In later versions of VSS, all binding information is kept locally on the developer's machine in files named MSSCCPRJ.SCC. Within the .sln and .proj files of the solution, the source control binding information simply uses the notation "SAK" to denote that the project is currently bound. (Any new solution added to Vault also uses SAK notation.)

If a solution was originally added to source control using an older version of SourceSafe, then the binding information will already be written inside of the .sln and .proj files. That's why you're seeing both. If you want projects to use SAK notation, you may be able to unbind and rebind the projects:

1. Be sure to check in any changes you have currently made to the solution.

2. Using Vault integration, check Out the solution (.sln) and project (.proj) files for editing.

3. Under the Source Control menu of Visual Studio, select the "Change Source Control" menu.

4. In the resulting dialog, select the solution and all projects and then press the Unbind button. This will unbind the solution from source control and remove all binding information from within the .sln and .proj files.

5. Close the dialog.

6. Again, under the Source Control menu of Visual Studio, select the "Change Source Control" menu.

7. In the resulting dialog, select the solution and all projects and then press the Bind button. This will rebind the solution to source control, but will write all binding information to the external MSSCCPRJ.SCC files instead of within the .sln and .proj files.

8. Close the dialog.

9. Check in the modified .sln and .proj files.

3) What's the difference between .vspscc and .vssscc? Some of our .vspscc specify that certain objects, like MIDL output aren't under source control. Do we need both of these files? Should “SOURCE_CONTROL_SETTINGS_PROVIDER” = "PROJECT" or "PROVIDER", and how is this controlled from Visual Studio?

The .vspscc is the solution metadata file, and the .vssccc is the project metadata file. The .vspscc file points to the project file, which points to the provider info, which is in the MSSCCPRJ.SCC file. Visual Studio determines
how these are created, so no human intervention is required (or recommended).