我们有一个单片MFC GUI应用程序即将结束它在C ++中的生命。我们计划在C＃中构建新功能，并在每个应用程序之间传递数据。
问题是：在C ++和C＃之间传递数据的最佳方法是什么？
注意：
两端都有一个GUI前端，可能只需要传递像Id这样的简单数据，并且可能有一种机制，它向另一个应用程序指示要使用的进程/功能。
例如，其中一个应用程序将是C＃中的CRM系统，当双击网格中的一行时，将传递customerId和一条消息，以在MFC应用程序的客户表单中打开该客户。
我做了一些研究，选项似乎是Windows Messaging，Memory Mapping，Named Pipes或Windows Sockets之类的东西。在这个阶段，我们倾向于命名管道，但非常感谢其他建议或提示或其他人的经历。
答案 0 :(得分：5)
就我个人而言，我会考虑使用像命名管道这样的东西，因为它们很容易在C ++端和.NET端的System.IO.Pipes上使用。
如果您计划随着时间的推移替换应用程序的其他非.NET位，那么它也可能是阻力最小的路径。
答案 1 :(得分：5)
选择：
为什么命名管道？
在.Net中只使用System.IO.Pipes。
在C ++中使用CreateNamedPipe和CreateFile。
答案 2 :(得分：2)
您也可以使用管理端的P / Invoke - 如果MFC应用程序具有C API，这将非常有用。你也可以从任何一方使用COM。
答案 3 :(得分：2)
您列出的选项当然有效，但您也可以考虑使用COM。
答案 4 :(得分：2)
我使用套接字（TCP） - MFC和.NET都直接支持它们。
答案 5 :(得分：1)
你真的需要两个流程吗？
非托管C ++和托管C＃代码完全能够在同一个进程中运行，并且通过一小部分托管C ++ / CLI，您可以用简单的函数调用替换进程间通信的复杂性。
答案 6 :(得分：0)
我的选择是标准窗口消息（例如WM_FOO）或DCOM：
只要通信非常简单，消息就会起作用，并且设置它的开销很小。如果你可以将每个消息的通信简化为一个或两个整数，这可能是一个很好的起点。如果这两个应用程序都已经是窗口化应用程序，它们都已经有消息循环，所以你已经大部分都在那里了。
DCOM需要更多的程序员开销，但它很好，因为你可以定义更丰富的接口，避免必须将复杂的消息转换为二进制形式。如果你走这条路，CoRegisterClassObject是通过DCOM发布对象的起点。我从来没有尝试过使用C＃应用程序，但原则上它应该是完全可能的
答案 7 :(得分：0)
假设您拥有遗留应用程序的源代码，请查看您是否无法将所有“主力”代码编译为DLL，然后从那里调用各个函数/窗口。一旦你有了这个工作，你可以简单地围绕你需要的函数编写Managed C ++包装器，并从你的C＃代码中调用它们。如果你幸运的话，整个过程可能需要不到一天的时间。
答案 8 :(得分：0)
如果您不必担心应用程序将运行的所有系统上存在的.NET框架，我会说C ++ / CLI，否则就是COM。但这确实取决于你最熟悉和熟悉的东西。我喜欢C ++ / CLI和COM的现有“函数调用”结构（而不是使用其他协议构建它），但这只是我。
我目前正在使用COM来添加一些.NET组件功能，主要是因为如果不存在.NET，仍然需要使用回退功能，但这是特定于我需要最大部署的首选。