将ATL COM DLL迁移至.NET Core：COM互操作相关技术疑问

刚好之前在项目里处理过ATL COM和.NET Core集成的需求，来给你逐一拆解这些问题：

• 复用现有投资：你手里的ATL COM DLL已经是经过测试、稳定运行的代码，用COM互操作可以直接复用，不需要重新编写和测试整个组件，节省大量时间和人力成本。
• 避免重构风险：重写为C++/CLI意味着要把ATL特有的逻辑（比如COM接口的实现、消息映射、ATL的容器类等）转换成托管代码，这个过程很容易引入新的bug，尤其是复杂组件，测试覆盖难度极高。
• 官方成熟支持：COM互操作是微软官方提供的跨.NET和原生COM的成熟方案，在.NET Core里也得到了很好的支持，文档和社区资源都很丰富，遇到问题更容易找到解决方案。
• 保留原有功能完整性：ATL COM可能依赖一些Windows特有的系统API或者COM特性，COM互操作能完整保留这些功能，而C++/CLI如果处理不当，可能会丢失一些原生能力或者需要额外适配。

确实会有一定的性能开销，主要来自托管与非托管代码的边界切换和数据类型封送：

• 每次从.NET Core的托管代码调用COM组件的方法，都需要完成一次跨边界的上下文切换，这个过程会有少量开销。
• 如果传递的是非 blittable 类型（比如字符串、自定义结构体），.NET运行时需要做数据类型的转换和内存拷贝，这会增加额外的开销。

不过也不用太担心：

• 如果不是高频次的调用（比如每秒成千上万次）或者大数据量的传输，这个开销几乎可以忽略，不会影响整体性能。
• 你可以通过一些方式优化：比如减少跨边界调用的次数（把多个小调用合并成一个大的方法调用）、使用 blittable 类型（如int、float、简单结构体）来避免封送、或者自定义封送器来优化特定类型的转换。
• .NET Core相比旧版.NET Framework，对COM互操作的性能做了不少优化，整体开销已经比以前小很多。

很遗憾，不行。COM是Windows平台特有的技术，.NET Core在Linux、macOS等非Windows平台上并没有实现COM互操作的支持，所以如果你的.NET Core项目需要跨平台运行，这个方案完全走不通。

这种情况下，你可能需要考虑其他替代方案：比如把ATL COM的核心逻辑抽出来，重写为跨平台的C++原生库，然后用.NET Core的P/Invoke调用；或者把COM组件封装成Web服务，通过HTTP接口调用；如果复杂度不高，也可以考虑用C#重写核心功能。

这个得看你原有ATL COM组件的复杂度：

• 简单组件（少量接口、逻辑单一）：难度很低。你只需要把ATL定义的COM接口转换成托管接口，然后用C++/CLI的混合模式把原有非托管代码封装到托管类里，基本不需要修改核心逻辑，只需要处理好托管与非托管的内存管理（比如非托管内存要手动释放，托管对象由GC管理）。
• 复杂组件（大量ATL特性、复杂逻辑）：难度很高。如果你的ATL组件用到了大量ATL特有的功能，比如消息映射、窗口控件、COM聚合、自定义调度接口、或者依赖其他非托管库，那么重构起来会非常麻烦：
  • C++/CLI的混合模式需要严格区分托管和非托管代码的边界，一不小心就会出现内存泄漏或者类型转换错误。
  • 一些ATL的特性在托管环境下没有直接对应的实现，需要重新设计逻辑。
  • 测试工作量极大，你需要保证重构后的组件和原有ATL COM的功能完全一致，包括异常处理、线程模型等细节。

总的来说，除非你的项目有跨平台的硬性要求，否则不建议做这个重构，COM互操作是更稳妥的选择。

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