IIS环境下旧ASP.NET应用System.Threading.Tasks.Extensions加载异常问题

以下是导致该异常的核心可能原因：

• 程序集绑定延迟加载与硬编码依赖冲突
  应用启动时未必立即加载System.Threading.Tasks.Extensions，后续触发特定逻辑（如异步操作、第三方组件调用）时，CLR才会尝试加载程序集。若存在第三方组件硬编码引用4.1.0.0版本，即使你配置了绑定重定向，也可能绕过规则导致版本匹配失败；另外，web.config的重定向配置可能未覆盖所有场景（如子应用配置、IIS应用池的.NET版本兼容限制）。

• IIS应用池回收引发的程序集缓存异常
  IIS应用池定期回收后，CLR的程序集缓存可能出现异常。重启应用时程序集从本地bin目录正常加载，但回收后CLR可能优先从全局程序集缓存（GAC）查找旧版本——若服务器GAC中存在4.1.0.0版本的System.Threading.Tasks.Extensions，就会触发版本不匹配的错误。

• 部署文件被意外覆盖
  编译时指定了4.6.28619版本，但部署后可能存在旧版本程序集被覆盖的情况：比如自动部署脚本、CI/CD流程混入旧文件，或者同应用池的其他应用交叉污染了程序集文件。

• .NET Framework版本兼容性问题
  基于.NET Framework 4.x的旧ASP.NET应用，System.Threading.Tasks.Extensions在不同框架版本中的内置行为有差异。若服务器安装了特定.NET Framework更新，CLR可能优先使用系统自带的程序集版本，而非你部署的版本。

• 检查服务器GAC并强化绑定重定向
  运行gacutil /l System.Threading.Tasks.Extensions查看是否存在4.1.0.0版本，若存在可考虑移除（需确认不影响其他应用），或在web.config中强制绑定到目标版本：

  <configuration>
    <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
          <assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
          <bindingRedirect oldVersion="0.0.0.0-4.6.28619" newVersion="4.6.28619" />
        </dependentAssembly>
      </assemblyBinding>
    </runtime>
  </configuration>
  

  确认该配置未被machine.config或子应用配置覆盖。

• 监控应用池回收行为
  查看IIS应用池的回收设置，确认异常是否在回收时间点发生。可临时禁用定期回收测试，或调整回收策略；同时确保bin目录下的System.Threading.Tasks.Extensions.dll权限正常，不会被回收清理操作影响。

• 验证部署文件完整性
  部署后检查bin目录下System.Threading.Tasks.Extensions.dll的版本：右键文件→属性→详细信息，确认版本为4.6.28619。排查是否有自动更新、同步脚本会替换该文件。

• 排查第三方组件间接依赖
  使用dotnet list package --include-transitive命令（或Visual Studio依赖项面板），检查应用引用的第三方包是否间接依赖4.1.0.0版本的System.Threading.Tasks.Extensions。

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