Gui/Monitor/Config/Controller for a Windows Service

[Steffer [MCP]]

Hi NG

I'm have made a server application (WinForms) but I would very much
like to move the tasks that my app runs into a Windows Service.

But have you any experience building an communication interface between
the Gui and a Windows Service, I'd like to hear from you.

Is the solution:
Sockets - with commands and data send directly
Remoting?
Web Services?
COM+?
Something else?

It's small size data that has to be transfered. Both the Winforms App
and the Windows Service can communicate with a SQL Server (same
database).
The Winforms App. also has to show what the Windows Service is doing
right now - realtime is preferred but not required.

What I want to end up with is the behavior something like WebTrends
where you have a Server that runs as a Windows Service and a
WebInterface (in my case WinForms app) running on the same machine. The
Windows Service does all the hard work while the Winforms app. tells
the Windows Service how to do it, and shows what the Windows Service is
working on.

Any suggestions?

[greg.merideth]

I've written a number of services for our office using a number of
different communication methods. For short simple messages Sockets
work just fine but when I want to get back a larger chunk of data (over
45k) I chose the remoting route.

Debugging services is a galactic pain when dealing with threads and
socket issues but once it's all working it's great.

My only complaint against .net services is the memory footprint of the
services. The template that comes with VS will generate a service that
consumes between 16-24MB on startup while doing nothing. I've started
experimenting with a windows service that dynamically loads in modules
into different appdomains to reduce the memory footprint.

Also, loading modules that are compiled with NGEN and published into
the GAL into a service makes them run a little slower overall. After
an article I read in MSDN magazine apparently thats perfectly normal.