I have just start learning about WCF that can help me for the communication between two different platform application. I have also created one simple application for the communication but both client and service are written in C#. I want to know how I can establish a C++ and C# application so that they communicate to each other. Thanks in advance
this question seems very wide to me, the thing is since you are in windows, and the C# and C++ applicattions will be running simultaneously, you have to thing in the specific requeriments of you appliccation.
For example, I had a Server in C# wich recived some data, that had to be processed in C++ and then returned to the sender, so, since the C# and C++ process were in the same computer I used a File Mapping method, for example.
Indepently of the language, what you have to make sure, is that the data you send, wen you recive it in the other process, that should be able to be understood.
Here is a link for more info in wnidows
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx
Related
My current project involves building a high speed framework for communications across different OSs and remote systems for computer vision applications where the various components communicate using ZeroMQ sockets. This works fine in Standard C++ (Non-Cli).
I have recently found a use-case where I need to interface with an application coded in C#. Having compiled and run the "Hello World" example from the guide (On localhost) with clrzmq 2.2.2. I cannot get the two programs to communicate (One in C++ one in C#).
The C# server receives a request from the C++ client but nothing happens after that, it just seems to hang, which would indicate a problem with the C# response. Replacing the C# server with a C++ one compiled from the guide works fine.
Does anybody have any experience of getting C++ apps to talk to .NET using ZMQ? I would be grateful for any help, as this is not covered in any documentation I have been able to locate.
That is likely to be an application bug. We have a program like that running without issues. C# to c++.
We're working on a project that requires us to interface with a specific set of hardware; one set can be controlled very easily using C#, the other of which is natively programmed using Python. Part of the project involves getting the hardware running on Python to communicate with the hardware running through C#, and unfortunately, due to time constraints, we aren't able to create a set of C# or Python software to control the other set of hardware.
The set of hardware running on Python is completely event based, in that we can program functions that are called when certain conditions are met by the hardware. Our thought was to modify the C# application controlling the other set of hardware to host the Python application (using something like Application.Run()), then program the Python functions to propagate relevant data to the C# application as the events come in from the hardware.
We're considering using a socket connection to handle communication between the two, as both C# and Python are fairly simple to get working that way (or so our Python guy claims). The biggest concern with this that we have is if there will be any issues with the fact that both programs will be hosted on the same machine. If this won't be an issue, we would probably end up using a shared library such as 0MQ
We've also done some research into the following areas:
Pipes / Named Pipes
Message Queues
Shared Memory
Basically we want to know which method of these (or any others) will be the easiest to implement with these languages, and which will give us the best performance. We are concerned only with speed and accuracy of the data (ie, if using network packets, one that will drop the least). Security is not a concern.
Ideally, there should be one data stream going from the Python application to the C# application, and two data streams going from the the C# application to the Python application. The host machine will be running Windows 7. I can give additional information as needed.
One option is to try IronPython. Since IronPython is a .NET language, communicating with C# code should be easy.
It seems worth looking into how hard it would be to get your existing Python code running on IronPython.
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.
What "technology" would you suggest to exchange some kind of messages between a Java server and several clients written in C#, Javascript and Java?
The background story:
In our current project we're trying to build a generic UI backend in Java (running on the server) which is then "bridged" into several UI frontends by means of different UI adaptors (running on the client, the server, or both). While our server technology will always be Java, there will be C# (Silverlight), JavaScript and Java clients. Maybe even more in the future (different Smartphones, Tablets).
The UI backend and UI frontends communicate through a bunch of more or less simple messages (mostly name/value-pairs) each of which encapsulates a specific property/state/data change on the client or server respectively. Within a single request cycle, several such simple messages are aggregated into one big message which is then passed from backend to frontend or vice versa. At the moment sending and receiving messages is done at a single entry point on the client as well as on the server. So there are no server methods exposed as WebService etc. - simply because this would most definitely be to slow in our case.
Our current prototype consists solely of a Java server, a Java Desktop Client (Swing) and a Java Web Client (Vaadin). The message exchanged between backend and frontend is effectively a list of POJOs (each representing a specific "change") serialized/deserialized to/from XML. So far, so good.
Now C# and Javascript come to the table. Since we want to work with some kind of object in each technology, we thought it would be a good idea to specify the messages/changes/pojos in some kind of abstract language and then generate objects for each target language. At some point these objects could then be serialized/deserialized and sent over the wire (probably via http/s). For this purpose we thought of Google's protocol buffers or Thrift. What do you think?
For the moment our synchronous request-response-cycle is enough but we will need asynchronous request-response or server-push respectively pretty soon. That's why we thought of using something like ActiveMQ straight away. What do you think? Too much? If not, how can we accomplish the object generation mentioned above (xsd, jaxb, ? for js)? Are there better ways? I've never used ActiveMQ but according to the website it should be possible with Java, C# (Spring.NET) and somehow with Javascript (STOMP) too. However, this seems pretty complex to me...
Any tips, hints, experiences or comments about this or related topics would be really helpful.
Thank you in advance.
I would recommend using webservices. The WSDL language defines objects and messages of your protocol in abstract form. Most modern languages like Java and C# have tools for converting WSDL to native types and libraries for handling I/O.
For the last two years i have been involved in building a similar system: backend for our project is c#, java and bunch of other languages, frontend is phone clients for ios, android, symbian, all the common webbrowsers and even windows desktop apps.
For all these services we use JSON, since it seems to be most widely supported format across all languages and platforms, it decodes fairly fast on the clients compared to xml based solution (esp. webbrowsers/javascript) and it has a pretty low overhead that compresses extremely well which is great for clients that lack bandwidth.
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.