VS 2010和源代码管理提供商

嗨，我最近解释过 我们为VS2010所做的项目设置更改背后的原因 . 让我给你描述一下托达 是的， 这些更改中的某些更改如何影响源代码管理提供程序。

新的.vcxproj扩展和SCC

我们在VS2010中改变C++项目文件格式，迁移到新的MSBug语法，并且我们更改了项目文件扩展名。 项目文件 到 VCX项目 以反映这一变化 . 此更改可能会影响SCC提供程序，具体取决于它们的设计和实现。

例如，大多数SCC提供程序基于 MSSCPRJ.scc公司 绑定提示文件 将无法再创建此文件，因为提供程序仅为已注册的项目扩展名创建它。现有的SCC提供商不会跟踪新的 VCX项目 无需用户或供应商干预的扩展。

由于无法利用 MSSCPRJ.scc公司 文件 VCX项目 相反，VS将在两个位置将绑定信息嵌入到项目中

· VCX项目 文件。此文件存储 SCC项目名称 , SccLocalPath路径 和 SCC提供程序 作为全局属性元素。

· 索 文件。这是每个解决方案用户的设置文件，用于存储 SccAuxPath 财产 .

虽然这不一定是坏事，但是如果SCC提供程序跟踪此类信息，那么VS中的源代码控制体验会更简单。我们走吧 , 从源代码检查打开 控制，和 从分支位置。

在$/project location下向源代码管理添加一个新项目。因为源代码管理提供程序无法跟踪新的项目扩展（.vcxproj） , 它将源代码管理信息保存在项目文件中。稍后 , 从$/Project、$/BranchedProject创建新分支。从源代码管理将$/BrancheProject打开到磁盘上的其他位置。项目文件仍将保留指向$/project而不是$/BranchedProject的嵌入式源代码管理信息。开始使用新分支而不是原始分支 , 您应该通过文件更改源代码管理信息 à 源代码管理 à 更改源代码管理。

如果源代码管理提供程序能够跟踪新的项目扩展，则可以避免此额外步骤，因为msscprj.scc提示文件将从一开始就包含正确的分支信息。

供应商修复

为了让集成对用户来说更简单，当SCC提供者检测到与vs2010的集成时，它应该添加新的 VCX项目 扩展到已识别的VS项目扩展列表中，或者至少为用户提供一种将其添加到UI中的方法。

用户修复

某些SCC提供程序（如Microsoft Visual Source Safe）已经允许用户编辑跟踪的扩展列表。在VSS客户机中，这可以通过工具完成 à 选项 à 源中的文件类型。如果您使用的是源代码安全，请在将新项目添加到源代码管理或将旧的受控制项目转换为VS2010之前，将新项目扩展添加到列表中。

新的.vcxproj.filters文件和SCC

VS2010的另一个变化 , 已移动解决方案资源管理器 过滤器信息 从项目文件转换为单独的文件。此文件位于与 VCX项目 项目文件，同名但 .vcxproj.过滤器 分机。此更改需要供应商干预以确保兼容性。

从SCC的角度来看，这在项目和过滤器文件之间添加了一个新的“主-特殊”关系。这个SCC概念并不新鲜，它指的是特殊文件的行为，这些文件对用户保持透明，隐藏在UI中，但与主文件一起从工作区移动到仓库。不同的SCC提供程序的隐藏行为可能不同，但是让我举例说明sourcesafe如何处理“主-特殊”关系。

在VSS中，特殊文件从不显示在解决方案资源管理器或挂起的签入/签出窗口中，仅当它们的源代码控制操作状态与其主文件不同时，才会列出这些文件。

例如，如果将新的头文件添加到源代码控制的C++项目中，这将生成项目更改，也会更改筛选器。项目和过滤器文件都将签出，但在SCC挂起签入工具窗口中，只有项目文件将显示为已更改。你好 r， 如果重命名解决方案资源管理器筛选器或在筛选器之间移动文件，此更改不会影响项目文件，在这种情况下，只有筛选器文件会显示在SCC挂起签入窗口中。

这种新的关系可能会影响以前没有考虑 爱德 特殊文件。缺少支持的一个症状是，当从源代码控制打开vcxproj时，项目将显示在解决方案资源管理器中，而没有过滤器层次结构和 .vcxproj.过滤器 文件在磁盘上的预期位置丢失。

项目 转换和SCC

命令行升级。

