我继承了一个非常混乱的VSS数据库，我需要清理它。在我完成重组之前，我想得到一些指导，所以我不会像前一个人那样犯错。我将把一切都移到一个新的VSS实例并重新开始。历史信息不是问题，因此可以理解，全新安装不包括先前版本的历史记录。 （如果需要，可以使用当前的VSS数据库。）
我们目前正在使用Visual Studio 2005和Visual Source Safe 2005.我们将转向VS2010，也许是TFS，但首先是第一步。
我们有三个ASP.NET产品，每个产品共享多个库。这是项目的基本结构：
PRODUCT 1
References:
Library 1
References:
Library 4
Library 5
Library 2
Library 3
PRODUCT 2
References
Library 1
References:
Library 4
Library 5
Library 3
Library 6
PRODUCT 3
References
Library 5
Library 3
作为第一步，我从VSS获得了所有产品和库“Unbound”，并按如下方式将它们组织在文件夹中。 （有3个开发人员，我们都会在我们的机器上设置相同的文件夹结构。）
C:\Source\Products\Product1
C:\Source\Products\Product2
C:\Source\Products\Product3
C:\Source\Libraries\Library1
C:\Source\Libraries\Library2
...
C:\Source\Libraries\Library5
每个产品和每个库都有自己的解决方案;项目引用用于所有引用的库。例如，PRODUCT 1的解决方案包括库1,2,3,4和5的项目引用。库1的解决方案包含库4和5的项目引用，依此类推。在这一点上，一切都在建立。
问题：PRODUCT 1的常见做法是包含图书馆4和5的项目参考，即使它没有直接引用它们（但它的一个参考项目确实如此）？
我计划在VSS中设置并行结构：
$\Prodcuts\Product1
...
$\Libraries\Library5
问题：这是一个使用的逻辑结构吗？如果没有，我应该做些什么。
提前感谢您的意见。
Darvis
答案 0 :(得分：1)
问题：PRODUCT 1的常见做法是包含项目 库4和5的参考文献，即使它没有引用它们 直接（其中一个参考项目确实如此）？
是的，它甚至是某些任务所需要的，例如code analysis in VS2010。无论如何，构建过程将排除任何直接未使用的引用（不是不清除它的原因，但是支持并非所有项目引用都在构建项目时直接使用）。
如果你在VB.NET中工作，你可以自动清理引用（但是你可以很容易地破坏代码分析功能，而且我遇到了它不能正常运行的情况），在C＃中清理项目引用的能力不是内置（某些（非免费）插件就像Resharper）
一样问题：这是一个使用的逻辑结构吗？如果没有，我应该做些什么。
（也许它应该是programmers上的一个单独的问题，因为它有点主观，但无论如何我都会回答:)）
我的逻辑中没有任何问题。我个人不拆分库项目和可执行项目。它们只是项目。这真的是个人偏好的问题，其他人会将其分解为客户，平台等。但只要人们能够看到你正在做的事情背后的逻辑，我认为你在使用它时不会遇到任何问题VSS。