嘿，我来给你理清楚这个问题，直接说结论：你想的这个直接引用封装DLL的方案确实不可行，下面我会给你能提交给上级的官方依据，还有解释你遇到的错误原因。

为什么会出现Could not load type System.Web.HttpContext？ #

这个错误本质上是因为.NET 5/6（以及后续的.NET版本）是完全重构的跨平台.NET，它彻底抛弃了System.Web这个组件——System.Web是.NET Framework专属的，深度绑定旧版ASP.NET和IIS运行时的一套API，.NET 5+的ASP.NET Core栈和它没有任何兼容性。你的封装DLL里只要调用到依赖System.Web的代码，.NET 5+的运行时就找不到对应的类型，自然会报错。

能提交给上级的官方文档依据 #

微软在官方的.NET兼容性和迁移文档里明确说明了这一点：

.NET 5及更高版本不支持依赖System.Web、旧版ASP.NET（包括Web Forms、ASMX Web服务）的.NET Framework程序集。这类组件是.NET Framework独有的，没有被移植到.NET Core/.NET 5+生态中，也永远不会被移植。

另外，在.NET的"移植可行性检查"文档里也提到：

如果你的代码依赖System.Web命名空间下的任何类型，那么它无法直接在.NET 5+中运行，必须进行重写，或者通过跨进程通信的方式调用（而非直接引用DLL）。

为什么封装DLL也解决不了问题？ #

你以为把调用封装在.NET Framework DLL里就能隔离，但实际上.NET 5+的进程在加载这个DLL时，还是会尝试在自己的运行时环境中找System.Web的类型——而这个环境里根本没有这些类型。.NET 5+和.NET Framework的运行时是完全独立的，不能在同一个进程里混合依赖System.Web的.NET Framework代码和.NET 5+代码。

替代方案供你参考 #

既然这些DLL没法升级，你可以考虑这几个方向：

• 把旧DLL封装成独立服务：基于.NET Framework搭建一个简单的Web服务（比如ASMX或者旧版ASP.NET Web API），把旧DLL的功能暴露成接口，然后让你的.NET 5+ Web API通过HTTP请求调用这个服务，这是最稳妥的方式。
• 使用.NET Standard拆分逻辑：如果旧DLL里有部分代码不依赖System.Web，可以把这部分抽出来做成.NET Standard类库，这样既能被旧的.NET Framework项目引用，也能被.NET 5+项目直接引用，逐步替换掉依赖System.Web的部分。
• 进程外调用：比如用WCF或者其他进程间通信方式，让.NET 5+程序启动一个.NET Framework的进程来执行旧DLL的逻辑，再返回结果，但这种方式复杂度较高，维护成本也大。

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