如果 一 VS2010解决方案和项目转换 是 在命令行执行，转换无法访问任何SCC提供程序。SCC集成通常只在VSIDE中可用。如果使用命令转换项目，如“ 开发/升级 “或” VCU升级 “并且SCC设置不存储在项目中，加载转换后的解决方案时，解决方案将不会绑定到源代码控制库。

这可以通过手动将本地工作区重新绑定到SCC仓库（文件）来解决 à 源代码管理 à 更改源代码管理）。

在运行命令行工具之前，可能还需要检查解决方案，因为 , 命令行转换无法请求签出，但至少已在本地修改了解决方案文件。当您第一次加载转换后的解决方案时，还可以从IDE内部修正此问题。

如果您使用的不是visualstudio，而是MS命令行工具和Windows SDK等支持，则必须使用第三方SCC客户端软件解决此问题。

Visual Studio IDE升级

如果从VSIDE中转换，并且源代码管理提供程序是TFS或VSS，则新的 VCX项目 项目及其过滤器文件应自动控制。VSS还提供了在转换完成和第一个解决方案加载之间签入新项目和过滤器文件的选项，如下面的屏幕截图所示。

注意 , 在上面的屏幕截图中，过滤器文件不包括在内，因为它与主文件具有相同的源代码管理状态（挂起添加）。

对于某些第三方源代码管理提供程序，从ORCA转换后，新项目和筛选器文件可能不会自动控制 . 除非， 供应商已经实施了对新项目的支持 vcxproj先生 项目扩展名，用于过滤器文件和项目之间的特殊主关系。

对于那些对登记根目录下磁盘上的任何新文件执行挂起添加操作的SCC提供程序，新项目和过滤器文件将同时受到控制。

如果源代码管理信息最初存储在Orcas项目文件中，那么新的VS2010项目文件也应该被自动控制，因为转换过程会将这些设置从.vcproj迁移到.vcxproj，从而导致新的VS2010项目被检测为属于同一源代码管理数据库。

正在使用 MSSCPRJ.scc公司 在实现对新扩展的支持之前，提示文件可能仍然会检测到新的VS2010项目文件，如果它们的实现考虑了解决方案的源代码管理信息的话。这是可能的，因为解决方案是在转换到新的.vcxproj文件（而不是旧的.vcproj文件）之后指向的，并且由于解决方案扩展名保持不变（.sln），因此msscprj.scc提示文件与以前一样工作。第 我们， 如果源代码管理提供程序实现正在考虑此场景，则属于受控解决方案的所有新项目都将被自动控制。

项目扩展更改对第三方源代码管理提供商的影响

项目扩展变更在转换时会以一些可能需要供应商干预的方式影响第三方SCC提供商。

· 如前所述，如果SCC提供者使用 MSSCPRJ.scc公司 文件 和 您的源代码管理提供程序不知道 VCX项目 扩展后，源代码管理信息现在将存储在项目和中。 索 文件夹。

· 如果源代码管理提供程序正在使用基于项目文件名组合的任何特殊提示文件（如 vspscc公司 这些文件需要重新命名以考虑新的项目扩展名。

· 如果项目扩展名显式存储在任何特殊文件中（如 MSSCPRJ.scc公司 )这需要换成新的扩展。

对于这些场景，SCC提供者需要知道旧项目的名称。 更具体地说 IVsSccManager2.registersc项目 第三方SCC提供者实现的方法需要知道当前打开的项目是否刚刚完成转换操作，如果是，则需要知道转换前项目的名称。这可以通过调用VS2010的新接口来解决。 IVS项目升级工厂3 在 Microsoft.VisualStudio.Shell.Interop 命名空间。这个新接口公开了 CheckProjectUpgraded检查项目 方法。

[ 指南属性 （L） “943CE488-176F-457B-8C88-3502C775501C” )] [ 接口重复属性 ()] 公众的 接口 班 IVS项目升级工厂3 { … 内景 CheckProjectUpgraded检查项目 ( [InAttribute]字符串^pszFileName， [OutAttribute]bool%%pbUpgradeComplete完成， [OutAttribute]字符串^%%pbstrUpgradedProjectFileName ) … }

哪里：

pszFileName文件名	要打开的项目的当前（升级后）名称。
pbUpgradeComplete升级完成	返回项目是否刚刚成功升级。
PBSTRupGradedProject文件名	如果项目刚刚成功完成转换，则返回将要打开的项目的升级前名称，否则返回空字符串。

谢谢，如果您对这个问题有任何疑问或顾虑，请告知我们。

安德烈·伊萨克 软件开发工程师 风险投资项目和建设团队