在VS.NET IDE中集成VSS的常见问题

VSS与VS.NET IDE的集成会带来哪些好处？

好处：

（ 1 ） 可直接在 IDE 中 CheckOut/CheckIn 。

（ 2 ） 在一台新机器上第一次打开 Solution 时 ， 可为 Web Project 自动创建 IIS 虚拟目录。

（ 3 ） VS.NET 自动判断不该添加到 VSS 中的文件，例如 suo ， *.vbproj.user 等，避免手工添加这些文件之后导致个人环境互相干扰的问题。

（ 4 ）文件更名特别方便，尤其是 aspx 文件更名时， VSS 中的 aspx.vb 以及相关的 resx 文件都能自动更名。

 

缺点：

（ 1 ） VS.NET 的 Source Control Add-in 有 Bug ，经常出错，特别是调整 Solution 结构时。正确的 Folder 更名操作步骤很复杂，因此调整 Solution 结构特别麻烦。

（ 2 ）操作更要小心，有一定的培训 / 学习成本。

（ 3 ）打开 Solution 时，因为需要与 VSS Server 通讯，速度很慢，而且占用网络带宽和服务器资源。

（ 4 ） Web 项目的工作目录总是在 wwwroot 下面，与 SourceSafe 中的项目层次结构不一致。

（ 5 ）想要临时修改某个文件调试一下，特别不方便（因为提示要 CheckOut ），尤其是修改 Project 文件（比如增加一个临时文件测试一下的时候）。

（ 6 ）创建 Project 的人，在第一次 Add to Source Control 时， VSS 将自动创建一个与 Solution 同名的 VSS Folder ，比如：本来想将 Purchase.sln 添加到 $/…/Src 之下，但是结果是添加到 $/…/Src/Purchase 之下。对于 Web Project ，其他人 Open From Source Control 时，工作目录都会变成 InetPub/wwwroot 下面的子目录，而创建 Project 的人的工作目录却是原先在 …/Src/ 下面的某个目录。

（ 7 ） VS.NET 有很多 Bug ，导致操作出错或不便。比如：

• Change Source Control对话框中，经常几个Project被捆在一起，选中一个就选中其他几个，无法单独设定绑定路经。
• Unbind时，经常无法全选，这样在准备一个独立的、不绑定的开发环境时很费事。
• Check In时，有时会提示一些不相干的文件，让你选择是否Check In，而事实上那些文件根本没有Check Out。

 

想要将VSS与VS.NET IDE绑定，必须做什么准备工作？

（ 1 ）安装 VSS 客户端

安装程序在文件服务器上： //xafile/Share/MSDN/VSS/EN/VSS60d

CD Key: 111-1111111

（ 2 ）删除可能重名的 IIS VD

本机 IIS 最好没有任何自己创建的 VD （虚拟目录） ，否则，可能在打开 Solution 时被提示输入形如 VD_1 的工作目录。

另外， Inetpub/wwwroot 下面的同名目录也要删除，以免出错，尽管这种情况 VS.NET 不会提示 VD_1 样式的工作目录。

（ 3 ） 第一次从 VS.NET 打开 Solution ， 必须通过选择 File - Source Control - Open From Source Control 命令 ， 不能用传统方法 Get 之后从本地硬盘直接打开 ， 否则将无法自动创建 IIS VD 。

一个原来没有绑定的Solution，如何才能正确地实现绑定？

最保险的做法：

（ 1 ）将所有 Projects 从 Solution 中 Remove ，这样得到一个空的 Solution 。

（ 2 ） 用 VS.NET 的 File – Source Control – Add to source control 命令

注意： Add to Source Control Project 对话框中，默认有一个 Project 名，形如 SoluionName.Root ，应该把这个内容清空，否则会在 VSS 中看到 $/SolutionName.Root/SolutionName 这样的重复目录结构。

（ 3 ） 用 Add Existing Project 命令添加原有 Projects 到 Solutions 中。

（ 4 ） Check In 那些添加进来的 Projects 。

