无法加载程序集：如何确定bindingRedirect的正确newVersion？

针对你遇到的程序集加载错误，下面是具体的诊断和解决思路：

1. 识别使用非4.2.0.0版本System.Net.Http的包 #

• Visual Studio内置依赖查看：在解决方案资源管理器中，展开项目的「依赖项」→「NuGet」，找到System.Net.Http，右键选择「查看依赖关系」，可看到所有直接/间接依赖它的包及各自要求的版本。
• 查看项目配置文件：
  • 传统.NET Framework项目：打开packages.config，搜索System.Net.Http查看是否有其他版本条目；同时检查项目文件（.csproj）中的<Reference>节点，确认程序集版本。
  • .NET Core/.NET 5+项目：直接查看.csproj文件里的<PackageReference>节点，或通过「NuGet包管理器」的「已安装」标签，查看所有包的依赖详情。
• 命令行工具：在项目根目录运行dotnet list package --include-transitive，输出完整依赖链后搜索System.Net.Http，即可找到所有依赖它的包及对应版本要求。

2. 辅助排查工具（含Visual Studio支持） #

• Visual Studio原生工具：
  • NuGet依赖关系图：右键项目→「管理NuGet程序包」→「依赖项」标签，点击「查看依赖关系图」，直观展示包的依赖层级和版本冲突。
  • 构建日志：在Visual Studio中开启「详细」级别的构建日志（工具→选项→项目和解决方案→构建并运行→MSBuild项目构建输出详细程度设为「详细」），构建时会输出程序集绑定的详细过程，从中可找到版本不匹配的线索。
• 程序集绑定日志查看器（Fuslogvw.exe）：Windows自带工具，勾选「记录绑定失败」后重现错误，可生成详细日志，定位具体哪个包在请求非4.2.0.0的版本。
• 反编译工具：用ILSpy或dnSpy打开项目输出目录下的程序集，查看其引用的System.Net.Http版本，直接定位冲突包。

3. 找到冲突包后的处理方案 #

bindingRedirect是常用解决方案，但并非唯一选择，需根据场景判断：

• 优先尝试版本对齐：若冲突包Y依赖的版本与4.2.0.0的API兼容，可通过bindingRedirect统一版本。在app.config/web.config中添加：

  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="Y依赖的版本号" />
  </dependentAssembly>
  

  也可反过来让Y依赖的版本重定向到4.2.0.0，前提是API兼容。
• 更新冲突包：若bindingRedirect引发兼容性问题，尝试更新包X或包Y到彼此兼容的版本，从根源解决冲突。比如找同时支持4.2.0.0的包Y版本，或升级X到包Y依赖的版本。
• 注意.NET Core/.NET 5+特性：这类项目默认无需手动配置bindingRedirect，框架会自动处理依赖统一。若仍出错，检查是否有包强制指定旧版本，或清理项目缓存（删除bin/obj目录后重新dotnet restore）。

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