Visual Studio 2015 多解决方案策略 (TFS)答案

【问题标题】：Visual Studio 2015 multiple solutions strategy (TFS)Visual Studio 2015 多解决方案策略 (TFS)
【发布时间】：2017-07-30 06:11:37
【问题描述】：

当一个解决方案中的一些项目引用另一个解决方案中另一个项目的程序集时，最好的策略是什么。

- Solution 1
-- Proj1
-- Proj2
- Solution 2
- OtherProj 1
- Solution 3
- FooProj1
- FooProj2

例如，如果 OtherProj、FooProj1 和 FooProj2 使用 Proj1 或 Proj2 程序集。

现在我必须构建例如 Proj1 并手动将该程序集复制/粘贴到解决方案 2 和解决方案 3 中的解决方案文件夹中。我不能直接引用，因为这将使用本地路径，如果我通过源代码控制 (TFS) 签入，我的同事会收到我的本地路径（这就是为什么我们在解决方案文件夹中复制/粘贴，以便路径始终是相对的)。

我们考虑的是添加一个构建后事件并将程序集复制到服务器 \myserver\assemblies\relaase\Proj1.dll 上的共享文件夹，然后在我们的解决方案/项目中引用这些文件。

这是一个好策略吗，因为它也适用于源代码控制，或者还有其他策略可以工作吗？

（在 Visual Studio 中存在共享项目之类的东西，但我认为这更多是针对单个解决方案但多个平台而不是共享）

【问题讨论】：

一旦你的代码库变得足够大，它会让单个 SLN 文件变得难以管理。此时，您需要编写和维护一个 MSBUILD “.proj” 文件，以便以正确的顺序构建所有项目。如果您这样做，您的项目可以从它们构建的地方引用这些 DLL。您不需要使用绝对文件路径进行引用 - 您应该使用相对路径（这是创建对另一个程序集的引用时的默认设置，因此您不需要在此处执行任何特殊操作）。

【解决方案1】：

您应该将每个项目/解决方案的输出发布为 Nuget 包并依赖这些包。

将项目或解决方案的输出打包为 Nuget 包非常容易，其中包含大多数内置功能。NuGet 存储库可以是网络共享，也可以使用托管服务（MyGet、VSTS/TFS ，其他人）。

【讨论】：

发布 Nuget 包对于 CI 构建来说很好，但是当您需要在一个解决方案 (SolutionA) 中进行更改同时在另一个解决方案 (SolutionB) 中工作时会怎样呢？除了用本地引用临时替换 SolutionB 中的 Nuget 包引用（脖子疼，并且会意外提交该本地引用），还有哪些其他选择？
您将每个解决方案视为松散耦合的第三方包。您所描述的是代码的紧密耦合。不是一个好习惯...
这与耦合无关。它与您正在开发的开发有关，例如，同时使用它的库和应用程序。您需要在库中进行更改并立即在应用程序中查看/使用它们。发布到 Nuget 存储库是一把大锤，如果 Nuget 不支持类似于 Maven 的 SNAPSHOT 版本的东西，这尤其痛苦。如果 Nuget 拥有它，那么在每个构建中发布该库至少是可行的。
推荐使用包管理来管理依赖。您可以进行更改并将其发布到自动化管道中，只需几分钟即可完成。如果您需要更紧密的周转，您可以添加本地 Nuget 包存储库并在那里发布包。

【解决方案2】：

VS 扩展，NuGet Reference Switcher 是针对这种情况的一种解决方案。从它的描述来看：

NuGet Reference Switcher 是一个 Visual Studio 扩展，它自动将 NuGet 程序集引用切换到项目引用，反之亦然。这在开发引用自己的 NuGet 包的应用程序时很有用。

【讨论】：