使用多个 VS 解决方案和多个项目时的 NuGet 策略

Question

我正在寻找关于哪种方法被视为最佳做法的一些想法。

场景： .NET SVN 存储库由多个项目组成，其中一些共享相同的 NuGet 包。还存在多个解决方案文件，每个解决方案文件都有一个子集，有些重叠。

例子：

a.sln
--> proj1 - log4net, nunit(v1.0.0)
--> proj2 - log4net, json
--> proj3 - log4net, nunit(v1.0.0)

b.sln
--> proj2 - log4net, json
--> proj4 - nunit(v1.0.0)

当开发人员打开a.sln 并将该解决方案中所有项目的nunit(v1.0.0) 包更新为v2.0.0 时，就会出现问题。这使得proj4 的nunit 仍然在v1.0.0 上，并且假设所有二进制文件都复制到一个输出文件夹，首先构建的解决方案将确定哪个版本的nunit 可用。

方法一： 编写一个由a.sln 和b.sln 使用的项目，其唯一目的是包含所有项目的所有NuGet 引用，并将所有文件输出到一个文件夹，例如Externals。修改所有项目以手动引用此文件夹内的dll。

方法 #2： 更新软件包时要谨慎，并为每个解决方案重复该过程。

方法#3： 创建一个包含所有项目的解决方案，避免使用多个解决方案。

我有强烈的偏好，但希望获得社区反馈并保持开放的心态。

Answer 1

• 方法 #1 - 我看到的问题是它强制对其他项目进行更新，从而导致潜在的编译问题。此外，您可能有一个项目更喜欢旧版 NuGet 包

• 方法 #2 - 根据 #1，此外，除非开发人员使用其他解决方案，否则他们可能不会考虑更新它们。我们开发人员在处理带有眼罩的错误时可能会很挑剔

• 方法 #3 - 虽然从维护的角度来看稍微容易一些，但它并不能保证某些项目都使用相同的 NuGet 数据包。例如nunit 的两个不同版本。在 Visual Studio 中安装和/或更新 NuGet 包时，开发人员可以覆盖哪些项目将接收包。根据您项目的规模，一些开发人员可能不喜欢创建单体解决方案的想法（即使项目可以右键单击Unload Project），因为一般会影响性能

  李>

在我看来，方法#3 可能会更容易，因为只需一步即可将相同的软件包批量安装到您的所有项目中。 方法 #1 也很接近，但我担心您会发现，无论由于依赖关系，您都必须将 NuGet 包部署到其他项目中 - “类型 xxx 在未引用的程序集。请将其添加到引用中"。

不兼容的版本

这使得 proj4 的 nunit 仍然在 v1.0.0 上，并且假设所有二进制文件都复制到一个输出文件夹，首先构建的解决方案将确定哪个版本的 nunit 可用。

同意，这让我觉得这是一个终极问题，也是我们遇到的问题。即使您的团队习惯于到处使用 log4net 版本 X，您很有可能会遇到使用某些第三方库也需要 log4net 但版本 Y 的情况。于是版本不兼容的问题又来了。

应用程序域

如果您发现您的解决方案必须使用多个版本的第 3 方程序集进行部署，您可能需要查看子 .NET AppDomain。这个想法是，您不是将程序集部署到一个大文件夹中（旧文件可以被新文件破坏，反之亦然），而是将每个程序集绑定到特定第三方 .dll 的根文件夹和子文件夹。

您需要子 AppDomain 的原因是，即使其他程序集位于不同的文件夹中，每个 AppDomain 也不能多次加载程序集。

例如

<my app folder>
|--folder a
  |--log4net v1.dll
  |--nunit 3.dll
|--folder b
  |--log4net v2.dll
  |--nunit 4.dll

毕竟，nUnit 在运行测试时使用子 AppDomain。