我作为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。最后，它是最古老的兼容包的组合（显然它不能正常工作）。
如果这是默认行为，那么可以覆盖它吗？
答案 0 :(得分：4)
是不是NuGet应该将软件包解析为兼容性边界内的最新版本？
没有。 NuGet will actually choose the lowest major/minor version and the highest patch version。这样做的理由是因为主要版本可能会引入重大变化，次要版本可能会引入新功能（因此引入错误的可能性更高），但补丁版本只能修复错误。
如果这是默认行为，那么可以覆盖它吗？
由于您的库需要这些库的特定版本，因此只需add a version attribute到您的nuspec中相应的dependency个节点。