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项目是一

分享到：

N 个 ASP.net DropDownList 无刷新联动菜单 | RHEL DVD光盘制作方法

• 2006-11-10 16:18
• 浏览 1030
• 评论(0)
• 查看更多