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的{{1}}仍然在nunit上，并假设所有二进制文件都复制到一个输出文件夹，首先构建的解决方案将确定v1.0.0的哪个版本可用。

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

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

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

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

Answer 1

方法＃1 - 我看到的问题是它强制更新到其他项目，导致潜在的编译问题。此外，您可能有一个项目更喜欢旧的NuGet包
方法＃2 - 按照＃1，此外，除非开发人员跨越其他解决方案，否则他们可能不会考虑更新它们。在处理
方法＃3 - 虽然从维护角度来看稍微容易一些，但并不能保证某些项目都使用相同的NuGet数据包。例如两个不同版本的 nunit 。在Visual Studio中安装和/或更新NuGet包时，开发人员可以覆盖哪些项目将接收包。根据项目的规模，一些开发人员可能不喜欢创建单一解决方案的想法（即使项目可以右键单击卸载项目）由于一般性能影响

在我看来，方法＃3 可能更容易，因为只需一步即可将相同的软件包大量安装到您的所有项目中。 方法＃1 也接近但我担心你会发现你必须将NuGet包部署到其他项目中，而不管是因为依赖 - ＆＃34; Type xxx在未引用的程序集中定义。请将其添加到参考文献＆＃34; 。

不兼容的版本

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

同意，这对我来说是最终的问题，也是我们遇到的问题。即使你的团队在任何地方使用说log4net版本 X 都有纪律，你很可能遇到使用某些第三方库也需要log4net但版本 Y 的情况。因此，不兼容版本的问题再次出现。

应用程序域

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

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

e.g。

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

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

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

1 个答案:

不兼容的版本

应用程序域