背景

之前同事问到过1个关于nuget包被多层引用后,最终生效的版本的问题。当时通过在项目中重新安装了一次nuget包解决了。
现在来重新复盘一下当时的场景,顺便把这种场景下nuget处理逻辑分享给大家。

常见的引用关系进行梳理:

  • 其中MyApp是我们的应用程序项目。
  • MyLibA、MyLibB等是依赖的类库(基础组件、其它组SDK)。
  • PackageX是最终要观察的nuget包。

场景A:这是我们最常用的情况,编译后MyApp目录下PackageX的版本是v1.0

preview - nuget使用经验:复杂依赖关系下的包版本问题

场景B:这种情况大家应该也经常遇到:依赖的两个类库MyLibA和MyLibB,而它们俩对PackageX的依赖版本是不一致的。这种情况下MyApp编译后输出的时PackageX的v2.0版本,这是由于【NuGet 将使用满足所有版本要求的最低版本】。
preview - nuget使用经验:复杂依赖关系下的包版本问题

场景C:这种情况比较有迷惑性,大家看一下最终MyApp编译后PackageX的版本是多少?答案是v1.0。
preview - nuget使用经验:复杂依赖关系下的包版本问题

这里就是一开始被同事问到的那种场景。如果参考场景B的情况,则应该输出v2.0版本的PackageX。但是此时nuget则采取了“最近优先”的策略,即选择最靠近应用程序的那个包的版本。也正是这个原因,我们可以直接在MyApp项目中添加所需版本的PackageX包,然而这种办法是治标不治本的。

场景D:这是场景B和场景C的综合情况。根据以上规律可知:MyApp的编译输出是v3.0的PackageX包。
preview - nuget使用经验:复杂依赖关系下的包版本问题

总结一下nuget的包依赖解析策略:

  • 引用层级相同时,NuGet 将使用满足所有版本要求的最低版本;
  • 引用层级不同时,NuGet 将选择最接近应用程序的包。

结语

以上几种场景基本涵盖了平时能够遇到的引用依赖关系,更多更复杂的情况可能会是分支更多、引用关系更深。
如果遇到不符合预期的情况,大家可以按照上图的思路,先把引用关系确定好,再结合nuget的包依赖解析策略就能够把问题解决掉。

nuget使用经验:复杂依赖关系下的包版本问题

nuget使用经验:复杂依赖关系下的包版本问题插图