5

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.

Martin R
  • 113
  • 3
  • 8
  • 1
    How about using network API's for this? e.g. a local TCP/IP connection. – Binkan Salaryman Jun 18 '15 at 08:24
  • network + protobuf for example https://github.com/google/protobuf – Andrey Jun 18 '15 at 08:25
  • Named pipes also work well. – Furkan Omay Jun 18 '15 at 08:34
  • I don't think Window's messages is an awful way to communicate. How much data are you storing in the file? If a small amount, what about using the WM_COPYDATA message (https://msdn.microsoft.com/en-us/library/windows/desktop/ms649011(v=vs.85).aspx) and avoiding the file I/O? – jglouie Jun 18 '15 at 12:36
  • One other way is to use COM, but that may be overkill for you – jglouie Jun 18 '15 at 12:41
  • Thanks for your reply. There is not so much data in the files, depending on configuration something about 20-50 different informations. – Martin R Jun 18 '15 at 12:50
  • I haven't though about local TCP/IP, I have to read about this, but it is an interesting point. Using COM ist pretty same as CLI wrapper, but much easier to implement. Cli wrapper was my prefernce, but as I posted previously I wanted to know if there are any better solution for this task or if there are any cases when I should avoid cli. Named pipes - they are somehow similar to files and in this case, a wouldn't have much benefit over currently used communication, or am I wrong? – Martin R Jun 18 '15 at 13:03
  • Named pipes are like actual pipes, you can push water (data) into your pipe and receive on the other end. If you don't have much data, you can pass them with Window's messages and mailslots, the latter would be even much easier. – Furkan Omay Jun 18 '15 at 13:12

4 Answers4

9

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.

Community
  • 1
  • 1
Furkan Omay
  • 1,047
  • 1
  • 11
  • 22
  • 1
    Named pipes are almost certainly the way to do this. Be careful to set the security attributes correctly or a malicious application could hijack the pipe. (Avoid TCP/UDP if there's any chance that the PC might have networking disabled.) – Ian Goldby Jun 18 '15 at 10:18
  • @IanGoldby I've expanded the answer with your super easy mailslot suggestion. – Furkan Omay Jun 18 '15 at 12:33
  • Thanks for your detailed explanation. But how about benefits and drawbacks of each of these methods? As you said named pipes should work "similar" to files which i am currently using and there wouldn't be much changes in code, but also not much benefit?. If we want to compare cli wrapper and named pipes - are there any cases(performance, data amount, ease to debug, adding new data...) when we should use one and not the other option? – Martin R Jun 18 '15 at 13:16
  • One more thing about named pipes - can we always be sure that antivirus will not block them? – Martin R Jun 18 '15 at 13:23
  • @MartinR Named pipes are better than files because you don't need PostMessage(), you don't have the possibility of the file lying around after the applications have quit, data is removed from a pipe by reading it, other applications can't interfere with them, and they aren't affected by antivirus scans. – Ian Goldby Jun 18 '15 at 13:23
1

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.

Drax
  • 12,682
  • 7
  • 45
  • 85
0

Usually I register custom message with RegisterWindowMessage API for both Apps.

i486
  • 6,491
  • 4
  • 24
  • 41
0

We have the same issue. From .net to c++ , we call the dll, from c++ to .net , we build a local web service providing resful api to c++

Saffi Zhang
  • 1