Data Transfer between C ++ (MFC) and C #

Question

We have a monolithic MFC GUI application that is nearing the end of its life in C ++. We plan to create new features in C # and transfer data between each application.

Question: what is the best way to transfer data between C ++ and C #?

Notes:
Both ends will have a GUI and probably only need to pass simple data, such as Id, and perhaps have a mechanism where it tells the other application which process / functionality to use.
For example, one of the applications will be a CRM system in C #, which, when a line in the grid is double-clicked, will pass, say, clientId and a message to open this client in the client form of the MFC application.

I did a bit of research, maybe the parameters are Windows Messaging, Memory Mapping, Named Pipes, or something like Windows Sockets. At this point, we tend to Named Pipes, but we will greatly appreciate other advice or advice or other people's experience.

Answer 1

Personally, I would like to use something like named pipes because they are easy to use on the C ++ side and System.IO.Pipes on the .NET side.

It will also be the path of least resistance if you plan to replace other non-.NET bits over time.

Answer 2

Make a choice:

• files
• named pipes <- My recommendation
• Common memory
• sockets
• COM
• Windows Messages

Why named pipes?

• Gives you a FIFO way to work for free (for example, sockets, but not as shared memory).
• You can easily share both ways.
• Well supported on all platforms
• Ease of use
• Reliable data transmission and delivery.
• May block and not block
• Can read data without deleting (unlike sockets)
• You can easily add a third application.

In .Net, just use System.IO.Pipes.

In C ++, use CreateNamedPipe and CreateFile.

Answer 3

You can also use P / Invoke from the managed side - this would be useful if the MFC application has a C API. You can also use COM on both sides.

Answer 4

The options you listed are certainly valid, but you can also consider COM.

Answer 5

I would use sockets (TCP) - both MFC and .NET have direct support for them.

Answer 6

Do you really need two processes?

Unmanaged C ++ and managed C # code work fine in one process and with a small level of managed C ++ / CLI, you can replace the complexity of interprocess communication with simple function calls.

Answer 7

My selections will be either standard window messages (e.g. WM_FOO) or DCOM:

• Messages will work until communication is very simple, and the overhead when setting it up is minimal. If you can bring a message to one or two integers per message, this is likely to be a good place to start. If both applications are already windowed applications, they already have message loops, so you are already there most of all.

• DCOM requires a lot more programmer overhead, but it's nice that you can define a richer interface and avoid the need to convert complex messages to / from binary form. If you go this route, CoRegisterClassObject is the starting point for publishing an object via DCOM. I have never tried to do this from a C # application, but basically it should be completely possible

Answer 8

Assuming you have a source of an outdated application, see if you can compile all the workhorse code as a DLL and then call individual functions / windows from there. After you do this, you can simply write Managed C ++ wrappers around the functions you need and call them from your C # code. The whole process may take less than a day if you are lucky.

Answer 9

I would say C ++ / CLI if you do not need to worry about the .NET platform that exists on all the systems on which the application will run, and otherwise COM. It will really depend on what you are most comfortable and familiar with. I like the existing structure of C ++ / CLI and COM function calls (as opposed to creating it with other protocols), but that's just me.

I am currently using COM to add some components of the .NET component, mainly because of the need to still work with backup files if .NET is not, but for specific tasks where maximum deployment is preferable.