我们正在考虑为我们的软件产品之间共享的代码创建一个独特的集合。然后我们将有一个软件项目的集合。这样做是出于组织目的。是否可以使用一个解决方案来引用两个不同集合中的c＃项目？
答案 0 :(得分：4)
解决方案可以从任何地方获取文件，因为它们需要映射到loal磁盘以供Visual Studio打开它们，但是当将代码扩展到多个集合时，源代码控制集成将会中断。团队资源管理器要求所有代码都来自同一个集合，它支持所有代码来自单个团队项目的解决方案，在这些情况下，其他功能将最有效。
当您的作品分布在多个项目和/或馆藏中时，VSTS和TFS中的其他功能将更难使用。测试计划，敏捷工具，团队容量和一些其他项目纯粹是项目级别的范围。同时在多个项目中工作将使团队更难以正确使用这些工具。许多TFS顾问实施了一个＆＃34; One项目来统治他们所有＆＃34;战略因为这些原因。将所有代码和所有代码放在 one teamproject中。
XAML和2015构建引擎一次只能访问单个Project Collection中的源。因此，尽管可以设置多个本地工作空间，每个工作空间都映射到不同的团队项目和/或项目集合，但在使用TFS附带的标准构建服务器时，这不可用。其他构建工具（例如Team City）可以同时链接到多个源控制提供程序。
现在可以在同一个团队项目下拥有多个Git存储库，这种方法更有意义。
其他更困难的事情可能包括分支结构，当代码跨越集合时，管理代码的不同版本将非常困难，因为标签和分支不能交叉集合并且是在多个项目中工作时难以维护。
更好的解决方案可能是将您的共享代码放在单独的团队项目或项目集合中，但不能以Visual Studio项目的形式直接包含在其他项目中。相反，将您的共享项目存储为NuGet包，可以是私有NuGet订阅源，也可以是启用了包管理的VSTS帐户。
这样你的其他项目将更快地构建（在正确设置时可能很重要），将使用共享库的二进制版本并且具有较少的笨拙解决方案。
将所有代码放在单个团队项目或项目集合中的一个缺点是维护安全性更加困难。 TFS内部自然边界的项目集合，一个难以意外错误配置或突然出现的边界。
答案 1 :(得分：1)
正如@jessehouwing所说，解决方案可以包含来自多个馆藏的文件。每个集合都有一个本地工作区，您可以将项目/文件附加到解决方案中。
我不同意的是，这实际上是一个好主意。有10个以上的集合没有问题，每个集合用于特定目的。
例如1，对于通用项目，除非必要，否则任何人都不会更新。一个存储脚本。基本上把它想象成图书馆的书架。所有类似的东西都应该保持密切。
另一个优点是安全性，因为一个团队可以访问某些集合而不能访问其他集合。这是一个明显的加分。
至于时差，真的1-2秒对任何人都有影响。再添加一个代理，您将节省时间，因为本地构建没有任何区别。
至于标签的具体目的策略有助于克服这些问题。