我们有一个用 C++ 编写的单片 MFC GUI 应用程序,它的生命周期已接近尾声。我们计划用 C# 构建新功能并在每个应用程序之间传递数据。

问题是:在 C++ 和 C# 之间传递数据的最佳方法是什么?

笔记:
两端都将有一个 GUI 前端,并且可能只需要传递简单的数据(例如 ID),并且可能有一种机制,向其他应用程序指示要使用的进程/功能。
例如,其中一个应用程序是 C# 中的 CRM 系统,当双击网格中的一行时,将传递 customerId 和一条消息,以在 MFC 应用程序的客户表单中打开该客户。

我做了一些研究,选项似乎是 Windows 消息传递、内存映射、命名管道或 Windows 套接字之类的东西。在这个阶段,我们倾向于命名管道,但非常感谢其他建议或技巧或其他人的经验。

有帮助吗?

解决方案

就我个人而言,我会考虑使用像命名管道这样的东西,因为它们很容易在C ++端和.NET端的System.IO.Pipes上使用。

如果您计划随着时间的推移替换应用程序的其他非.NET位,那么它也可能是阻力最小的路径。

其他提示

任君选择:

  • 文件
  • 命名管道 <-- 我的推荐
  • 共享内存
  • 插座
  • 通讯
  • Windows 消息

为什么命名管道?

  • 为您提供免费的 FIFO 工作方式(类似于套接字,但不同于共享内存)
  • 可以轻松地进行双向沟通
  • 所有平台均得到良好支持
  • 便于使用
  • 可靠的数据传递和交付
  • 可以是阻塞和非阻塞
  • 无需删除即可读取数据(与套接字不同)
  • 可以轻松扩展以包含第三个应用程序。

在.Net中只需使用System.IO.Pipes。

在 C++ 中使用 CreateNamedPipe 和 CreateFile。

您也可以使用管理端的P / Invoke - 如果MFC应用程序具有C API,这将非常有用。你也可以从任何一方使用COM。

您列出的选项当然有效,但您也可以考虑使用COM。

我使用套接字(TCP) - MFC和.NET都直接支持它们。

你真的需要两个流程吗?

非托管C ++和托管C#代码完全能够在同一个进程中运行,并且通过一小部分托管C ++ / CLI,您可以用简单的函数调用替换进程间通信的复杂性。

我的选择是标准窗口消息(例如WM_FOO) 或 DCOM:

  • 只要通信非常简单,并且设置它的开销很小,消息就可以工作。如果您可以将通信简化为每条消息一两个整数,那么这可能是一个很好的起点。如果两个应用程序都已经是窗口应用程序,则它们都已经具有消息循环,因此您已经完成了大部分工作。

  • DCOM 需要更多的程序员开销,但它的好处是您可以定义更丰富的接口,并避免必须将复杂的消息与二进制形式相互转换。如果您走这条路,CoRegisterClassObject 就是通过 DCOM 发布对象的起点。我从未尝试过从 C# 应用程序执行此操作,但原则上它应该是完全可能的

假设您拥有遗留应用程序的源代码,请查看您是否无法编译所有<!>“; workhorse <!>”;代码作为DLL,然后从那里调用各个函数/窗口。一旦你有了这个工作,你可以简单地围绕你需要的函数编写Managed C ++包装器,并从你的C#代码中调用它们。如果你幸运的话,整个过程可能需要不到一天的时间。

如果您不必担心应用程序运行的所有系统上都存在 .NET 框架,那么我会选择 C++/CLI,否则选择 COM。不过,这实际上取决于您最舒服和最熟悉的内容。我喜欢 C++/CLI 和 COM 现有的“函数调用”结构(而不​​是使用其他协议构建它),但这只是我的看法。

我目前正在使用 COM 添加一些 .NET 组件功能,主要是因为如果不存在 .NET,仍然需要使用回退功能,但这特定于我的需求,其中最大部署更可取。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top