首页 文章

为什么NuGet根据您的起点不同地解析版本?

提问于
浏览
3

我作为NuGet包打包的库使用await / async,因此我需要向Microsoft.Bcl.Async添加依赖项 . 但Microsoft.Bcl.Async依赖于Microsoft.Bcl和Microsoft.Bcl.Build . 在测试项目中会发生什么,我从NuGet.org获取这些软件包的不同版本,具体取决于安装它们的顺序 .

如果我安装了Microsoft.Bcl.Async,那么NuGet会安装以下软件包:

package id="Microsoft.Bcl.Build" version="1.0.4" 
package id="Microsoft.Bcl" version="1.0.19"  
package id="Microsoft.Bcl.Async" version="1.0.165"

然后我的测试项目没有编译 .

如果我首先安装Microsoft.Bcl,NuGet将安装以下内容:

package id="Microsoft.Bcl.Build" version="1.0.10" 
package id="Microsoft.Bcl" version="1.1.6"

然后我可以安装Microsoft.Bcl.Async:

package id="Microsoft.Bcl.Async" version="1.0.165"

测试项目无法编译 .

但是如果我一个接一个地手动安装所有三个BCL项目,我得到以下内容:

package id="Microsoft.Bcl.Build" version="1.0.13" 
package id="Microsoft.Bcl" version="1.1.6" 
package id="Microsoft.Bcl.Async" version="1.0.165"

只有这样我的测试项目才能成功编译!

我一定误解了NuGet版本解析的工作原理,但是NuGet不应该将软件包解析为兼容性边界内的最新版本吗?上面的场景显示NuGet使用受支持的最小数量获取依赖版本:Microsoft.Bcl.Async 1.0.165需要Microsoft.Bcl 1.0.19或更高版本,而NuGet需要1.0.19 . Microsoft.Bcl 1.0.19需要Microsoft.Bcl.Build 1.0.4或更高版本,而NuGet需要1.0.4 . 最后,它是最古老的兼容包的组合(显然它不能正常工作) .

如果这是默认行为,那么这可以覆盖它吗?

1 回答

  • 4

    是不是NuGet应该将软件包解析为兼容性边界内的最新版本?

    没有.NuGet will actually choose the lowest major/minor version and the highest patch version . 这样做的理由是因为主要版本可能会引入重大变化,次要版本可能会引入新功能(因此引入错误的可能性更高),但补丁版本只能修复错误 .

    如果这是默认行为,那么可以覆盖它吗?

    由于您的库需要这些库的特定版本,因此只需add a version attribute到您的nuspec中相应的 dependency 节点 .

相关问题