c# - .Net Core 中 NU1605 警告/错误的可能解决方法

Question

发布 .net 核心控制台应用程序 (.Net Core 3.1) 以进行发布时，会发出类似于以下内容的许多错误。

检测到包降级：System.Threading 从 4.3.0 到 4.0.11。直接从项目中引用包以选择不同的版本。
ProjectABC.Services -> log4net 2.0.8 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Threading (>= 4.3.0)
ProjectABC.Services -> log4net 2.0.8 -> System.Threading (>= 4.0.11)

我知道在这种情况下 nuget 解析为较小的版本（4.0.11），即使它打破了其他依赖项（> = 4.3.0），因为最近获胜的概念。

是否有任何设置或配置来解决满足所有条件的最新版本？
在这种情况下，版本 4.3.0 是 >= 4.0.11 和 >= 4.3.0
不这样做有什么好处，而是像现在这样用最近的胜利来解决？

大多数解决方案似乎都将新版本的依赖项直接添加到项目中以修复错误。因为它满足最近获胜规则。但是，这似乎维护起来很麻烦，并且如果项目不直接需要不需要的依赖项并且 log4net（在此示例中）曾经被删除或替换，则很容易意外地留下不需要的依赖项。

可能的解决方法

其他一些建议似乎包括更改配置以不将“NU1605”警告视为错误，或将目标运行时设置为可移植（目前我正在为 win-x64 构建）。

从“将警告视为错误”输入中删除“NU1605”警告后，我无法让 VS 保存配置，并且手动更改 .csproj 文件没有效果。
所以我假设有技术原因需要在发布时将这些警告视为错误？

将目标运行时设置为 Portable 似乎确实可以阻止在发布时产生错误。我对此的理解是，在运行时，错误版本的依赖项仍将基于最近获胜使用，警告和错误只会被跳过，尽管完整编译被延迟。因此，如果在 (4.0.11) 和 (4.3.0) 之间将组件添加到所需的依赖项中，那么一切都可能正常工作或中断。我对此的理解准确吗？

我试图回答的主要问题是。
是否有任何替代方法可以直接将较新版本的依赖项添加到项目中，这仍然会导致在编译时解析正确的版本？
将目标运行时更改为可移植的实际修复错误还是将其延迟到运行时？

标签： c#.net-corenuget