我們有一個單片的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