此时 VS.NET 会提示 resx 文件用 UTF-8 编码，无法用 VSS 控制变更等，不用管它。

绑定前后，Solution中的哪些文件有变化？又有哪些本来没有的文件会自动产生？

（ 1 ）关键的改变只有 sln 文件，原有内容之后会添加一个 GlobalSection ，形如：

Global

GlobalSection(SourceCodeControl) = preSolution

SccNumberOfProjects = 53

SccLocalPath0 = .

CanCheckoutShared = false

SolutionUniqueID = {EFD7F1A3-3977-4BE8-AFFC-D33AB7D8546C}

SccProjectUniqueName1 = ..//..//WebFramework//Src//Frameworks.etp

SccProjectName1 = /u0022$/WebProjects/WebFramework/Src/u0022,/u0020J…

SccLocalPath1 = ..//..//WebFramework//Src

CanCheckoutShared = false

……

EndGlobalSection

EndGlobal

（ 2 ）自动产生的 SolutionName.vssscc 文件没有什么实质性内容。

（ 3 ）自动产生的 etpname. vspscc 或者 projectname.vspscc 文件没有实质内容。看起来比较重要的一行信息是：

"PROJECT_FILE_RELATIVE_PATH" = "relative:WindowsApplication1"

（ 4 ） vbproj 文件会增加少量新内容。

<VisualStudioProject>

    <VisualBasic

        ProjectType = "Local"

        ProductVersion = "7.10.3077"

        SchemaVersion = "2.0"

        ProjectGuid = "{F894CF6B-BAC2-4F54-ACFA-DF317FFBBDBE}"

        SccProjectName = "SAK"

        SccLocalPath = "SAK"

        SccAuxPath = "SAK"

        SccProvider = "SAK"

    >

红字部分是新增内容 ， 也不是很重要。这些内容将来可能导致在打开时提示 “ Seem to be under source control but… ” 。

伴随 vbproj 文件，本地目录中会产生一个 *.vbproj.webinfo 文件，内容是：

<VisualStudioUNCWeb>

    <Web URLPath = "http://localhost/webapp1/WebApp1.vbproj" />

</VisualStudioUNCWeb>

看起来还比较重要，但是还没有发现过因这个文件的信息错误导致问题。

注意：

C# 项目文件（ csproj ）中的 SccProjectName 不是“ SAK ”这么简单，例如：

SccProjectName = '"$/WebProjects/WebFramework/Src/ApplicationBlocks", KGBEAAAA'

这是跟 VB.NET 项目很不同的。

 

（ 5 ） SS.ini 文件可能有变化 ，这是产生很多问题的根源，因此是特别要小心的！

SS.ini 是 VSS 个人配置文件，这个文件在 VSSDB/Data/../Users/[username]/ 目录。其内容主要是 SSEXP 当前项目、窗口状态等，更重要的内容是每个 VSS Folder/Project 对应的本地工作目录。

要特别注意检查在 Open From Source Control 之后 ， 这个文件中有没有多几行 。

其中 ， Web Project 肯定会改变工作目录 ， 还算正常。比如 ：

[$/]

Dir (XA-APP-LUO2K3J) = C:/MPROJECT

[$/WebProjects/Purchase1.0/Src/Purchase/PurchaseService]

Dir (XA-APP-LUO2K3J) = c:/inetpub/wwwroot/LeyserService/PurchaseService

[$/WebProjects/Purchase1.0/Src/Purchase/ApplicationUI/LeyserWeb]

Dir (XA-APP-LUO2K3J) = c:/inetpub/wwwroot/LeyserWeb

以上两个 Project 都是 ASP.NET Web Application 或者 Web Service 类型的 Project ，所以没有问题。

如果出现其他类型的 Project 工作目录也出现在这个文件中 ， 例如 ：

[$/WebProjects/WebFramework/Src/OtherFrameworks/NHibernate]

Dir (XA-APP-LUO2K3J) = C:/study/asp.net/ORM/nhibernate/src/NHibernate

[$/WebProjects/Purchase1.0/Src/Purchase/DataAccess]

