As per my knowledge, I knew that messages can posted from one application to other application using "SendMessage" or "PostMessage".
I tried using SignalR to communicate b/w the applications. The problem here i found was server should be launched as a console application and clients will be my winforms. Ideally I don't want to show this console application as it seems to be weird for the user. If there is any work around for this approach please suggest.
After signalR I came across EventAggregrator in c#. Can we use EventAggregrator to communicate b/w two different C# applications? If yes could some one give an example on how to do this.
Until a few years ago, Socket class was the right way to do this. There are probably more modern, robust and easier ways to achieve the same result nowadays, but you may want to look at what's under the hood.
Socket class on MSDN:
https://msdn.microsoft.com/it-it/library/system.net.sockets.socket%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396
Client-server example on CodeProject:
https://www.codeproject.com/articles/463947/working-with-sockets-in-csharp
Related
This question already has answers here:
Can I communicate between Java and C# using just sockets?
(2 answers)
Closed 9 years ago.
I am about to develop a server using the Java language for a game.
The game is written in C#, and they are going to communicate through sockets.
The only way I can come up with is using JSON.
What is the proper way to do this?
The proper way is to have either a RESTful or a SOAP-based web service on the server
side and the client to call it. This is also going through sockets on the lowest level.
If you want, you can implement socket-based communication yourself (no REST/SOAP)
but I would not recommend it as it will make your job more difficult and error-prone.
But on the other hand, this may be more efficient, if you implement it well.
So you have many options, it all depends on the exact needs/requirements.
If you want to communicate properly your applications, I suggest you think about a multi-threaded server, in which every worker thread should poll the open socket and deal with the request, and you should write all this with kind of low-level I/O and multi-threading APIs.
Though it is possible to do it, I must recommend you to leave your communications to an application server, for example a Tomcat server or something similar. There you can deploy your java server as a web application implementing a REST or SOAP based webservice.
This way, you are covered with a production-strength server doing your communications duty for you, and can focus on writing a standard webservice client in C# (I admit I can be of little or no help at all in C#, but I guess someone here will be glad to help you there).
If your looking for a convenient API / library to communicate between apps, you may want to consider zeroMQ.
For webserver-client models. You may want to consider implementing a HTTP REST/SOAP interface.
I'm learning to work with sockets, and every example in every article or book demonstrates how a server should work using a desktop console or wpf application. The authors usually say that the same code can be easily implemented on the server.
Maybe it's easy, but still -- how? Do I have to use WCF or maybe something else? Is there any good book which can help me to become the lord of sockets?
The "same code on the server" comment means you're really developing a communications interface protocol. You send messages in a particular way, and expect to receive in the same way. Eg. fixed length messages vs agreed terminator; how message data is formatted etc.
If you put your code into it's own set of classes you can then host your code in any sort of application - console, wpf as you've stated but also.. windows services. In my case i've got it so that running the app in debug mode runs winforms, but as release mode runs as a service.
The answer to this SO question has some useful links.
Chat service application
I highly recommend Vadym's posts and Stephen Cleary's nito documentation.
I'm writing a web server app for the first time, and I'm not really sure that I know what I'm doing.
Basically I have some server side C# code and a native iOS app. I need to be able to push updates from the server to the app. The method which we have decided to use is Long Polling, and I can see three ways of doing this:
1) Writing my own web server in C# - not neccesarily tempting as it requires re-inventing the wheel
2) Using WCF - I've seen a few articles about how to implement long polling over WCF, but the tutorials that I've seen all seem to use clients which are implemented in .NET WCF which is not applicable for me as I need to use an iOS app.
3) Something else, possibly using IIS - I don't really know where to begin with this option.
Can anyone recommend a good tutorial, or exemplar project which uses standard HTTP to implement long polling with a C# server? So long as it's using standard HTTP, I'm confident with the iOS side of things.
Obviously if there's an even neater way of doing things then I'm all ears as well.
I would highly recommend that you investigate SignalR which allows you to achieve exactly what you are after. There are many iOS tutorials as well as HTML / JavaScript and of course C#.
One of the benefits of SignalR is that it tries to use the best technology available on the various devices and down-grades until it works. So, will start with Web Sockets for example and fail down to long-polling if nothing better is available.
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.
I have two C# programs and I want to send some data back and forth between them. (And check if the data arrived to the other application.)
The two programs will always run on the same computer, so no networking capability is required. I've already read some questions with similar topics here, but I'm not entirely sure which is the right method for me. (WCF, Remoting, etc.)
What I want to know, is which one is the easier to implement for a beginner in C#?
(I don't want it to get too complicated anyway, it's only a few integers and some text that I want to send.)
If there isn't a real difference in difficulty, what advantages does one have over the other?
I'd really appreciate some simple example code as well.
Thanks in advance.
You can use Pipes to send data between different instances of your application. If you just need to tell the other instance that something has happened you can send messages from one application to another by using SendMessage api.
WCF essentially packages up the various methods of communication between applications (web services, remoting, MSMQ etc) in a single package, so that they are programmatically the same in the way that they are used, and the detail of what method is used is left for configuration of the binding between. A slight simplification perhaps, but essentially what it's about.
It is worth getting into WCF if you need inter-process communication, and this would certainly be my advice as to the way to go with this. It's worth looking at IDesign, who produce a number of articles on the subject, as well as some reusable code libraries, that you may find useful. Their Juval Lowy has also written an excellent book on the subject,
Another good point about WCF is that if your requirements ever change and all of a sudden you have to move one of the application to a different machine, requiring now network capability, you will only need to change configuration on both sides, instead of having to recode.
Plus, ad David said, WCF is a good tool to have in your bag.
Cheers, Wagner.
I found MSMQ is simple to implement.