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

本文关键字：NuGet 项目 策略 解决方案 VS | 更新日期: 2023-09-27 18:21:24

我正在寻找一些关于哪种方法被认为是最佳实践的想法。

场景：.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可用。

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

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

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

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

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

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

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

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

在我看来，方法#3可能更容易，因为可以一步将同一个包大规模安装到所有项目中方法#1也很接近，但我担心您会发现，由于依赖关系，您将不得不将NuGet包部署到其他项目中-"类型xxx是在未引用的程序集中定义的。请将其添加到引用中"。

不兼容的版本

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

同意，我觉得这是我们遇到的终极问题。即使您的团队在任何地方都严格使用log4net版本X，您也很可能会遇到使用某些第三方库也需要log4net但版本Y的情况。因此，不兼容版本的问题再次出现。

AppDomains

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

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

例如

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

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

相关文章：