Dir (XA-APP-LUO2K3J) = C:/WebProjects/Purchase1.0/Src/Purchase/DataAccess

上面这两个目录（ Nhibernate 和 Purchase.DataAccess.Order ）中并没有 Web 项目， 就说明有问题 ， 问题的原因有两种 ：

l         sln 文件中包括了根本不存在的某个目录中的 Project 的 Source Control 绑定信息。而这个 Project 是存在的，但是不是在绑定信息所描述的目录中。

l         sln 或者 etp 包含了非下级目录中的 Project ， 例如 ： C:/a/a.etp 包含一个 C:/b/b.vbproj 。

因此，一要仔细检查 sln 文件中的绑定信息，即 GlobalSection 部分；二要避免在 Solution 或者 etp 中包含其下级目录之外其他路径下的 Project 文件。

特别注意：

在调整 Solution 结构之后， Project 的存放路径、名称、所属 etp 发生变化，而 sln 文件却因为 VS.NET 的 Source Control Add-in 的 Bug 可能没有及时、正确地更新，往往就会导致问题。

与绑定有关的文件信息有哪些？它们之间是什么关系？出现问题的时候，是什么文件的什么内容与什么文件的什么内容不符了？

与绑定有关的文件信息包括：

l         Sln 文件中的 GlobalSection 信息

l         Etp 或者 proj 文件中的 scc* 信息

l         SolutionName.vssscc 或者 ProjectName.vspscc 文件中的信息

l         VSSDB/Users/username/ss.ini 文件中的工作目录信息

起关键作用、同时也最容易出问题的，其实只有 sln 文件中的 GlobalSection 信息 。

针对每个 Project ，主要是 5 个方面的信息：

SccProjectUniqueName1 = ProjName1//ProjName1.vbproj

SccProjectTopLevelParentUniqueName36 = …//.....etp

SccProjectName1 = /u0022$/Solution1/ProjName1/u0022,/u0020UAAAAAAA

SccLocalPath1 = ProjName1

SccProjectFilePathRelativizedFromConnection1 = …

出现问题的时候，就是这几项内容之间、或者其中某项内容与实际路径之间有差异。

尤其需要注意的是最后一项 SccProjectFilePathRelativizedFromConnection1 ，一般不出现，如果出现，一般都会导致问题。这项内容的出现往往伴随着 SccLocalPath=. ，这种情况下，就会出现多个项目具有相同的绑定路径的问题，参见附录中的（ 7 ）。

对于 Web 项目，还有一个描述 URL 信息的 webinfo 文件，这个文件与 sln 和 etp 之间的内容不一致也是常见问题。

另一个检查重点是 ss.ini 中的工作目录设置 ，如果出现没必要的或者错误的工作目录设置，一般就会出现绑定的问题。

在一个已经绑定的Solution中，如何正确地添加新的etp和Project？

正确的添加步骤：

（ 1 ） Add New Project

（ 2 ） Check In 那些新项目

（ 3 ）保存所有文件（主要是为了保存 sln ）

最好用 SSExp 验证一下，然后关闭 Solution 再打开，再次验证。

在一个已经绑定的Solution中，如何正确地添加已经存在的etp和Project？

步骤上与添加新的 etp 或者 Project 没有差异 （ 当然第一步是 Add Exsting Project ） 。但是 ， 如果是过去曾经绑定过的 etp 或者 Project ， 最好删除对应的 vspscc 文件，以免 RelativePath 之类的信息导致问题。

 

一种特殊情况是：如果被添加的项目已经在其他 Solution 中绑定，那就不能 Unbind ，此时可以用 Add Project From Source Control 命令来添加，不要用传统的 Add Existing Project 。

已经绑定的情况下，如何修改Project所属的etp？

为了保险 ， 不要直接 Remove 然后 Add Existing 。最佳做法：

（ 1 ） Unbind project 。然后从现有 etp 中 Remove 。

（ 2 ）删除可能存在的对应 Project 的 vspscc 文件。

（ 3 ）将 Project 的目录移动到 etp 之下！！！

