{"id":4003,"date":"2010-03-16T12:43:00","date_gmt":"2010-03-16T12:43:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vcblog\/2010\/03\/16\/vs-2010-and-source-control-providers\/"},"modified":"2019-02-18T18:45:37","modified_gmt":"2019-02-18T18:45:37","slug":"vs-2010-and-source-control-providers","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/vs-2010-and-source-control-providers\/","title":{"rendered":"VS 2010 and Source Control Providers"},"content":{"rendered":"

Hi, I recently explained <\/span>the reasons behind the project settings changes we made for VS 2010<\/a><\/font>.<\/span> Let me describe to you toda<\/span>y, how some of these changes may impact source control providers.<\/span><\/font><\/font><\/p>\n

<\/p>\n

The new .vcxproj extension and SCC<\/span><\/b><\/p>\n

<\/font><\/span><\/b><\/p>\n

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

For example, most SCC providers based on an <\/font><\/span>mssccprj.scc<\/span> bindings hint file<\/font><\/font><\/font><\/a> 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 <\/font><\/span>vcxproj<\/span> extension without user or vendor intervention. <\/font><\/span><\/font><\/p>\n

As a result of not being able to leverage the <\/font><\/span>mssccprj.scc<\/span> file for a <\/font><\/span>vcxproj<\/span> file, VS will instead embed the binding information into the project in two places<\/font><\/span><\/font><\/p>\n

\u00b7<\/font>         <\/span><\/span><\/span>vcxproj<\/span> <\/font><\/span><\/b>file. This file stores <\/font><\/span>SccProjectName<\/span>, <\/font><\/span>SccLocalPath<\/span> and <\/font><\/span>SccProvider<\/span> as global property elements.<\/font><\/span><\/font><\/p>\n

\u00b7<\/font>         <\/span><\/span><\/span>suo<\/span><\/b> file. This is the per solution user setting file and it is used to store the <\/font><\/span>SccAuxPath<\/span> property.<\/span><\/font><\/font><\/p>\n

<\/p>\n

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\u2019s<\/span>,<\/span> examine opening from source <\/span>control, and from branched locations. <\/span><\/font><\/p>\n

Add a new project to source control, under $\/Project location. Because the source control provider can\u2019t track the new project extension (.vcxproj)<\/span>, it will persist the source control information in the project file. Later<\/span>, 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<\/span>, you should change source control information via File<\/span>\u00e0<\/span>Source Control<\/span>\u00e0<\/span>Change Source Control. <\/span><\/font><\/p>\n

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.<\/font><\/span><\/p>\n

Vendor Fix<\/font><\/span><\/b><\/p>\n

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

User Fix<\/font><\/span><\/b><\/p>\n

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 <\/span>\u00e0<\/span> Options <\/span>\u00e0<\/span> 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.<\/span><\/font><\/p>\n

<\/span><\/font><\/p>\n

 The new .vcxproj.filters file and SCC <\/span><\/b><\/span><\/p>\n

Another change made for VS2010<\/span>, moved the Solution Explorer <\/span>filter\u2019s information from the project file into a separate file. This file is located on disk adjacent to the <\/span>vcxproj<\/span> project file, with the same name but a <\/span>.vcxproj.filters<\/span> extension. This change requires vendor intervention to ensure compatibility. <\/span><\/font><\/p>\n

From the SCC perspective, this adds a new \u201cmaster \u2013 special\u201d 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 \u201cmaster \u2013 special\u201d relationship. <\/font><\/span><\/p>\n

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.<\/font><\/span><\/p>\n

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. Howeve<\/span>r, 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.<\/span><\/font><\/p>\n

This new relationship might impact third party SCC providers that previously didn\u2019t have code that consid<\/span>ered 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 <\/span>.vcxproj.filters <\/span>file is missing from its expected location on disk.<\/font><\/p>\n

<\/p>\n

Project Conversion and SCC<\/span><\/b><\/p>\n

<\/span><\/b><\/p>\n

Command Line upgrade.<\/span><\/b><\/p>\n

If<\/span> <\/span>a VS2010 solution and project conversion <\/span>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 \u201c<\/span>devenv \/upgrade<\/span>\u201d or \u201c<\/span>vcupgrade<\/span>\u201d 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. <\/span><\/p>\n

<\/span><\/p>\n

 <\/span><\/p>\n

<\/p>\n

This can be fixed by manually rebinding the local workspace to the SCC depot (File <\/span>\u00e0<\/span> Source Control <\/span>\u00e0<\/span> Change Source Control). <\/span><\/p>\n

It might also be necessary to check out the solution before running the command line tools because<\/span>, 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. <\/span><\/p>\n

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.<\/span><\/p>\n

 <\/span><\/p>\n

Visual Studio IDE upgrade<\/span><\/b><\/span><\/b><\/p>\n

If you convert from within the VS IDE and your source control provider is either TFS or VSS, the new <\/span>vcxproj<\/span> 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.<\/span><\/p>\n

<\/span><\/p>\n

<\/p>\n

Note<\/span>, 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. <\/span><\/p>\n

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

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. <\/span><\/p>\n

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.<\/span><\/p>\n

Some of the source control providers that are using a <\/span>mssccprj.scc<\/span> 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. Th<\/span>us, all new projects belonging to the controlled solution will be automatically controlled, if the source control provider implementation is considering this scenario.<\/a><\/span><\/p>\n

 <\/span><\/p>\n

Project extension change impact on third party source control providers<\/span><\/b><\/p>\n

The project extension change impacts third party SCC providers at conversion time in a few ways that might require Vendor intervention. <\/span><\/p>\n

\u00b7         <\/span><\/span><\/span>As discussed previously, if the SCC provider uses the <\/span>mssccprj.scc<\/span> file and<\/b> your source control provider does not know about the <\/span>vcxproj<\/span> extension, the source control information will now be stored in the project and .<\/span>suo<\/span> files.<\/span><\/p>\n

 <\/span><\/p>\n

\u00b7         <\/span><\/span><\/span>If the source control provider is using any special hint files based on composite of project file name (like <\/span>vspscc<\/span> files) those need to be renamed to take into account the new project extension. <\/span><\/p>\n

 <\/span><\/p>\n

\u00b7         <\/span><\/span><\/span>If the project extension is stored explicitly in any special file (like in <\/span>mssccprj.scc<\/span>) that needs to be replaced with the new extension. <\/span><\/p>\n

 <\/span><\/p>\n

For these scenarios the SCC provider needs to know the name of the old project. <\/span>More specifically, the IVsSccManager2.RegisterSccProject<\/span> 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<\/span> in the Microsoft.VisualStudio.Shell.Interop <\/span>namespace. This new interface exposes the CheckProjectUpgraded<\/span> method.<\/p>\n

[<\/span>GuidAttribute<\/span>(L<\/span>“943CE488-176F-457B-8C88-3502C775501C”<\/span>)]
[<\/span>InterfaceTypeAttribute<\/span>()]
<\/span>public<\/span> interface <\/span>class<\/span> IVsProjectUpgradeViaFactory3
{
…
<\/span>    int<\/span> CheckProjectUpgraded
    (
       [InAttribute] String^ pszFileName,
       [OutAttribute] bool% pbUpgradeComplete,
       [OutAttribute] String^% pbstrUpgradedProjectFileName
    )
…
}<\/span><\/p>\n

Where:<\/span><\/p>\n

\n\n\n\n\n\n
\n

pszFileName<\/span><\/span><\/font><\/p>\n<\/td>\n

\n

The current (after upgrade) name of the project about to be opened.<\/font><\/font><\/span><\/p>\n<\/td>\n<\/tr>\n

\n

pbUpgradeComplete<\/span> <\/font><\/span><\/font><\/p>\n<\/td>\n

\n

Returns whether the project was just successfully upgraded.<\/font><\/font><\/span><\/p>\n<\/td>\n<\/tr>\n

\n

pbstrUpgradedProjectFileName<\/span><\/span><\/font><\/p>\n<\/td>\n

\n

Returns the before upgrade name of the project about to be opened, if it just successfully completed a conversion, or empty string otherwise.<\/font><\/font><\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/span><\/p>\n

Thank you and let us know if you have any questions or concerns about this subject.<\/span><\/p>\n

Andreea Isac
Software Development Engineer
VC Project and Build Team<\/span><\/p>\n

<\/span><\/span><\/font><\/span><\/font><\/span><\/font><\/font><\/p>\n

<\/span><\/font><\/font> <\/p>\n

<\/span><\/font><\/font> <\/p>\n

<\/span><\/font><\/font> <\/p>\n","protected":false},"excerpt":{"rendered":"

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 […]<\/p>\n","protected":false},"author":289,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[40,41],"class_list":["post-4003","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus","tag-source-control","tag-vs2010"],"acf":[],"blog_post_summary":"

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 […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/4003","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/289"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=4003"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/4003\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=4003"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=4003"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=4003"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}