我们有一个单片 MFC GUI 应用程序，它在 C++ 中的生命周期已接近尾声。我们计划在 C# 中构建新功能并在每个应用程序之间传递数据。
问题是：在 C++ 和 C# 之间传递数据的最佳方法是什么？
注意：
两端都将有一个 GUI 前端，并且可能只需要传递简单的数据，如 Id，并且可能有一种机制，它可以向其他应用程序指示要使用的进程/功能。
例如，其中一个应用程序是 C# 中的 CRM 系统，当双击网格中的一行时，会传递 customerId 和一条消息，以在 MFC 应用程序的客户表单中打开该客户。
我做了一些研究，选项似乎是 Windows 消息传递、内存映射、命名管道或 Windows 套接字之类的东西。在这个阶段，我们倾向于命名管道，但非常感谢其他建议或技巧或其他人的经验。
就我个人而言，我会考虑使用命名管道之类的东西，因为它们很容易从 C++ 端使用，而 System.IO.Pipes 在 .NET 端也很容易使用。
如果您打算随着时间的推移替换应用程序的其他非 .NET 位，这也可能是阻力最小的路径。
任君挑选：
为什么命名管道？
在 .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# 应用程序执行此操作，但原则上它应该是完全可能的
假设您拥有旧版应用程序的源代码，请查看是否无法将所有“主力”代码编译为 DLL，然后从那里调用各个函数/窗口。一旦你完成了这项工作，你就可以简单地围绕你需要的函数编写托管 C++ 包装器，然后从你的 C# 代码中调用它们。如果幸运的话，整个过程可能需要不到一天的时间。
如果您不必担心应用程序将运行的所有系统上存在的 .NET 框架，我会说 C++/CLI，否则会说 COM。不过，这真的取决于你最舒服和最熟悉的东西。我喜欢 C++/CLI 和 COM 的现有“函数调用”结构（而不是使用其他协议构建它），但这只是我。
我目前正在使用 COM 来添加一些 .NET 组件功能，主要是因为如果 .NET 不存在，仍然需要使用后备功能，但这是特定于我的需要，最好是最大部署。