（ 4 ） 在新的 etp 中 Add existing project 。

（ 5 ） Save all 然后 Check In 。

（ 6 ）关闭并再次打开。

 

在Project中添加一个Form时，需要注意什么，对绑定有何影响？

要点是：一旦集成，那么所有操作都应该在 IDE 中进行，不要再用 SSExp.exe 进行手工操作。

添加文件至 VSS DB 时，如果采用集成操作，相关文件都能自动添加或更新；否则，手工添加很可能漏掉某些资源文件，或者漏掉什么更新操作。另外，有些与用户有关的文件是不能放进 VSS 的，包括 suo,*.vbproj.user 等，手工操作很可能把这些文件也添加进去，导致用户环境互相干扰。

 

如果需要修改一个Folder的名称，对绑定有何影响？

如果按照 MSDN 的文档，这个操作将包含 20 个步骤！之后还需要很多手工操作。

不如先 Unbind 单个 Project ，在外面改好之后，再添加进来，最后 Check In 。

另：

对于文件，可在 IDE 中 Rename ，然后 CheckIn ， VSS 中的文件名将自动更新。

一个已经绑定的Solution，如何更快地Unbind？必须逐个Project地Unbind吗？

如果一切正常，可以在 VS.NET IDE 中成批 Unbind ，不需要逐个 Unbind 。

如果想要将一个绑定的Solution源代码复制到一个演示机器上，如何保证在演示机器上正确打开Solution，而且不看到任何警告或错误信息？

关键是要正确地 Unbind 。 Unbind 之后，与 Source Control 有关的文件会被删除，项目文件中有关 Source Control 有关的信息也会被删除。

Web Project的两种开发模式有什么不同？对VSS绑定有何影响？

VS.NET 管理 Web 项目文件有两种方式： File Share 和 FrontPage ，前者是 VS.NET 新提供的方法，后者是过去 Visual InterDev 的方法。

l         File Share （ 默认模式 ）：利用 wwwroot$ 共享来修改文件，其共享权限设置为： ./Administrators 和 ./VS Developers 都有 Full Control 权限。试验证明：如果是本地开发环境（ VS.NET 与 IIS 在同一台机器），即使没有这个共享也能正常打开。可见，用本地 IIS 开发时根本没有使用这个共享。

l         FrontPage ： All files are managed using the HTTP protocol. Source control requests from Visual Studio are forwarded through the FrontPage server extensions to the server installation of your source control provider (for example, Visual SourceSafe). The FrontPage access method does not support as many source control commands as File Share.  可见，两种模式的最大差别是支持的 VSS 操作命令不一样多 。 FrontPage 模式下，不能执行 Branch/Merge 等复杂操作。

注意：

尽管在集成状态下，一般都用 File Share 模式，但是 sln 或 etp 中仍然需要用 http 路径来指定包含的 Web Project ，否则用 C:/Inetpub/wwwroot/ 这样的路径将导致不同机器上无法正确打开的问题。

 

为什么在添加一个新的Web Project的时候，提示说必须提供一个URL Path，而实际上本来就是URL Path？

这应该是 VS.NET IDE 的 Bug ， 在绑定信息紊乱的时候 ， 最好不要添加新的 Project 。

 

为什么提示http://localhost/ProjectName_1这样的URL Path？

VS.NET 总是将 Web 项目的工作目录放到 wwwroot 下面，并且设置虚拟目录 。如果现在的 IIS 中已经有重名的虚拟目录，就会提示 projectName_n 样式的 URL Path 。

如果不想看到这样的提示，应事先删除本地的同名虚拟目录。

 

Web Project打开失败的常见问题和原因是什么？

最常见的问题包括：

（ 1 ） Cannot open project 之类的问题

原因是： Solution 文件（ sln ）中 GlobalSection 部分的信息紊乱，垃圾信息没有删除，或者有关工作路径的信息与实际路径不一致。

（ 2 ） VSS 中显示的 Work Folder 信息混乱

