VS 2010 and Source Control Providers

VS 2010 and Source Control Providers

  • Comments 9

Hi, I recently explained the reasons behind the project settings changes we made for VS 2010. Let me describe to you today, how some of these changes may impact source control providers.

The new .vcxproj extension and SCC

We changed the C++ project file format in VS2010, migrating to the new MSBuild syntax, and we changed the project file extension from vcproj to vcxproj to reflect this change. This change may impact SCC providers, depending on their design and implementation.

For example, most SCC providers based on an mssccprj.scc bindings hint file would not be able to create this file anymore because the provider only creates it for registered project extensions. Existing SCC providers will not track the new vcxproj extension without user or vendor intervention.

As a result of not being able to leverage the mssccprj.scc file for a vcxproj file, VS will instead embed the binding information into the project in two places

·         vcxproj file. This file stores SccProjectName, SccLocalPath and SccProvider as global property elements.

·         suo file. This is the per solution user setting file and it is used to store the SccAuxPath property.

While this is not necessarily a bad thing, the source code control experience in VS is simpler if the SCC provider is tracking this kind of information. Let’s, examine opening from source control, and from branched locations.

Add a new project to source control, under $/Project location. Because the source control provider can’t track the new project extension (.vcxproj), it will persist the source control information in the project file. Later, create a new branch from $/Project, $/BranchedProject. Open $/BranchedProject from source control into a different location on disk. The project file will still keep embedded source control information pointing to $/Project and not $/BranchedProject. To start working against the new branch instead of the original branch, you should change source control information via FileàSource ControlàChange Source Control.

This extra step can be avoided if the source control provider is able to track the new project extension, because the mssccprj.scc hint file will contain the correct branch information from the start.

Vendor Fix

To make integration simpler for the user, when SCC providers detect integration with VS 2010, it should add the new vcxproj extension to the list of recognized VS project extensions or at least provide a way for the user to add it in the UI.

User Fix

Some SCC providers such as Microsoft Visual Source Safe already allow the tracked extensions list to be edited by a user. In VSS client this can be done via Tools à Options à File Types in Source. If you are using Source Safe, add the new project extension to the list before adding new projects to source code control or converting old controlled projects to VS2010.

 The new .vcxproj.filters file and SCC

Another change made for VS2010, moved the Solution Explorer filter’s information from the project file into a separate file. This file is located on disk adjacent to the vcxproj project file, with the same name but a .vcxproj.filters extension. This change requires vendor intervention to ensure compatibility.

From the SCC perspective, this adds a new “master – special” relationship between the project and the filters file. This SCC concept is not new and refers to the behavior of special files where they remain transparent to the user, hidden in the UI but moving from workspace to depot in lockstep with their master file. The hiding behavior may vary from one SCC provider to another, but let me exemplify how Source Safe handles the “master – special” relationship.

In VSS, special files never show up in solution explorer or in the pending check-ins/checkout windows, they are listed only when they have a different source code control operation status to their master file.

For example, if you add a new header file to your source code controlled C++ project, this will generate a project change and also a filters change. Both the project and filters files will be checked out, but in the SCC pending check-in tool window only the project file will show up as changed. However, if you rename a Solution Explorer filter or move a file between filters, this change does not affect the project file and in this situation only the filters file will show up in the SCC pending check-in window.

This new relationship might impact third party SCC providers that previously didn’t have code that considered special files. A symptom of missing support is that when opening a vcxproj from source code control the project is displayed in Solution Explorer without the filter hierarchy and the .vcxproj.filters file is missing from its expected location on disk.

Project Conversion and SCC

Command Line upgrade.

If a VS2010 solution and project conversion are performed at the command line, conversion has no access to any SCC providers. SCC integration is typically only available from within the VS IDE. If projects are converted with commands like “devenv /upgrade” or “vcupgrade” and SCC settings are not stored inside the project, the solution will not be bound to the source code control depot when the converted solution is loaded.


This can be fixed by manually rebinding the local workspace to the SCC depot (File à Source Control à Change Source Control).

It might also be necessary to check out the solution before running the command line tools because, the command line conversion cannot request a checkout but will have modified at least the solution file locally. This can also be remedied from inside the IDE when you first load the converted solution.

