迁移Azure Function V1到.NET6版V4报CallContext加载错误如何解决

你遇到的Could not load type 'System.Runtime.Remoting.Messaging.CallContext' from assembly 'mscorlib'是运行时不兼容导致的：.NET 6属于新一代跨平台.NET栈，已经完全删除了.NET Framework专属的System.Runtime.Remoting系列API。你直接在.NET 6环境下加载编译目标为.NET Framework 4.8的业务程序集，只要代码（包括.NET Framework版本EF6的内部依赖）用到了Remoting下的CallContext逻辑，就会触发这个类型加载异常，这不是配置错误，是两个运行时的核心断层，没有黑科技可以直接绕过。

你现有EF6数据库优先的代码不需要全量重写，根据你的需求选下面任意一个方案即可：

• 方案1：直接使用.NET Framework 4.8创建Azure Function V4（最适配你当前场景，业务代码零修改）
  操作步骤：

  1. 安装最新版Visual Studio 2022，勾选「Azure开发」工作负载，确保本地Azure Functions工具为最新版本
  2. 新建Azure Functions项目时，函数版本选择「Azure Functions v4 (.NET Framework)」，不要选择面向.NET 6的进程内/隔离工作模式选项
  3. 把原有V1项目中的触发器逻辑、.NET Framework 4.8业务程序集引用、EF6数据库优先的edmx模型和实体类直接迁移到新项目即可。EF6在.NET Framework 4.8环境下是原生支持的，不需要额外做SqlClient工厂注册这类兼容操作
  4. 配置文件中的连接字符串、队列触发器绑定规则和V1版本完全兼容，.NET Framework版本的V4函数默认加载的Newtonsoft.Json版本足够高，不需要再用之前替换程序集的临时方案
     注意：面向.NET Framework 4.8的V4函数仅支持Windows平台部署，不支持Linux，运行模型为进程内，官方提供长期支持

• 方案2：保留.NET 6运行时，最小改造适配EF6
  如果你必须使用.NET 6运行时，也不需要把EF6全量重构为EF Core代码优先：

  1. 把现有.NET Framework 4.8的业务层、EF6数据层升级到EF6.4版本，该版本官方支持.NET Standard 2.1，可以直接被.NET 6项目引用
  2. EF6.4的.NET Standard版本已经移除了对System.Runtime.Remoting.CallContext的依赖，改用.NET Core兼容的AsyncLocal实现，不会再触发你遇到的类型加载错误
  3. 原有数据库优先生成的EF6模型可以直接复用，只需要升级NuGet包后重新生成一次实体类即可，整体改造工作量不到全量转EF Core的10%
  4. 你现有代码中写的DbProviderFactories.RegisterFactory逻辑可以保留，System.Data.SqlClient在.NET 6环境下可以正常工作

• 不要尝试在.NET 6进程中直接加载未适配.NET Standard的.NET Framework 4.8程序集，除了CallContext的问题，后续还会遇到System.Web、System.Configuration等大量.NET Framework专属API缺失的错误，没有通用兼容层可以解决
• 不要用进程互调、COM包装这类方式把.NET Framework代码塞到.NET 6函数里运行，稳定性和性能都很差，后续维护成本极高
• 面向.NET Framework 4.8的V4函数对常用触发器（队列、HTTP、定时器、Blob等）的支持和.NET 6版本基本一致，完全可以满足生产使用需求

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