除了 Web 项目之外，其他项目的工作目录应该与 VSS 中的结构一致，但是如果 Solution 或 ETP 的结构与 VSS 中的 Folder 结构不一致 ， 导致 VSS 的 Users/username/SS.ini 中有关工作目录的信息多余或者与实际情况不一致。

（ 3 ） Web 项目的 Location 提示 http://localhost/ProjectName_1

这是因为本地 IIS 中已经存在同名的虚拟目录。避免问题的办法是在 Open From Source Control 之前，删除本地的重名虚拟目录。

（ 4 ）多个项目绑定路径相同的问题

原因是 SccLocalPath 不正确，参见附录中的（ 7 ）。

 

为了避免少出现问题，应注意：

l         千万不要重复使用 Open Source Control 打开 Solution 。这个命令对一个 Solution 只能用一次 ， 如果第一次失败 ， 一定要清理硬盘上 Get 下来的文件 ， 而且要删除 IIS VD 和物理文件。之后才能再次使用 Open From Source Control 尝试打开。

l         不要手工修改 etp 或 sln 中包含的 Project 信息，特别是 Web Project 的 http 路径不要改成 C:/Inetpub/wwwroot/ 路径。

l         不要在 sln 或者 etp 中添加其下级目录之外其他路径的项目。

 

对于常见问题的解决办法，参见附录。

References

Web Projects and Source Control Integration in Visual Studio .NET

ms-help://MS.VSCC...1033/sccvs70/html/vetchWebProjectsSourceControlIntegrationInVisualStudioNET_Convert.htm

 

附录：解决一个Solution绑定问题的步骤实录

 

以下是在使用 Open From Source Control 打开一个已经设置绑定的 Solution 时，遇到的问题和解决的详细过程：

(1) Web Project的Location问题

提示输入 Web Project 的工作拷贝的 Location 时，出现三个 Web 项目的列表，而实际上应该只有两个。
原因：其中一个 Web Project — PurchaseWeb —原先在 wwwroot 下面，后来把它的源文件调整到另一个 Web Project — LeySerWeb —下面的二级目录中，不再作为单独的 Project ，但是 sln 文件有关 Source Control 的信息却没有及时删除，成为垃圾信息。

具体步骤：

打开 sln 文件，找到如下信息：

-----------------

Global

GlobalSection(SourceCodeControl) = preSolution

SccNumberOfProjects = 56

SccLocalPath0 = .

CanCheckoutShared = false

SolutionUniqueID = {EFD7F1A3-3977-4BE8-AFFC-D33AB7D8546C}

...

SccProjectUniqueName33 = http://localhost/PurchaseWeb/PurchaseWeb.vbproj

SccProjectTopLevelParentUniqueName33 = Purchase//Purchase.etp

SccProjectName33 = /u0022$/…/Src/Purchase/ApplicationUI/PurchaseWeb/...

SccLocalPath33 = http://localhost/PurchaseWeb/

----------------

其中带有“ 33 ”字样的都是垃圾信息。用 Notepad 修改如下：

l         删除带有“ 33 ”字样的垃圾信息，包括 CanCheckoutShared = false 。

l         将最后一个 Project 的信息（标号为“ 55 ”）转移到原来“ 33 ”所处的位置。

l         将“ 55 ”改为“ 33 ”。

l         将 GlobalSection(SourceCodeControl) 下面第一行的 SccNumberOfProjects = 55 中的“ 56 ”改为“ 55 ”。

用 Task Manager 直接终止 VS.NET 之后，重新 Open From Source Control ，这个错误就没有了，仅显示两个 Web Project 的列表。

 

(2) Unable to read project file问题

重新打开时，确认 Web Project 的 Location 之后，出现错误提示： Path not found: LeyserWeb.vbproj 。

原因：在包含该项目的 etp 文件中，指定了非 URL 路径。该 ApplicationUI.etp 文件部分内容为：

        <Views>

            <ProjectExplorer>

                <File>LeyserWeb/LeyserWeb.vbproj</File> *******

                <File>PurchaseWin/PurchaseWin.etp</File>

            </ProjectExplorer>

        </Views>

        <References>

            <Reference>

                <FILE>LeyserWeb/LeyserWeb.vbproj</FILE> *******

                <GUIDPROJECTID>{4ED7777B-…54774E1}</GUIDPROJECTID>

            </Reference>

