一个 VSTS 项目可以映射到不同的本地工作空间吗？

Question

我有一个类库项目，由 Visual Studio 2017 中的两个不同解决方案共享。这些解决方案映射到两个不同的工作区。在这两种解决方案中，我都找不到在源代码控制下获取共享项目的方法。有什么建议吗？

Answer 1

我假设您有两个独立的团队项目，每个项目都有自己的 TFVC 存储库。在其中一个团队项目（例如 TPA）下，您有一个公共库，您希望与位于团队项目 B (TPB) 中的解决方案共享该库。

你不能做你要求做的事——即使你能做，你也不应该做。您不想分叉源代码并维护它的两个副本。您要执行以下操作之一：

1. 映射包含所有团队项目的单个工作区并使用相对 参考路径。这不是很好，理想情况下，每个团队项目都被认为是一个完全独立的实体。
2. 将所有内容放在一个团队项目中，并为所有内容维护一个工作区。
3. 将共享组件转换为 NuGet 包并使用Package Management feed。然后，共享组件的每个使用者都可以引用一个通用 NuGet 包。

我想说#1 已经作为一个选项被排除在外。每个团队项目都应该是一个独立的实体，它们之间没有任何共享。既然你有共享的东西，你就选择了错误的组织结构。停止使用多个团队项目。

选项 2 还可以，但有点笨拙。

选项 3 是管理跨项目依赖项的首选现代方式。我强烈建议考虑实施这种模式。如果您采用这种模式，那么维护多个团队项目再次变得可以接受——您有一个团队项目充当共享组件的发布者，另一个充当消费者。这已经足够孤立，可以认为它们彼此独立，因此是多个团队项目的可接受候选者。

值得注意的是，该领域大多数专家的现代思想是，为所有相关应用程序维护一个团队项目是正确的方法。我见过拥有数百名成员和数十个应用程序的团队使用一个组织良好的团队项目没有任何问题。

Answer 2

虽然我同意 Daniel 的观点，即这可能是一个坏主意并且有替代方案，但这是完全可能的；但是有一个限制：每个工作区必须在您的硬盘上拥有自己的共享项目副本，他们可以在服务器上共享远程副本。这与分布式源代码控制模型非常相似，可以正常工作。

要完成这项工作，首先创建一个工作区并在本地映射文件夹：

 Workspace 1
 $/Common/           => c:\src\1stProject\Shared
 $/ProjectA/Solution => c:\src\1stProject\SolutionA

然后创建第二个工作区：

 Workspace 2
 $/Common/           => c:\src\2ndProject\Shared
 $/ProjectB/Solution => c:\src\2ndProject\SolutionB

这样，两个项目共享相同的服务器位置，对 Shared 所做的更改将直接影响解决方案 A 和解决方案 B。但在本地，每个解决方案都有自己的本地待定更改等。

只要两个团队项目位于同一个 TFS 项目集合中，此解决方案就可以工作。

唯一的限制是这些项目不能放在彼此的子文件夹中，所以你不能这样做：

 Workspace 1
 $/Common/           => c:\src\1stProject\SolutionA\Shared
 $/ProjectA/Solution => c:\src\1stProject\SolutionA

两个工作区也不能映射到同一个本地文件夹：

 Workspace 1
 $/Common/           => c:\src\Shared
 $/ProjectA/Solution => c:\src\1stProject\SolutionA

 Workspace 2
 $/Common/           => c:\src\Shared
 $/ProjectB/Solution => c:\src\1stProject\SolutionB

替代方案

Nuget

不直接使用共享源，而是将 NuSpec 添加到 Common 项目，然后构建 NuGet 包并将其发布到 VSTS 帐户的 VSTS 包管理源。添加对解决方案 A 和解决方案 B 的 NuGet 引用。这样，Common 的二进制文件在 SolutionA 和 SolutionB 之间共享，但 common 是独立维护的。这样，以不同于解决方案 B 的节奏更新解决方案 A 也更容易（这也是此解决方案的最大缺陷）。

Git 和子模块/子树

将 TFVC 存储库转换为 Git 存储库。这样，您可以使用 Subtree 或 Submodules 直接从 SolutionA 存储库和 SolutionB 存储库引用 Common。

MonoRepo/一个统治他们的项目

将所有 TFVC 存储库合并到一个 TFVC 存储库中，这样两个项目就可以轻松地存在于同一个工作区中。从技术上讲，这不需要将两个项目放在同一个工作区中，但它更容易。它会产生与上述非常相似的解决方案：

 Workspace Single
 $/Project/Shared    => c:\src\Shared
 $/Project/SolutionA => c:\src\1stProject\SolutionA
 $/Project/SolutionB => c:\src\2ndProject\SolutionB

将产生与以下跨项目布局相同的结果：

 Workspace Single
 $/CommonProject/    => c:\src\Shared
 $/ProjectA/         => c:\src\1stProject\SolutionA
 $/ProjectB/         => c:\src\2ndProject\SolutionB

注意

在任何跨项目设置中，Visual Studio 和 VSTS 的 UI 都会与您抗衡。 VSTS 团队一直致力于使单个团队项目能够跨帐户移植。为了做到这一点，需要在某些时候删除这些功能。例如，VSTS 构建中的 UI 不会在源选择器中显示任何其他团队项目。如果您手动键入路径，它们将起作用（只要您将构建配置为具有集合级别范围）。

建议

Nuget 解决方案是您尝试解决的问题类型最可靠的解决方案。 VSTS 包管理功能将允许您轻松地跨多个项目共享公共项目，甚至跨其他 VSTS 帐户是您将来想要的。这是最可靠的解决方案。

如果您需要能够在任一解决方案中编辑文件，我强烈建议您查看 Git Subtrees 或 Git Submodules。无论如何，Git 是未来，这些功能将使您能够以更容易维持的方式实现您的需求。不过，它们确实具有陡峭的学习曲线。