If you are not using Visual Studio, but just MS command line tools and support such as the Windows SDK, this problem must be fixed up using the 3rd party SCC client software.


Visual Studio IDE upgrade

If you convert from within the VS IDE and your source control provider is either TFS or VSS, the new vcxproj projects and their filters files should be controlled automatically. VSS provides also the option of checking in the new projects and filters files, between the conversion finish and the first solution load, as you can see in the below screenshot.

Note, that in the above screenshot the filters file is not included because it has the same source control status (pending add) as its master file.

For some third party source control providers, the new project and filters files might not be automatically controlled after conversion from Orcas. Unless, the providers have implemented support for the new .vcxproj project extension and for the special-master relationship between the filters file and the project.

For those SCC providers that respond with a pending add operation to any new file dropped on disk under the enlistment root, the new project and filters files will be coincidentally controlled.

The new VS2010 project files should also be automatically controlled if the source control information was stored originally in the Orcas project files, because the conversion process would migrate those settings from .vcproj to .vcxproj, causing the new VS2010 projects to be detected as belonging to the same source control database.

Some of the source control providers that are using a mssccprj.scc hint file might still detect the new VS2010 project files before implementing support for the new extension, if their implementation takes into account the source control information of the solution. This is possible because the solution is pointing after conversion to the new .vcxproj files (instead of the old .vcproj files) and since the solution extension remained the same (.sln) the mssccprj.scc hint file works as before. Thus, all new projects belonging to the controlled solution will be automatically controlled, if the source control provider implementation is considering this scenario.


Project extension change impact on third party source control providers

The project extension change impacts third party SCC providers at conversion time in a few ways that might require Vendor intervention.

·         As discussed previously, if the SCC provider uses the mssccprj.scc file and your source control provider does not know about the vcxproj extension, the source control information will now be stored in the project and .suo files.


·         If the source control provider is using any special hint files based on composite of project file name (like vspscc files) those need to be renamed to take into account the new project extension.


·         If the project extension is stored explicitly in any special file (like in mssccprj.scc) that needs to be replaced with the new extension.


For these scenarios the SCC provider needs to know the name of the old project. More specifically, the IVsSccManager2.RegisterSccProject method as implemented by the third party SCC provider needs to know whether the current opening project just finished a conversion operation and if so it then needs to know the name of the pre-conversion project. This can be answered by calling a new interface for VS 2010. IVsProjectUpgradeViaFactory3 in the Microsoft.VisualStudio.Shell.Interop namespace. This new interface exposes the CheckProjectUpgraded method.

public interface class IVsProjectUpgradeViaFactory3
    int CheckProjectUpgraded
       [InAttribute] String^ pszFileName,
       [OutAttribute] bool% pbUpgradeComplete,
       [OutAttribute] String^% pbstrUpgradedProjectFileName



The current (after upgrade) name of the project about to be opened.


Returns whether the project was just successfully upgraded.


Returns the before upgrade name of the project about to be opened, if it just successfully completed a conversion, or empty string otherwise.


Thank you and let us know if you have any questions or concerns about this subject.