将红字部分的路径修改为 URL 地址形式：

                <File>http://localhost/LeyserWeb/LeyserWeb.vbproj</File>

这个问题得到解决。

 

(3) Path not found问题

强行终止、重新打开 sln 时，出现提示： $/WebProject/.../Microsoft.ApplicationBlocks.Data was not found. Would you like to browse for the project?

这也是因为 VS.NET 的 Bug ，没有及时更新有关的信息导致的问题。原先这个 Project 是在另一个 Folder 下面，包含在另一个 etp 中，现在调整了，结果 sln 中只有部分信息得到更新：

---------- 红字部分是没有正确更新的内容

SccProjectUniqueName44 = .. WebFramework//Src//ApplicationBlocks//Microsoft.ApplicationBlocks.Data//Microsoft.ApplicationBlocks.Data.vbproj

SccProjectTopLevelParentUniqueName44 = ..//..//WebFramework//Src//Frameworks.etp

SccProjectName44 = /u0022$/WebProjects/Purchase1.0/Microsoft.ApplicationBlocks.Data/u0022,/u0…

SccLocalPath44 = ..WebFramework//Src//ApplicationBlocks//Microsoft.ApplicationBlocks.Data

---------------

--------- 将 SccProjectName44 部分修改成：

/u0022$/WebProjects/WebFramework/Src/ApplicationBlocks/u0022,/…

---------

这个问题就解决了。

(4) Project file not found问题

强行终止、重新打开 sln 时，出现提示： File not found: Microsoft.ApplicationBlocks.Data.vbproj

原因： sln 中有关这个项目的 SccLocalPath 信息不正确，结果导致该项目在 VSS 中的工作目录单独设置，而且设置成了不正确的路径。

 

有关工作目录的设置信息保存在下面这个文件中：

//xafile/share/Project/MProject/Users/[username]/ss.ini

本来，只需要为 sln 文件所在目录设置工作目录，下级目录就会自动按照项目层次结构自动设置，不需要 ss.ini 中的单独设置。当然， Web 项目是一个例外，因为 Web 项目的工作目录总在 wwwroot 下面。对于其他项目，如果某个下级目录在 ss.ini 中存在工作目录设置信息，肯定就是有什么问题。

ss.ini 中有关工作目录的设置如下：

[$/WebProjects/WebFramework/Src/ApplicationBlocks]

Dir (XA-APP-LUO2K3J) = C:/MPROJECT/WebProjects/WebFramework/Src/ApplicationBlocks/Microsoft.ApplicationBlocks.Data

红字部分是多余的部分，出现这个错误的原因，是 sln 文件中的信息不正确：

--- sln.old

SccProjectUniqueName44 = ..//..//WebFramework//Src//ApplicationBlocks// 

          Microsoft.ApplicationBlocks.Data//Microsoft.ApplicationBlocks.Data.vbproj

SccProjectTopLevelParentUniqueName44 = ..//..//WebFramework//Src//Frameworks.etp

SccProjectName44 = /u0022$/WebProjects/WebFramework/Src/ApplicationBlocks/u0022,/…

SccLocalPath44 = ..//..//WebFramework//Src//ApplicationBlocks//Microsoft.ApplicationBlocks.Data

---

其中的红字部分是多余的。删除红字部分，然后从 ss.ini 中删除这个项目的工作目录设置，这个问题就解决了。

 

(5) Project does not exist问题

强行终止、重新打开 sln 时，出现提示： project does not exist。

这个问题的原因，是因为该 project 不在其所属 etp 的下级目录中，结果导致 ss.ini 中单独设置了工作目录，而 Open From Source Control 时， VS.NET 仍然将该 project 的文件 Get 到了 etp 文件所在目录的下级目录中（这应该也是 VS.NET 的 Bug ），当然就找不到指定的 csproj 文件了。

