易语言×.NET互通：用COM打造托管桥梁

52JinY 助手

很多做易语言的朋友，迟早会遇到一个现实问题：项目里要用到成熟的 .NET 库，但又不想/不能把整套代码迁到 C#。这时候“易语言与 .NET 互操作”的话题就摆在眼前。路径大致两条：走 COM 这条“老路”，或者直接和托管代码桥接。两者并非水火不容，各有代价和边界。

先说 COM

这条路的好处是“老而稳”。把 .NET 库做成 COM 可见的组件（在 C# 项目属性里勾选“对 COM 可见”，或用 RegAsm/Regsvr32 注册），然后在易语言里通过对象变量创建、调用即可。类型信息通过 TLB 暴露出来，方法签名也比较清晰，IDE 里能直接看到可用成员。对已经有大量 VB6/Delphi 时代经验的同学，这几乎是肌肉记忆。

但代价同样明显。首先是部署：COM 需要注册，管理员权限、32/64 位位宽一致性、注册表残留，都是坑。其次是类型系统的落差：.NET 的泛型、委托、异步 Task，很难原样穿过 COM 边界，只能退化成对象、接口或回调 IDispEvent。再有就是异常与字符串编解码，不注意就出“看起来像能跑，但偶发崩”的鬼问题。我的经验是，若必须走 COM，就老老实实做一个“薄适配层”——单独建个 C# Class Library，对外只暴露扁平的接口、基础类型与 BSTR 字符串，内部再去调用真正的 .NET 复杂对象，这样边界更可控。微软文档和社区里对 RegAsm 与嵌入互操作类型的说明可以作为参考，搜索“Registering assemblies for COM interop”基本能找到权威步骤。

再看托管桥接。很多人会提到两类方案：一是走 CLR 托管宿主，把 .NET 运行时托进你的进程里，通过反射或固定入口调用托管方法；二是借助现成的桥，如 UnmanagedExports（DllExport）、C++/CLI 或者 CoreCLR Hosting API，把托管方法“长成”原生风格的导出函数。优点是少了 COM 注册这层历史包袱，部署更简洁，和 .NET Core/.NET 6+ 的跨平台故事也更贴近现实。缺点是工程门槛更高：托管宿主的生命周期管理、AppDomain/AssemblyLoadContext、GC 与原生内存的交界、线程模型，都需要你认真设计。不少“跑得起来”的示例，放到真实项目就暴露出线程切换、阻塞调用、异常回传这些细节问题。

如果你走 C++/CLI 做桥，思路通常是：用 C++/CLI 写一个混合 DLL，一端暴露 extern "C" 的原生接口，供易语言通过调用 DLL 使用；另一端链接/引用托管程序集，做类型转换、内存管理和异常捕获。这条路的调试体验最好，但工具链只在 Windows/ MSVC 下舒服。若希望完全绕开 C++/CLI，可以用 DllExport 把 C# 方法导出成 stdcall/cdecl，然后严格用 blittable 类型（int、double、指针）过界；复杂结构体和字符串自己约定编码（UTF-16/UTF-8）和释放协议，否则就是内存雷区。

怎么选？给一个朴素决策表：  
- 你的目标机器权限可控、位宽单一、接口相对稳定，团队成员对 COM 不抗拒——优先 COM。它对简单对象模型的支撑足够，调试路径成熟。  
- 你需要零注册部署、未来要上 .NET 6/8、甚至考虑后续跨平台复用逻辑——考虑托管宿主或 C++/CLI 桥。前期投入更大，但后续维护少踩历史坑。  
- 无论哪条路，边界要“瘦”。把所有复杂性关在托管侧或桥接层里，跨界协议尽量是基础类型 + 明确的缓冲区长度 + 明确的所有权。

一些工程化建议，都是踩坑总结：  
- 统一位宽。x86 调 x86，x64 调 x64，不要指望“能注册就能用”。  
- 明确字符串与编码。选 UTF-16 就全链路 UTF-16；选 UTF-8 就自己提供转换与长度。  
- 异常不跨界。托管侧 catch 所有异常，转错误码与最后错误文本；原生侧绝不假设成功必然返回非空。  
- 线程模型先订，再写代码。COM 里注意 STA/MTA；托管宿主里避免在 GC 不知情的线程上长期持有托管对象引用。  
- 日志要两端各自留存，再提供一枚“取最近错误”的 API，定位问题时少抓瞎。  
- 做一个“小而全”的样例工程：一条字符串 round-trip、一个数组求和、一次回调调用、一次异常返错。样例跑通再上业务。

最后，别神化任何一条路径。COM 不是洪水猛兽，托管桥也不是银弹。把互操作当成“产品的一部分”去设计和维护，而不是“偶尔穿一下墙”，你会发现两边生态都能为你所用。至于进一步阅读，微软 Docs 上的“COM interop”、“Hosting .NET Core runtime”，以及社区里对 DllExport、C++/CLI 的实践文章都值得一读，关键是照着自己的项目边界，挑一套能持续维护的方案。