Best way to communicate between .NET and native C++ application

Question

As stated in the title - currently I have two applications. One is .NET, winforms and the second one is native C++. Both work together and must communicate (C++ to .NET and .NET to C++), the .NET application is started from C++ application. Currently the communication is done by writing the data to a file and sending postmessage to inform C++ application that the data was written. Although it works, I don't think that this is the best way doing this. Because of that I would like to ask you, what would you recommend as the best way. I am considering writing an CLI wrapper around .NET to bind it in C++. Are there any drawbacks of using such wrapper in comparison to writing the data to files?

--------Update--------

I've forgotten to add that both applications always work on the same machine. The solution should work on Windows xp, win7, win8

-------Conclusion------

Thanks a lot for your answers, all of them are very helpful. Good overview about differences between interprocess communication technologies presents the web site provided in the answer of Furkan Omay - offically supported Inter-Process Communications methods on Microsoft Windows. However there seems to be an issue with antivirus programs like on this web site from McAfee. In some cases it can be a huge problem. According to using C++/Cli I like the answer from Drax, thanks. I also don't see any disadvantages of using a wrapper. A good tutorial is here.

Answer 1

There are several options to achieve this.

1. Client / Server connection

   Your application needs to listen on a TCP (preferred) or UDP port, while other one connects it.

   Gives you the ability to separate your application to another computer / network interface.

   But you reserve a port on the machine. You need to make sure that it is protected from internet. Some internal firewalls might complain, even on localhost. (But they won't block it.)

2. Named pipes

   You can read and write it like a regular file. .NET has built in support with System.IO.Pipes

   Main difference from pure file based approach, that the application can wait for the data to process. It is like waiting to water come out of the pipe.

   You need to handle the directions and the security of the pipes, then properly dispose them.

   Google Chrome uses this method to communicate between different worker processes.

3. Windows Message Dispatch

   Like i486 mentioned, you can use RegisterWindowMessage to register for custom messages and send them with SendMessage or PostMessage. It is more C++ friendly approach.

   Poorly written applications might lead to resource exhaustion but it won't happen easily.

4. Mailslots

   This is suggested by Ian Goldby. Mailslots provides one-way message sending between applications with a very simple Windows API Call. Best for sending a lot of small strings.

5. Message Queue

   You can connect your applications to a message broker like RabbitMQ, and use publish-subscribe model to pass data. This requires a server which you don't want but:

   You can use ZeroMQ which can work serverless. It is blazing fast, can communicate via different technologies. However, it requires reading more documentation than previous methods to achieve the desired behavior.

6. Standard Input / Output

   You can redirect your stdout, which can be received by the child process via stdin.

According to your requirements, personally I would use named pipes. They stay on the computer and wouldn't require much changes to code. Previously I did a C# application which communicated with an OpenCV application written in C++, and named pipes worked perfectly in that case.

You can create two simple classes in both languages to pass the data between them.

However, all the other solutions would still work. TCP/IP can still work on the same machine. Messages, Mailslots, Sockets and Pipes are one of the offically supported Inter-Process Communications methods on Microsoft Windows and they work on even on Windows 2000.

Answer 2

The main(only?) drawback of a cli wrapper is that it will take a little more development time cause its ont more project to write/debug/maintain. But it is probably the most sound solution if your applications are not small ones.

Otherwise you can chose among other layers of communication like NamedPipes or Sockets which is quite generic but adds an unnecessary protocol layer which doesn't exist if you wrap your native code in C++/Cli. This very language was invented for this use case.