Windows Service Plus GUI/C#

Question

I've seen some apps that run as a windows service but can still provide a GUI that allows the user to see what's actually going on.

For example, we've got a windows service that builds reports. There are a number of stats that admins would like to see, such as how many reports are queued up, how much ram is in use, avg build time, etc.

What we'd like to do is provide a way for the admin to see this - such as an app that can connect to the window service to gather and display this information... or maybe a way that the app itself can provide its own GUI and display it when requested. Right now, the only thing the app does it create a log file.

Is there a way to do this?

Answer 1

Ideally services are completely separated from the User Interface for many reasons I won't get into.

However you can use some manner of IPC to view information such as this. My recommendation would be to use Remoting to request the data needed from the service, and then build whatever reports or graphs as needed into a separate application.

Answer 2

Several.

1. Have some sort of component that hooks into your windows service and sends information to another application via remoting. If you have an IoC container a clever use of decorators can do that
2. Use a service bus, MSMQ, WCF, Growl or something like that to broadcast interesting information. Applications simply need to know how to hook in.
3. Expose an HTTP endpoint or something where someone can connect to and download information on the windows service
4. Or simply create a one-page WinForms app that reads the log file every so often and displays interesting results.

(Notice that last one is by far the simplest - hint hint, do that.)

Answer 3

Services aren't allowed to make UI API calls (except one specific form of message box). So services that appear to have have a wser interface are actually two processes. The Service process is communicating with a standard Windows APP using some sort of proprietary backchannel. Could be a named pipe, a socket, or a hunk of named shared memory.