I have several users on a single Windows Server 2012 (they are using Remote Desktop).
I have two (vb.net) programs, that need to communicate with eachothers - that is ... each user have two applications that need to communicate.
What is the easies (and most realiable) approach to have two apps communicate while several instances is running on the same box (on instance per RDS user)?
Thanks!
There're a lot of options:
Message queue (for, example, MSMQ).
ASP.NET WebAPI self-host
WCF self-host.
...
Maybe, in your case, I would go for the use of message queues. And, since MSMQ comes with Windows (in order to install it, go to Add/remove Windows features in Control Panel) and .NET Framework has support for it out-of-the-box, it could be a good choice.
Side-note
When I mention WCF/WebAPI self-host, I mean that each process can have a very tiny REST or SOAP (or whatever) API that may allow that any of the whole processes may act as clients and/or servers. It's a good way of having interprocess messaging
You can:
1) Use the SendMessage api - http://msdn.microsoft.com/en-gb/library/windows/desktop/ms644950(v=vs.85).aspx
2) Run a client-server http://www.codeproject.com/Articles/12318/Building-Client-Server-applications-with-VB-NET-fo
3) Use UDP broadcasting http://www.solidautomation.com/bryon/Using_UDP_and_Winsock_in_Visual_Basic_6.htm
Available options inter process communication would be:
WCF
Remoting
ASP.Net WebSevices
WM_COPYDATA
Socket programing
Interprocess Communications on MSDN would be resource
Related
I've never had to do IPC on Windows before. I'm developing a pair of programs, a standard GUI/CLI app, and a windows service. The app has to tell the service what to do. So, assuming the communication is local only, what would be the best communication method for these two processes?
By best I mean more robust and less error prone, not the best performance nor the easiest to code.
Note I'm asking about what to use, a standard TCP socket, named pipes, or some other means of communication only.
IPC in .Net can be achieved using:
WCF
using named pipes requires .Net 3.0 and above.
Code example
The WCF class NetNamedPipeBinding can be used for interprocess communication on the same machine. The MSDN documentaion for this class includes a code sample covering this scenario http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx
Remoting
The original IPC framework released with .Net 1.0. I believe remoting is no longer being actively developed, and you are encouraged to use WCF instead
Code example
Inter-process communication via Remoting - uses a tcp channel
Resources
GenuineChannels, sell a remoting toolkit that includes a Shared Memory Channel. http://www.genuinechannels.com/Index.aspx
Ingo Rammer, wrote the definitive .Net remoting book, Advanced .NET Remoting, Second Edition
Win32 RPC using csharptest-net RpcLibrary
I came across a project recently that has wrapped the Win32 RPC library and created a .net class library that can be used for local and remote RPC
Project home page: http://csharptest.net/projects/rpclibrary/
MSDN references:
How rpc works: http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx
RPC functions: http://msdn.microsoft.com/en-us/library/aa378623(v=VS.85).aspx
Also has a google protocol buffers rpc client that runs on top of the library: https://code.google.com/p/protobuf-csharp-rpc/
WM_COPYDATA
For completeness it's also possible to use the WIN32 method with the WM_COPYDATA message. I've used this method before in .Net 1.1 to create a single instance application opening multiple files from windows explorer.
Resources
MSDN - WM_COPYDATA
Code example
PInvoke.net declaration
Sockets
Using a custom protocol (harder)
For local only, we have had success using Named Pipes. Avoids the overhead of TCP, and is pretty much (at least for .NET) as efficient as you can get while also having a decent API to work with.
Since you are limited to .Net 2.0 WCF is perhaps not an option. You could use .Net remoting with shared memory as the underlying communication mechanism between app domains on the same machine. Using this approach you can easily put your processes on different machines and replace the shared memory protocol with a network protocol.
The standard method of communicating with a windows service is to use service control codes. Windows services can receive codes from 0 to 255. 0-127 is reserved for system. 128 to 255 can be used for custom commands.
If you need to send complex objects to the service use database, xml, file, tcp, http etc. Other than that for sending control commands like reload configuration, process items etc this control codes should be used.
There are additional functionalities available such as querying the service. See Windows service documentation and api.
http://arcanecode.com/2007/05/30/windows-services-in-c-sending-commands-to-your-windows-service-part-7/
Your best bet is to use WCF. You will be able to create a service host in the windows service and expose a well defined interface that the GUI application can consume. WCF will let you communicate via named pipes if you choose, or you can choose any other communication protocal like TCP, HTTP, etc. Using WCF you get great tool support and lots of available information.
I'd like to add to this discussion. Please rebuke me if this is way out there - but couldn't a semaphore (or multiple semaphores) be used for rudimentary communication?
I am working on two separate C# applications, and I'm trying to determine what is the best way to create a remote procedure call from one app to the other. Webservices are not necessary in this case because the applications will always run on the same machine (Windows OS). What types of RPC are available in C# and .net that I can use?
I would recommend WCF with NetNamedPipeBinding for interprocess communication. Here's an example.
There's also Remoting which has been around since .NET 1.0 but becoming obsolete in favor of WCF.
There are several options available to you here. The most prominent though are
.Net Remoting
Windows Communication Foundation (WCF)
Both can be used for communication between processes on a remote or local machine.
I would recommend .NET Remoting configured with IPC channels, in my opinion this is the fastest way of communication between applications running on the same PC.
Try Protobuffers over Win32 RPC
networkComms.net provides very general RPC functionality, see RPCExample.cs.
I wanted to set up a simple data communication between two C# applications, and I'm not sure what the best method is in doing so. I've previously used Java Sockets and ServerSockets to get the job done, but I'm new to C#, so I've come for advice :) It's going to be two way communication with two clients exchanging strings or something of the like.
WCF (Windows Communication Foundation) is what you want.
You have several options:
Using pipes
Using sockets
WCF
You're needing .NET Remoting.
Remoting can be between two apps on the same computer, or across a network.
Here is a good start, the first link is a "Hello World!" remoting application:
http://msdn.microsoft.com/en-us/library/kwdt6w2k%28VS.71%29.aspx
I would also take a look at NServiceBus. It's really easy to setup and provides you with a reliable messaging system. Any messages sent between the apps (whether the destination app is online or not) are always delivered. The library leverages MSMQ to facilitate communication.
How to call Windows Service from Windows Service in C#.NET?
Please suggest a code related to the same for calling the Windows service within Windows Service.
If by windows service you me a some code running as service under the service controller. Then any number of API's exist, from WCF, remoting, MSMQ, sockets, etc. all way to shared memory (memory mapped files). If you give us more information as to what you're trying to achieve, then we can probably be more precise.
The preferred way of communication between separate windows apps is WCF - the Windows Communication Foundation which was introduced with .NET 3.0. It supports a wide variety of communication protocols (HTTP, TCP/IP) and offer a vast number of options and possibilities.
It allows you to send messages between two programs - no matter what they are. Windows NT Services are just fine.
In order to exchange messages, you will need to define one program to be the "server" and the other to be the "client". You will also need to define a service contract - an interface that defines the communication service and its methods.
The server part then needs to implement that service, and the client needs to create a proxy for that service, and then then two sides can exchange messages.
I've never had to do IPC on Windows before. I'm developing a pair of programs, a standard GUI/CLI app, and a windows service. The app has to tell the service what to do. So, assuming the communication is local only, what would be the best communication method for these two processes?
By best I mean more robust and less error prone, not the best performance nor the easiest to code.
Note I'm asking about what to use, a standard TCP socket, named pipes, or some other means of communication only.
IPC in .Net can be achieved using:
WCF
using named pipes requires .Net 3.0 and above.
Code example
The WCF class NetNamedPipeBinding can be used for interprocess communication on the same machine. The MSDN documentaion for this class includes a code sample covering this scenario http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx
Remoting
The original IPC framework released with .Net 1.0. I believe remoting is no longer being actively developed, and you are encouraged to use WCF instead
Code example
Inter-process communication via Remoting - uses a tcp channel
Resources
GenuineChannels, sell a remoting toolkit that includes a Shared Memory Channel. http://www.genuinechannels.com/Index.aspx
Ingo Rammer, wrote the definitive .Net remoting book, Advanced .NET Remoting, Second Edition
Win32 RPC using csharptest-net RpcLibrary
I came across a project recently that has wrapped the Win32 RPC library and created a .net class library that can be used for local and remote RPC
Project home page: http://csharptest.net/projects/rpclibrary/
MSDN references:
How rpc works: http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx
RPC functions: http://msdn.microsoft.com/en-us/library/aa378623(v=VS.85).aspx
Also has a google protocol buffers rpc client that runs on top of the library: https://code.google.com/p/protobuf-csharp-rpc/
WM_COPYDATA
For completeness it's also possible to use the WIN32 method with the WM_COPYDATA message. I've used this method before in .Net 1.1 to create a single instance application opening multiple files from windows explorer.
Resources
MSDN - WM_COPYDATA
Code example
PInvoke.net declaration
Sockets
Using a custom protocol (harder)
For local only, we have had success using Named Pipes. Avoids the overhead of TCP, and is pretty much (at least for .NET) as efficient as you can get while also having a decent API to work with.
Since you are limited to .Net 2.0 WCF is perhaps not an option. You could use .Net remoting with shared memory as the underlying communication mechanism between app domains on the same machine. Using this approach you can easily put your processes on different machines and replace the shared memory protocol with a network protocol.
The standard method of communicating with a windows service is to use service control codes. Windows services can receive codes from 0 to 255. 0-127 is reserved for system. 128 to 255 can be used for custom commands.
If you need to send complex objects to the service use database, xml, file, tcp, http etc. Other than that for sending control commands like reload configuration, process items etc this control codes should be used.
There are additional functionalities available such as querying the service. See Windows service documentation and api.
http://arcanecode.com/2007/05/30/windows-services-in-c-sending-commands-to-your-windows-service-part-7/
Your best bet is to use WCF. You will be able to create a service host in the windows service and expose a well defined interface that the GUI application can consume. WCF will let you communicate via named pipes if you choose, or you can choose any other communication protocal like TCP, HTTP, etc. Using WCF you get great tool support and lots of available information.
I'd like to add to this discussion. Please rebuke me if this is way out there - but couldn't a semaphore (or multiple semaphores) be used for rudimentary communication?