Andreea Isac
Software Development Engineer
VC Project and Build Team




  • Have there been improvements in or plans to adapt the SCC API to better suit source code control systems that use a model different than SourceSafe, or to make SCC binding more of a per-user setting?

    I use an SCC that has a model closer to CVS, where it only tracks files in a workspace and has no notion of projects or solutions. Using it under Visual Studio has been problematic at times because Visual Studio wants to do things that make sense for SourceSafe but not other SCCSes. For instance, the notion of a project/solution "binding root" is a big headache and leads to all sorts of weird behavior where VS2005/2008 force projects to be manipulated together in the Change Source Control dialog or refuses to allow SCC operations due to binding root conflicts. Another behavior I frequently see is that the IDE persistently asks me to check out a project from source code control and when you finally allow it to do so, it also checks out a bunch of files within the project too that I have to revert. It's possible this is caused by the SCC plugin, but I get a strong impression that these problems are being caused by limitations in the SCC API. For instance, you mention above that the SCC provider has to know about the .vcxproj extension -- why? Shouldn't the SCC provider receive the list of files comprising the project from the IDE?

    The "Source Control - Unable to Access Database" dialog also makes me shudder a bit. The Work Disconnected option works pretty well, but my experience has been that reconnecting is painful, with the usual process being that I have to let Visual Studio open a ton of files that haven't been changed and then revert them.

    The way I would like Visual Studio to interact with SCC is for the IDE to provide the connection between items in the solution and in the SCC, and thus an interface to add/edit/revert. It would be ideal if I didn't have to modify a vcproj/vcxproj/sln file to enable source control support -- that would be implicit from the SCC plugin identifying the files as being under source control. I like the IDE integration myself, but the fact that a project's SCC binding state is persisted state on the project rather than a user setting makes SCC binding less attractive. An alternative approach that has grown on me is to bind add/edit/revert operations through the SCC command line tool on $(ItemPath), and then bind keyboard shortcuts to those. It seems like the SCC API should be supporting that level of integration, though.

  • Thank you Phaeron for your feedback. During this cycle we did not have resources to redesign our source control support. We were only doing the necessary modifications needed by the new project system.

    We noted your concerns and we will consider them for a future release.

    Feel free to provide us even with more detailed scenarios that will help us understand what needs we should address in future.

  • > If you are using Source Safe, add the new project extension to the list before adding new projects to source code control or converting old controlled projects to VS2010.

    One thing to note here: the setting is per-user, per-database (stored in the ss.ini files). If you're changing the "CreateSccFiles" setting and add the new extension, make sure to use VSSExplorer and add the vcxproj extension to all VSS databases you're working with.

    Also, if one of the team members working on the same project forgets to add the extension, and he checks out/save/checkin the project file it will cause the real bindings to be added back in the project (and the only way to remove them and have the provider persist them is to have one of the team members with extensions set use ChangeScc dialog to unbind/rebind the solution). Therefore it's advisable for the administrator of the VSS database to change the extensions for all users of the VSS database by manually editing the users' ss.ini files and the template.ini file in the VSS database (and add the mssccprj =........ setting)


  • @Phaeron: Currently MSSCCI interface does not allow the kind of interaction between an IDE and a MSSCCI SCC provider as you require. A new set of interfaces will need to be invented on the side of MSSCCI to allow this kind of enlistment-based scc discoverability, and both VS and your scc provider will have to implement them - personally I doubt this will happen soon.

    However, Visual Studio has exposed since VS2005 a VSIP-based set of APIs that allow scc providers to integrate deeply with VisualStudio, and control everything, from the user interface to the way controlled projects are managed and discovered. It is up to the scc provider in that case what (if any) needs to be persisted in the solution and projects files to discover projects under source control.

    If your scc provider is enlistment-based and a different model suits it better than the MSSCCI model, your scc provider should consider implementing a package-based source control provider instead of a MSSCCI plugin.

    More information about Source Control VSPackages can be found in MSDN:


    Alin Constantin

    [Visual Studio Shell development]

  • All I wanna know is

    is it gonna work OK with Perforce?

  • Please read the content regarding third party source control providers in the blog, to enable it to work well with Perforce. If you run into any issue, let us know and we'll be happy to assist you. You may also report issues through Microsoft Connect.

  • It does not seem to work with Perforce :(

  • Shaz, what are the exact scenarios that are not working? Can you unblock yourself with manually executing the scc operations that do not work?

    As I explained in the blog, source control providers need to implement the new requirements I described, but the end user is not left with no workarounds available.

    Feel free to write directly to me about your scenario at andris at microsoft dot com.

  • RE:Perforce - we're seeing issues with some (but not all) projects left unable to retain valid connections to the Perforce database after conversion.  Viewed in the Change Source Control Dialog, the Server Binding column for the invalid project(s) is wrong - it points at the root of the whole branch.  How to correct this?  

    Also, in a given solution, half the server bindings are shown as "Perforce Project (<Path>)" (where <path> may not be included). The other half are shown as "//<path>".  All are connected, and all but one or two are valid (see paragraph 1).  Why aren't they all displayed as Perforce Projects?

Page 1 of 1 (9 items)