背景
之前同事问到过1个关于nuget包被多层引用后，最终生效的版本的问题。当时通过在项目中重新安装了一次nuget包解决了。
现在来重新复盘一下当时的场景，顺便把这种场景下nuget处理逻辑分享给大家。
常见的引用关系进行梳理：
- 其中MyApp是我们的应用程序项目。
- MyLibA、MyLibB等是依赖的类库（基础组件、其它组SDK）。
- PackageX是最终要观察的nuget包。
场景A：这是我们最常用的情况，编译后MyApp目录下PackageX的版本是v1.0
场景B：这种情况大家应该也经常遇到：依赖的两个类库MyLibA和MyLibB，而它们俩对PackageX的依赖版本是不一致的。这种情况下MyApp编译后输出的时PackageX的v2.0版本，这是由于【NuGet 将使用满足所有版本要求的最低版本】。
场景C：这种情况比较有迷惑性，大家看一下最终MyApp编译后PackageX的版本是多少？答案是v1.0。
这里就是一开始被同事问到的那种场景。如果参考场景B的情况，则应该输出v2.0版本的PackageX。但是此时nuget则采取了“最近优先”的策略，即选择最靠近应用程序的那个包的版本。也正是这个原因，我们可以直接在MyApp项目中添加所需版本的PackageX包，然而这种办法是治标不治本的。
场景D：这是场景B和场景C的综合情况。根据以上规律可知：MyApp的编译输出是v3.0的PackageX包。
总结一下nuget的包依赖解析策略：
- 引用层级相同时，NuGet 将使用满足所有版本要求的最低版本；
- 引用层级不同时，NuGet 将选择最接近应用程序的包。
结语
以上几种场景基本涵盖了平时能够遇到的引用依赖关系，更多更复杂的情况可能会是分支更多、引用关系更深。
如果遇到不符合预期的情况，大家可以按照上图的思路，先把引用关系确定好，再结合nuget的包依赖解析策略就能够把问题解决掉。