如何在.NET 7/8中调用.NET Framework 3.5第三方硬件通信库？

核心结论：必须使用 IPC #

由于 .NET 7/8 与 .NET Framework 3.5 的运行时完全不兼容，无法在同一进程中直接加载或调用该第三方库，进程间通信（IPC）是唯一可行的路径。不存在跨运行时直接调用的兼容方案，厂商的 .NET Standard 2.0 版本落地前只能通过进程隔离实现交互。

适合的 IPC 方案对比 #

结合你需要双向通信（.NET 7/8 调用硬件库，硬件消息回调至 .NET 7/8）、希望无缝包装库对象的需求，以下方案按推荐优先级排序：

1. WCF + CoreWCF #

• 适配性：完全满足你的场景。.NET Framework 3.5 原生支持 WCF 服务端，可轻松包装第三方库的方法并定义回调契约；.NET 7/8 侧使用 CoreWCF 生成客户端代理，实现类似"存根"的无缝调用体验，同时能接收来自服务端的回调消息。
• 优势：无需手动处理序列化、路由，自动生成的代理类让调用方式接近直接引用库的体验，双向通信机制成熟。
• 注意事项：虽然 WCF 属于传统技术，但针对你的兼容场景是最优选择，CoreWCF 是官方维护的 .NET Core+ 兼容实现，稳定性有保障。

2. gRPC #

• 适配性：需要将 .NET Framework 进程升级至 4.5+（.NET Framework 3.5 无法直接使用 gRPC 服务端库），但第三方 .NET Framework 3.5 库可在 4.5+ 进程中正常运行。gRPC 支持双向流式通信，可实现调用与回调的双向交互，性能优于 WCF。
• 优势：现代轻量，跨平台支持好，基于 Protobuf 序列化效率高，生态活跃。
• 缺点：需要定义 Protobuf 接口文件，手动生成服务端/客户端代码，相比 WCF 上手稍复杂。

3. 命名管道（Windows 原生） #

• 适配性：.NET 7/8 和 .NET Framework 3.5 均原生支持命名管道，可自定义消息格式（JSON/二进制）实现双向通信。
• 优势：轻量、Windows 下性能优异，无需依赖额外框架。
• 缺点：需要手动实现消息序列化、路由、错误处理和回调机制，没有现成的代理生成工具，开发工作量大，无法实现"存根式"的无缝调用。

排除方案：.NET Remoting #

已被官方废弃，.NET 7/8 完全不支持，直接排除。

启动 .NET Framework 进程的最优方案 #

1. 嵌入资源 + 临时目录启动 #

将 .NET Framework 编写的 IPC 服务端 exe 作为嵌入资源打包到 .NET 7/8 应用中，运行时提取到临时目录，再通过 Process.Start() 启动。这种方式部署时只需分发单个 .NET 7/8 应用程序包，无需单独管理两个 exe，体验更流畅。

2. 直接 Process.Start() #

最基础的方式，将 .NET Framework 服务端 exe 与 .NET 7/8 应用同目录部署，启动时通过 Process.Start() 拉起进程，可传递 IPC 地址等参数，同时监控进程状态，确保服务端正常运行。

排除方案：AppDomains #

.NET Framework 的 AppDomains 仅能隔离同一运行时内的代码，无法跨 .NET Framework/.NET 7/8 运行时，完全不适用于你的场景。

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