ss.ini 中的信息如下：

[$/WebProjects/WebFramework/Src/OtherFrameworks/NHibernate]

Dir (XA-APP-LUO2K3J) = C:/study/asp.net/ORM/nhibernate-0.0.5000.6/src/NHibernate

Sln 文件中的相关信息如下：

SccProjectUniqueName33 = ..//..//..//..//study//asp.net//ORM//nhibernate-0.0.5000.6//src//NHibernate//NHibernate-1.1.csproj

SccProjectTopLevelParentUniqueName33 = ..//..//WebFramework//Src//Frameworks.etp

SccProjectName33 = /u0022$/WebProjects/WebFramework/Src/OtherFrameworks/NHibernate/…

SccLocalPath33 = ..//..//..//..//study//asp.net//ORM//nhibernate-0.0.5000.6//src//Nhibernate

其中的红字部分就是不合适的，说“不合适”，是因为当初添加时该项目就是在 etp 所在目录之外，所以不能说是错误。但是，因为 VS.NET 没有按照指定的目录 Get ，导致项目无法打开，仍然是 VS.NET 的问题。

 

先删除 ss.ini 中错误的工作目录设置，然后手工修改 etp 文件，将 project 的路径改为 etp 下面的子目录，保存后手工 CheckIn 这个 etp 文件，就可以解决这个问题。

 

(6) sln中的垃圾信息的问题

修改一个项目的目录名可能导致 sln 文件中的垃圾信息，然后导致 ss.ini 中的垃圾信息，进而导致项目无法打开。

在看到 Purchase.DataAccess.Order 项目无法打开的提示之后，检查 ss.ini 发现一条垃圾信息：

[$/WebProjects/Purchase1.0/Src/Purchase/DataAccess/Purchase.DataAccess.Order]

Dir (XA-APP-LUO2K3J) = C:/MPROJECT/WebProjects/Purchase1.0/Src/Purchase/DataAccess/Purchase.DataAccess.Order

与其他工作目录设置垃圾信息不同的是：这条信息指向的工作目录是正确的，而且也符合整个 Solution 的层次结构！

 

检查 sln 文件，发现有两个有关 Purchase.DataAccess.Order.vbproj 的 source control 信息，其中一个是垃圾信息：

SccProjectUniqueName36 = Purchase//DataAccess//Order.DataAccess//Purchase.DataAccess.Order.vbproj

SccProjectTopLevelParentUniqueName36 = Purchase//Purchase.etp

SccProjectName36 = /u0022$/WebProjects/Purchase1.0/Src/Purchase/DataAccess/Purchase.DataAccess.Order/u0022,/u0020YEEEAAAA

SccLocalPath36 = Purchase//DataAccess//Order.DataAccess

CanCheckoutShared = false

其中，红字部分实际上已经修改为 Purchase.DataAccess.Order ，另外一条有关同一 vbproj 的信息正是修改后的路径。这应该也是 VS.NET 的 Bug 导致的问题。

删除这条垃圾信息，并调整 SccNumberOfProjects 等信息之后，这个问题就解决了。

 

(7) 多个项目绑定路径相同的问题

如果 sln 有问题，可能导致很多项目的 Server Binding 路径相同，结果是：在 Change Source Control 对话框中，这些项目不能单独选中，选中一个，其他相同绑定路径的项目也会被一起选中。

 

问题原因：

SccLocalPath 不正确，一般是 SccLocalPathxx = . ，本来应该是一个相对路径。另外，多出一个 SccProjectFilePathRelativizedFromConnection 设置。

还有一个“症状”是： vbproj.vspscc 文件中会有内容：

"PROJECT_FILE_RELATIVE_PATH" = "relative:Purchase//BusinessFacade//Pruchase.Facade.SupplierAndRep"

解决办法：

将 SccProjectFilePathRelativizedFromConnection 的内容转到 SccLocalPath ，然后删除前者，即：

SccProjectUniqueName49 = ….SupplierAndRep.vbproj

SccProjectTopLevelParentUniqueName49 = Purchase//Purchase.etp

