I have two Windows services, the first one written in C# and the second written in
unmanaged C++, I want to know how can I do two-way interprocess communication.
If the interprocess communication is always going to be done on the same machine, named pipes is the way to go because they are faster than other options.
However, if there is even the slightest chance that this communication might occur across machine boundaries at some point, go with the socket approach. For C++, you'll need the winsock2.h header file. In C#, use the System.Net.Sockets namespace.
It's been a while since I've done unmanaged C++, but my recollection is that you'll have to write less C++ code if you create the server on the C++ side and then use the TcpClient class on the C# side.
Sockets are probably your best bet.
With sockets your not necessarily tied to both programs being on the same machine.
Also, it's likely to be the most portable option (heck, Windows even has select() for sockets).
Sockets and Named Pipes are two options well supported in the managed and unmanaged environments.
There are a number of ways to do this, but I think that the best way would be to use WCF and COM+. If you host a service in COM+, you can access it through WCF in your .NET service, and through COM interfaces in your unmanaged code.
You might want to check out the following sections of the MSDN documentation to get started:
Integrating WCF Services with COM+:
http://msdn.microsoft.com/en-us/library/bb735856.aspx
Integrating with COM+ Applications Overview:
http://msdn.microsoft.com/en-us/library/ms734723.aspx
I would say sockets and a messaging system. Check our for Google Protocol Buffers.
Use either DCOM/RPC or named pipes - anything else is either insecure, hacky, or both.
Create a Singleton COM object. Maintain data in this COM object, which can be read by both C++ and C# applications.
I would say redis would be the best solution for any kind of interprocess communication
Related
I have a Java application that launches a small C# application on the client machine.
I need a simple solution for passing events between the C# and the Java applications.
To handle the opposite direction (Java->C#) I was using FileSystemWatcher, which listens to folder change events.
The Java application writes an empty file to a shared folder, and the C# app handles these events according to the (empty) file name (and then removes it from the "queue").
Could not find a Java equivalent to FileSystemWatcher to solve the problem of passing events from C# to Java.
Any creative idea ? (reminder: this is just a Java application so I have no Apache server or something like that).
Thanks
A nice simple writeup written in 2010
Use Named Pipes to Communicate Between Java and .Net Processes
http://jni4net.sourceforge.net/
That's probably an option for you.
This seems like a duplicate of
IPC between .NET and Java client applications
I would use a simple JMS server like ActiveMQ to pass messages back and forth.
basically you need inter process communication. There are many way for it.
Socket
Named Pipes
Any distributed queue like RabbitMQ, ActiveMQ, e.t.c.
Named Mutex
http://www.ikvm.net/
e.t.c.
There are many possible ways but they generally fall into two categories:
java<->c# interop (like http://jni4net.sourceforge.net/)
or
some form of standardized communication like webservices (they don't require a "server" to work) such as WCF in C# and Metro on the java side.
BTW: You really shouldn't be using the file system to pass events.
The scenario that I bring forward is basically that of, interaction between two .NET executables.
I have made a .NET Windows Forms application in C# (Application-A) that runs on a user's machine and does some specific activity, due to which it collects some data.
Now I have another .NET Windows Forms executable (Application-B), also made in C#, which also does some specific activity based certain inputs or data provided.
Now what I want to do here is, call Application-B from the Application-A and pass the some data to it.
How do I accomplish this?
You can use several options. You have some resources for each option below.
.NET Remoting
WCF
Use a communication file
MSMQ
Two last options are valid only if the processes are in the same machine.
Since they are two separated processes I think that the easiest way to do this is using .NET Remoting. Here you can find documentation and examples about how to do it.
An alternative to Remoting is WCF (>= .NET 3.0). It performs better than remoting.
If the processes will be always in the same machine, if you don't want to use remoting on localhost you can communicate them through a file (simple solutions usually work fine!)
And other more complex solution is communicate them using a Message Queue (MSMQ). Here you cand find out an example about how to use it.
You can use MSMQ to communicate between the applications.
Any mechanism will do, however.
You could use file based communications (write to a known directory and read from it).
WCF is another solution.
WCF is going to allow you a lot of flexibility in the future : Should you ever decide to enhance this communication to support multiple modes of communication, app.config changes should be the majority of the work to support a different binding.
In some of the projects I've been involved in, there's a mix of communications technologies where one choice would've been far easier to maintain-- this leads me to embrace the WCF decision for its inherent flexibility (WCF also supports MSMQ should the need arise to have queued communication).
If you're concerned about the learning curve and you're sure that no future need will arise for you to embrace other communication topologies, remoting could be a useful solution. Remoting is probably the easiest, least-developer-work needed way of setting up IPC.
You should stay away from things like Web Services -- there's unnecessary overhead in the web service operations that WCF doesn't suffer from (WCF can still allow binary transport, for instance).
If both the applications are running on same user computer than
1- this can be achieved through inter-process communications channel (IPC channel)
2- If you are using .NET 4.0, you can use memory mapped files
If both the applications are running on different system
1- You can make use of .NET Remoting
2- You can have WCF service based communication
3- Web Service is also an option if using .NET 2.0 or lower versions
We have several legacy components that interact with COM ports, USB etc.
I would like to create a .NET program that would emulate a COM port and log the traffic, relaying it to a WCF service endpoint somewhere or directly into a database. Maybe also wrapping a real COM port kind of like the decorator pattern.
I have looked around and I have found Sourceforge project Com0Com, but it's pretty old API and in c++.
I realize that I can solve this specific problem by creating a line printer driver and never really interacting with the COM ports registered in the system. Some links to that would also be highly appreciated.
Has anybody done this? How do you create system resources in .NET?
You would have to write a driver, that's how Com0Com works. If these components run in-process, you could hijack the Windows API functions, Microsoft's Detours for example.
Either solution requires C/C++, you can't write this code in a managed language. Although detouring could be technically possible, just very hard to get right. You can buy a solution though, your requirements are not uncommon, albeit it dated. Dated enough that finding one might be a bit tricky.
Has anybody done this?
To add to what nobugz said:
When I wrote a COM port emulator, I did it starting from the sample serial port driver in the DDK (serial.sys).
When I wrote a COM port wrapper/logger, I did it starting from the sample parallel port filter driver in the DDK (parport.sys).
the ways I can think of
Web service or soap
Socket
Database table
shared file
Any concise example you know of for webservice?
Web services or soap would be fairly easy, however, if the C++ application isn't a web server naturally (or the C# application), it may be easier to just use socket programming directly.
Sockets are fairly easy to use from both C# and C++. They give you complete control over the type of date transmitted, at the cost of potentially a little more work in the handling.
The biggest issues to watch for are probably endianness of binary data, and encoding of text data, if you use sockets directly. Otherwise, it's very easy.
Since you are already aware of the Web service and socket approach, I'll mention some other options. If you like simplicity, check out XML-RPC. This is what SOAP was before large standards committees and corporate interests began to control the specification. You can find implementations of XML-RPC for just about every major programming language out there. Hessian is an interesting binary protocol that has many fans and supports just about every major language as well. Protocol Buffers is popular within Google. The official version from Google does not support C#. However, the two highest rep users of SO do provide ports of protobuf for the .Net space.
I will probably be ridiculed for this, but also take a look at CORBA. It's not in vogue these days, but has many substantial technical creds, especially if one end of the communication is C++. IMHO, it's WS-* with OO support and no angle brackets required. For interop, I think it still should have a seat at the table. When engaged in C++ development, I found OmniOrb to be quite effective and efficient. Take a look at this SO Question for some pointers concerning using CORBA in .Net.
Sockets are easiest; and I would always go for that first. If database is an option, that's also trivial, but that would really depend. If it's queued events, that would make sense, but if it's request/response, it's probably not so great.
you can use gsoap to have a C/C++ program use a webservice.
You can also call a cgi program that is written in C++.
I have written a server in C that communicated with a C# client, and the endianess can be a pain to deal with, webservices is so much simpler.
Do you want it to communicate with each other (for instance, through tcp (like many others have pointed)) or do you want to be able to translate objects from C# to C++? If so, check out Apache Thrift (http://incubator.apache.org/thrift/).
What would be the best way to pass information from a windows forms C# app to a MFC C++ app while they are running? I don't need to send much, just a small string.
Thanks,
Jeff
Going down the list of IPC options:
Memory mapped files. Easy in C++, tough in C# without pointers, awkward handshaking
WM_COPYDATA. Easy in both, tricky to find the window handle you'll need
Clipboard. Easy in both, very awkward handshaking
COM. Out-of-proc is a beast, forget about it
Mailslots. Not suitable for one-to-one communication
Pipes. Easy in .NET 3.5, do-able in C++ but a bit tricky to get right
Sockets. Easy in both, hard to pass up.
Use named pipes, see this posting.
If the C++ app has a main window, take a look at using the SendMessage function (via P/Invoke) in the C# app to send a WM_COPYDATA message to the C++ app.
http://msdn.microsoft.com/en-us/library/ms649011%28VS.85%29.aspx
MailSlot api is small and simple but requires P/Invoke to use from c# and can go outside your local machine so needs care.
see my answer here
Named pipes may well be more robust but this is an alternate.