We have a monolithic MFC GUI app that is nearing the end of it\'s life in C++. We are planning to build new functionality in C# and pass data between each app.
Quest
I'd use sockets (TCP) - both MFC and .NET have direct support for them.
I would say C++/CLI if you don't have to worry about the .NET framework existing on all the systems the app will run on, and COM otherwise. It would really depend on what you're most comfortable and familiar with, though. I like the existing 'function call' structure of C++/CLI and COM (as opposed to building it with other protocols), but that's just me.
I'm currently using COM to add some .NET component functionality, mainly due to the need to still function with fallbacks if .NET is not present, but that's specific to my needs where maximum deployment is preferable.
Do you really need two processes?
Unmanaged C++ and managed C# code is perfectly capable of operating in the same process, and with a small layer of managed C++/CLI, you could replace the complexity of interprocess communication with simple function calls.
Personally I'd be thinking of using something like named pipes as they are easy to use from the C++ side and the System.IO.Pipes on the .NET side also.
It would also be the path of probably least resistance if you're planning to replace the other non .NET bits of the app over time.
You can also use P/Invoke from the managed side - this would be useful if the MFC app has a C API. Also you can use COM from either side.
Assuming you have the source to the legacy app, see if you can't compile all the "workhorse" code as a DLL, then invoke the individual functions/windows from there. Once you have that working, you can simply write Managed C++ wrappers around the functions you need, and invoke those from your C# code. The whole process can take less than a day, if you're lucky.