如何判断NuGet获取的DLL是否属于.NET Framework 4.8及相关疑问

核心问题背景 #

有大量以System.或Microsoft.为前缀的NuGet包，部分属于.NET Framework，但多数不是。需要快速判断从NuGet获取的some.dll（版本x.y）是否属于.NET Framework 4.8，以此确定部署时是否需要包含该DLL。由于.NET Standard、.NET Core、.NET及传递依赖的存在，情况复杂。

基础结论 #

无需过度纠结：

• 客户侧运行所需的文件都会被自动复制到构建输出目录
• nuget.org上的包均不属于.NET Framework 4.8，部署时需要随应用交付

获取.NET Framework 4.8原生程序集列表的方法 #

• 右键项目引用→添加→程序集，可直接查看框架自带的程序集
• 使用新SDK风格的.csproj文件，能查看详细的依赖关系图

传递依赖相关疑问解答 #

1. 为何部分NuGet包标注兼容.NET Framework却无对应框架的文件？ #

这类包（比如标注兼容.NET Framework 4.5的System.Threading.Tasks）主要是为.NET Core/.NET Standard库设计的，用于满足跨平台库的依赖声明需求。在.NET Framework项目中引用这类包其实没有实际意义——因为.NET Framework本身已经自带了这些程序集，NuGet包仅作为依赖传递的桥梁，不会向输出目录复制文件。

2. 为何System.Net.Http既是.NET Framework 4.8原生程序集，又有对应的NuGet包？添加依赖后为何输出目录没有该DLL？ #

• NuGet版本的System.Net.Http确实包含更新的功能或修复，但.NET Framework项目会优先使用框架自带的程序集，默认不会替换为NuGet包版本。
• 即使添加了System.Net.Http 4.3.4或依赖它的Refit 7.0.0，构建输出中没有该DLL的原因是：针对.NET Framework的部分NuGet包版本仅作为依赖占位符，或者项目默认配置优先使用框架原生程序集。如果需要强制使用NuGet包版本，需通过修改app.config的绑定重定向（bindingRedirect）或调整.csproj中的PrivateAssets等配置实现。

内容的提问来源于stack exchange，提问作者tomwaitforitmy