我们有一个单片的MFC GUI应用程序，它已经接近C++的生命周期了。我们计划在C＃中构建新的功能并在每个应用程序之间传递数据。在C++（MFC）应用程序和C＃之间传递数据
问题是：在C++和C＃之间传递数据的最佳方法是什么？
备注：
两端都会有一个GUI前端，可能只需要传递像Id这样简单的数据，并且可能有一个机制向其他应用程序指示使用哪个进程/功能。
例如，其中一个应用程序将是C＃中的一个CRM系统，当网格中的某一行被双击时，会传递customerId和一条消息以在MFC应用程序的客户表单中打开该客户。
我已经做了一些研究，选项似乎是Windows消息传递，内存映射，命名管道或类似Windows套接字的东西。在这个阶段，我们倾向于命名管道，但会真正感谢其他建议或提示或其他人的经验。
就我个人而言，我会考虑使用类似于命名管道的东西，因为它们很容易从C++端和.NET端的System.IO.Pipes中使用。
如果您计划随着时间的推移替换应用程序的其他非.NET位，它也可能是阻力最小的路径。
您也可以使用托管端的P/Invoke - 如果MFC应用程序具有C API，这将非常有用。你也可以从任何一方使用COM。
你列出的选项当然是有效的，但你也可以考虑COM。
当然，你的意思是DCOM？ – 2008-10-08 20:42:14
无论COM还是DCOM都是合适的 - 取决于应用程序是否在同一台机器上运行 – 2008-10-08 20:43:40
@Shaun Austin：其实我是指COM :)，这就是为什么我说COM。 – QBziZ 2008-10-08 20:54:17
任你选：
为什么命名管道？
在.Net只是使用System.IO.Pipes。
在C++中使用CreateNamedPipe和CreateFile。
我会使用套接字（TCP） - MFC和.NET都直接支持它们。
我的纬纱将是任一标准的窗口消息（例如WM_FOO）或DCOM：只要通信是非常简单的
消息会工作，并且在设置它是最小的额外开销。如果您可以将通信简化为每个消息一个或两个整数，那么这可能是一个很好的开始。如果这两个应用程序都已经是窗口化的应用程序，那么它们都已经有了消息循环，所以你已经完成了大部分的工作。
DCOM需要更多的程序员开销，但它很好，因为您可以定义更丰富的接口并避免将复杂消息转换为/从二进制形式。如果你走这条路线，CoRegisterClassObject是通过DCOM发布对象的起点。我从来没有尝试过从C＃应用程序这样做，但原则上它应该是完全可能的
你真的需要两个进程吗？
非托管C++和托管C＃代码完全能够在同一个进程中运行，并且只需一小层托管C++/CLI，就可以用简单的函数调用代替进程间通信的复杂性。
假设您有遗留应用程序的源代码，请参阅您是否无法将所有“主力”代码编译为DLL，然后从那里调用各个函数/窗口。一旦你有了这些工作，你可以简单地编写你需要的函数的托管C++包装器，并从你的C＃代码中调用这些包装器。如果幸运的话，整个过程可能需要不到一天的时间。
如果您不必担心应用程序将运行的所有系统上存在的.NET框架，我会说C++/CLI，否则就是COM。不过，这将取决于你最舒适和熟悉的内容。我喜欢C++/CLI和COM的现有'函数调用'结构（与其他协议相比），但那只是我自己。
我目前使用COM来添加一些.NET组件功能，主要是因为如果.NET不存在，仍然需要使用回退功能，但这是特定于我最需要部署的情况下的需求。
一个小的评论，为什么downvote总是很好 – 2008-10-08 20:44:15