SccLocalPath49 = .

CanCheckoutShared = false

SccProjectFilePathRelativizedFromConnection49 = Purchase//BusinessFacade//Pruchase.Facade.SupplierAndRep//

修改为：

SccProjectUniqueName49 = ….SupplierAndRep.vbproj

SccProjectTopLevelParentUniqueName49 = Purchase//Purchase.etp

SccLocalPath49 = Purchase//BusinessFacade//Pruchase.Facade.SupplierAndRep

CanCheckoutShared = false

 

另一种情况， SccLocalPath 不是句点，有内容，但是实际的项目文件不是在所属 etp 的下级目录中，结果就出现很多“ ..// ”样式的相对路径：

SccProjectUniqueName8 = ..//..//WebFramework//Src//ApplicationBlocks//Security//src//cs//Security//Security.csproj

SccProjectTopLevelParentUniqueName8 = ..//..//WebFramework//Src//Frameworks.etp

SccProjectName8 = /u0022$/WebProjects/WebFramework/Src/ApplicationBlocks/u0022,/...

SccLocalPath8 = ..//..//WebFramework//Src//ApplicationBlocks

CanCheckoutShared = false

SccProjectFilePathRelativizedFromConnection8 = Security//src//cs//Security//

对于这种情况，修改了 SccLocalPath 也不行。检查发现，这些 C# Project 的 csproj 文件中，存在 SccProjectName 信息，例如：

SccProjectName = '"$/WebProjects/WebFramework/Src/ApplicationBlocks", KGBEAAAA'

而对于 VB.NET 项目， vbproj 文件中只有很简单的信息：

SccProjectName = "SAK"

 

因此， C# 项目与 VB.NET 项目的绑定信息管理是有差异的 。

不管怎样，最好是将不是保存在 sln 文件所在目录之下的项目从 solution 中删除（当然，除了 Web 项目）；或者，将 sln 文件放到所有项目文件目录最外面的某个目录中。总之是避免出现“ ..// ”这样的相对路径。

 

提示：

l         只要出现 SccProjectFilePathRelativizedFromConnection ，肯定就是有问题！

l         要避免 etp 包含其下级目录之外路径中的 Project ，也要避免 sln 中包含其下级目录之外路径中的 etp 或者 Project 。

 

(8) SccProjectName信息丢失的问题

在 Change Source Control 对话框中，发现很多项目的 Server Binding 都显示红色波浪号。

 

退出 IDE 之后，发现 ss.ini 中多了很多 Work Folder 设置，大多数是不需要的（可以根据上级目录的工作目录确定），另有一个是错误的：

[$/WebProjects/Purchase1.0/Src]

Dir (XA-APP-LUO2K3J) = C:/MPROJECT/WebProjects/Purchase1.0/Src/Purchase.UnitTest/Purchase.Test.Order

检查 Purchase.Test.Order 下面的内容，是一个同名的 Project 。

然后检查 sln 文件，发现所有显示 Invalid 状态的项目都缺少 SccProjectName 信息。

解决办法：

l         删除 ss.ini 中的工作目录设置。

l         Check Out 并重新打开 sln 。

l         重新设置 Status 为 Invalid 的项目的 Server Binding 。此过程中，可能需要 Check Out 一些项目文件（包括 etp 文件）。

l         Check In 发生变化的 sln ， etp ， vbproj ， csproj 等文件。

 

(9) Check In提示多余文件的问题

在 IDE 环境中 Check In 时，对话框中显示出的文件列表包括一些根本没有 CheckOut 的文件。

检查发现，这些多余文件有三种可能：

l         没有设置 Server Binding 的项目文件。

l         尽管还在原先的 Project 中，但是在 VSS 中被移动到其他子目录了。

l         项目中的隐藏文件，没有被添加到 VSS 中。例如上图中的 nhibetnate-mapping-2.0.xsx 文件。

 

对于这些文件， Check In 的含义实际上是 Add to SourceSafe 。对于移动过位置的文件，应在 Check In 之后，手工删除 VSS 中原位置的垃圾文件。