Windows Compact Embedded 2013下C++调用C# DLL方案及IPC方法问询

1. C++/CLI、COM方案的替代方案 #

首先明确：WinCE 2013（Windows Embedded Compact 2013）默认仅支持.NET Compact Framework 3.9，该运行时从设计层面就不支持C++/CLI，因此C++/CLI封装方案完全不可行，和社区普遍结论一致。
COM封装无法实例化的常见原因及替代方向：

• 首先确认被封装的C# DLL是否为*.NET Compact Framework 定向编译版本*，如果使用桌面版.NET DLL做COM封装，哪怕编译通过，WinCE 2013无对应桌面运行时，必然无法创建实例
• 即使使用CF版本DLL，也需要用WinCE专用的regsvrce工具完成注册，同时要避免使用桌面COM特有的单元线程、高级COM接口等CE不支持的特性
• 若COM方案最终无法跑通，可选择两类替代：
  • 核心逻辑复杂度低的场景直接将C# DLL逻辑用原生C++重写，兼容性和性能最优
  • 逻辑复杂度高的场景将C#逻辑拆分为独立的CF应用，与C++应用通过进程间通信交互

2. C++与C#应用推荐的进程间通信实现 #

WinCE 2013下推荐按优先级选择以下IPC方案：

• 消息队列（MSMQ）：首选方案，系统原生支持，.NET Compact Framework提供System.Messaging命名空间封装，非托管C++可直接调用原生MSMQ API，支持异步通信，稳定性高，适配大多数结构化数据传输场景
• 命名管道：传输效率高于MSMQ，C++侧可直接通过CreateFile系列API操作，C#侧需通过P/Invoke调用原生命名管道API（.NET CF无内置托管封装），适合大数据量传输场景
• 本地套接字：使用127.0.0.1回环地址通信，通用性最强，两侧都有成熟的原生/托管API支持，缺点是需要自行实现序列化和通信协议，适合后续有跨设备通信需求的场景
• 共享内存：传输效率最高，C++侧创建共享内存区域，C#侧通过P/Invoke调用MapViewOfFile等API访问，需自行实现进程同步逻辑，适合高频、小数据量的实时通信场景

注意：所有IPC方案优先选择轻量二进制序列化格式，避免使用XML等高开销序列化方案，适配WinCE设备普遍有限的硬件性能。

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