我来分享几个亲测有效的方法，帮你精准找到到底哪个组件在请求System.Threading.Tasks.Extensions, Version=4.2.0.0：

1. 用Visual Studio自带的程序集绑定日志查看器（FUSLOGVW.exe） #

这是微软官方专门解决加载失败问题的利器，步骤超清晰：

• 以管理员身份打开Visual Studio开发者命令提示符，输入fuslogvw.exe启动工具
• 点击「设置」，选择「记录所有程序集绑定到磁盘」，指定一个日志保存文件夹
• 重新运行项目触发异常，回到工具刷新，找到对应System.Threading.Tasks.Extensions的日志条目
• 点开日志就能看到哪个程序集在请求4.2.0.0版本，甚至能看到完整的调用栈和加载路径，直接定位根源

2. 利用ReSharper的依赖分析能力 #

既然你有ReSharper，直接用它的强大分析功能：

• 在解决方案资源管理器右键点击解决方案，选择「ReSharper」→「分析」→「查看依赖关系图」
• 在依赖图里搜索System.Threading.Tasks.Extensions，就能看到所有依赖它的项目/程序集
• 还可以右键点击这个程序集，选择「查找用法」并勾选整个解决方案，能定位到所有直接或间接引用它的代码、配置文件
• 另外打开ReSharper的「解决方案分析」窗口，筛选「兼容性」警告，说不定能直接揪出版本不匹配的项目

3. 检查配置文件里的绑定重定向 #

有时候问题藏在app.config/web.config的重定向规则里：

• 全局搜索解决方案里的所有app.config和web.config，查找System.Threading.Tasks.Extensions相关的<dependentAssembly>节点
• 如果发现有指向4.2.0.0的旧重定向，或者没正确配置新版本的重定向，那就是问题所在
• 也可以在启动项目的配置里添加强制重定向，把所有版本都指向你bin里的版本，示例：

<dependentAssembly>
  <assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-[你的bin里的版本号]" newVersion="[你的bin里的版本号]" />
</dependentAssembly>

4. 用NuGet命令排查版本分布 #

某个项目可能偷偷装了旧版NuGet包，用命令快速排查：

• 打开NuGet包管理器控制台，输入Get-Package -Filter System.Threading.Tasks.Extensions -AllProjects
• 这个命令会列出所有项目里该包的版本，一眼就能看到哪个项目还在使用4.2.0.0
• 找到后直接在对应项目里更新包即可

5. 反编译可疑程序集（ILDasm） #

如果前面的方法都没找到，就反编译bin里的其他程序集：

• 打开Visual Studio开发者命令提示符，输入ildasm启动工具
• 加载你怀疑的程序集，查看「引用」节点，找到System.Threading.Tasks.Extensions的版本
• 逐个排查，总能找到那个还在请求旧版本的程序集

最后提醒下：有时候问题可能来自第三方NuGet包，它们内部依赖了旧版组件，这时候要么更新第三方包，要么用绑定重定向强制统一版本。

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