背景介绍
nuget是.net平台有效的包管理工具，相信每个C#开发者对它都不陌生。
本文我们来探究一下nuget对不再使用的dll文件的处理策略，分为如下2个场景：
-
场景A：包A1.0原来包含Newtonsoft.Json.dll，后来更新到包A2.0时不再包含此dll。现在项目中升级包A到2.0，nuget会如何处理Newtonsoft.Json.dll文件？
-
场景B：包A1.0和包B1.0都包含Newtonsoft.Json.dll，并在项目中同时安装了这2个包。现在卸载包B，nuget会如何处理Newtonsoft.Json.dll文件？
下面结合现有项目，验证上述场景看看：
场景A验证
说明：xxx.MQ就代表包A；xxx.MQ.2.0.36.6版本包含Newtonsoft.Json.dll，xxx.MQ.2.0.36.7版本不包含Newtonsoft.Json.dll；
执行nuget包升级操作后的变化对比如下：
根据上图验证效果，可以看到nuget从csproj文件中移除了Newtonsoft.Json.dll。这种情况其实是符合预期的，因为对dll文件确实是不再引用了。然而，如果考虑到其它包包含Newtonsoft.Json.dll时，nuget会怎么处理呢？看下图：
经过上图验证，可以看到nuget还是把Newtonsoft.Json.dll移除了。虽然它是通过xxx.3rd包安装引入的，那也不行。
场景B验证
说明：xxx.3rd就代表包A，xxx.MAC代表包B；
执行卸载包B操作后的效果如下：
可见卸载包B时，直接把Newtonsoft.Json.dll文件从csproj项目文件中移除，也是忽略了包A对Newtonsoft.Json.dll的依赖。
上述场景造成的直接影响就是：代码中依赖的Newtonsoft.Json的地方，nuget操作后编译不通过了。当然临时的解决办法可以reinstall所需的包，但你不觉得这样的操作不是那么优雅么？
总结
由上述探究可见，nuget包管理工具对dll文件的管理虽然提供了方便，但是在某些场景下还是会发生不符合预期的情况。如果恰好开发人员再排查不严格，那么甚至会造成dll版本错乱，进而引发更严重的问题。
我们回过头思考下以上问题的根源是什么？答案是最小单位的设计！这种模式下的nuget直接操作管理csproj中dll文件的具体路径。
如果我们把nuget包整体作为最小单位来维护管理呢？那么生成项目时，编译器就约定的路径下以nuget包为单位定位dll文件，由于避免了琐碎的dll文件路径管理，因此就压根不存在dll混乱的问题。
具体如何操作呢？请看微软推出的nuget升级版：PackageReference！
-
项目文件中的包引用：https://docs.microsoft.com/zh-cn/nuget/consume-packages/package-references-in-project-files
-
从 packages.config 迁移到 PackageReference：https://docs.microsoft.com/zh-cn/nuget/consume-packages/migrate-packages-config-to-package-reference