Gui and Windows Service Communication

GUI and windows service communication

If you are going to be developing with .NET, use WCF for your interprocess communication. WCF greatly simplifies development because the intricacies associated with a specific communication mechanism (e.g., sockets, pipes, etc.) are abstracted behind a unified programming model. Thus, it doesn't matter if you choose to use http, tcp, or named pipes for your transport mechanism, the programming model is the same.

I would highly recommend Juval Lowy's book Programming WCF Services for all things WCF. You can also visit his website, IDesign.net, for free WCF code samples.

For an overview of WCF, watch this free video at dnrTV. It covers the purpose of WCF and demonstrates WCF programming through some easy-to-follow examples.

If you have not already created your Windows service but plan to do so in C#, you can follow the step-by-step here.

Communication between Windows Service and Desktop Application

Don't get scared away by the named pipes concept, WCF will take care of the nasty bits for you. You'll only have to do the configuration, it's simply another communication channel, instead of using HTTP for example. So you'll need to look into WCF.

Check out this tutorial.

Communication between windows service and desktop app

sure you can use named pipes, WCF many other IPC methods.

for named pipe example among stack overflow questions, see here as well for some backgound:

Inter process communication using Windows service

also check this one: GUI and windows service communication

Communicate with clients from windows service

Original project was declined and only recently it was brought up again. I've revisited the problem and ended up with two solutions:

1. use Managed Extensibility Framework to load 3rd party pluggable modules into local system context (via interface). This can be used when plugin required local system access permissions.

2. use WCF for inter-process communication (say, using named pipes transport for local clients) when 3rd party module do not require local system access permissions and can run under different security context.

How to communicate with a windows service from an application that interacts with the desktop?

Be aware that if you are planning to eventually deploy on Windows Vista or Windows Server 2008, many ways that this can be done today will not work. This is because of the introduction of a new security feature called "Session 0 Isolation".

Most windows services have been moved to run in Session 0 now in order to properly isolate them from the rest of the system. An extension of this is that the first user to login to the system no longer is placed in Session #0, they are placed in Session 1. And hence, the isolation will break code that does certain types of communication between services and desktop applications.

The best way to write code today that will work on Vista and Server 2008 going forward when doing communication between services and applications is to use a proper cross-process API like RPC, Named Pipes, etc. Do not use SendMessage/PostMessage as that will fail under Session 0 Isolation.

http://www.microsoft.com/whdc/system/vista/services.mspx

Now, given your requirements, you are going to be in a bit of a pickle. For the cross-platform concerns, I'm not sure if Remoting would be supported. You may have to drop down and go all the way back to sockets: http://msdn.microsoft.com/en-us/library/system.net.sockets.aspx

---

Related Topics