VSS与VS.NET IDE

 很多人喜欢在VS.NET IDE中集成Source Control，以下是一些有关在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中原位置的垃圾文件。