Question

我有一个类库项目，由Visual Studio 2017中的两个不同解决方案共享。解决方案映射在两个不同的工作区中。我无法找到在两种解决方案中将共享项目置于源代码管理下的方法。有什么建议吗？

Answer 1

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

你不能做你要求做的事情 - 即使你能做到，你也不应该这样做。您不想分叉源代码并维护它的两个副本。您想要做的是以下之一：

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

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

选项2没问题，但它有点笨拙。

选项3是管理跨项目依赖项的首选现代方法。我强烈建议您考虑实施此模式。如果采用此模式，则再次可以接受维护多个团队项目 - 您有一个团队项目充当共享组件的发布者，另一个充当消费者。这足以让他们彼此独立，因此是多个团队项目的可接受候选人。

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

Answer 2

虽然我同意丹尼尔的观点，认为这可能是一个坏主意，并且有其他选择，但它完全可能;但是有一个限制：每个工作区必须有自己的硬盘驱动器上共享项目的副本，他们可以共享服务器上的远程副本。这非常类似于分布式源代码控制模型，可以正常工作。

要使其工作，首先要创建一个工作区并在本地映射文件夹：

 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的更改将直接影响SolutionA和SolutionB。但在本地，每个解决方案都有自己的本地挂起更改等。

只要两个团队项目都在同一个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项目并构建＆amp;将NuGet包发布到VSTS帐户的VSTS包管理订阅源。向SolutionA和SolutionB添加NuGet引用。这样，Common的二进制文件在SolutionA和SolutionB之间共享，但常见的是独立维护。这样，以与SolutionB不同的节奏更新SolutionA也更容易（这也是此解决方案的最大缺陷）。

Git＆amp;子模块/子树

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

MonoRepo / One Project To Rule The All

将所有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软件包管理功能，您可以轻松地跨多个项目共享Common项目，甚至可以在将来使用其他VSTS帐户。这是最可靠的解决方案。

如果您需要能够在任一解决方案中编辑文件，我强烈建议您查看 Git子树或 Git子模块。在任何情况下，Git都是未来，这些功能将使您能够以更容易维持的方式实现您的需求。他们的确有一个陡峭的学习曲线。

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

2 个答案:

替代

注意

建议