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
• 浏览 383
• 评论(0)
• 相关推荐

评论

发表评论

您还没有登录,请您登录后再发表评论