creating long-lived server for other applications on windows

Question

I've looked into COM servers and Windows services but I'm not sure what best suits my purposes or how to do it. What I want is something that can be started and run for an indefinite amount of time which holds an object so that other processes or applications obtain references to that object (or make requests to the server) to modify or query its state.

The server is essentially an application which processes commands to a device over a serial port and maintains an internal state of the device.

I have the device communication and persistence functionality written in C# right now and it can be created and run on a per-process basis but obviously I want it to instantiate once and run independently of other processes.

COM tutorials I've read have only confused me since I wasn't entirely sure if that is what I wanted and I was hoping there'd be more of a .Net way to do this.

Any help would be immensely appreciated!

Answer 1

this seems like a natural fit for a windows service. i should say that i'm not a .net programmer, but i understand you can create services with .net. as long as you know you can manipulate the serial port with .net you should be good to go.

-don

Answer 2

I would build a Windows Communication Foundation (WCF) service for this and expose it with one of the many bindings that is available. You can expose it via HTTP/SOAP, HTTP/REST, TCP/Binary, MSMQ, etc. all from the same service. If you have Windows 2008, you can activate it via Windows Activation Service (WAS). If you have some other Windows OS, you should write a Windows Service that you can register with the Service Control Manager (SCM). There are a lot of options here but I would definitely lean toward using WCF to create your service. There's so much "plumbing" that WCF takes care of for you. No need to reinvent all of that. Hope this helps.

Answer 3

Your requirements are a bit contradictory -- if the server has to run indefinitely, regardless of whether there are clients to serve or not, and the process has to be shared among all clients, regardless of the session they run in, Windows Services are the way to go.

If you want to have the server only run when there are clients and maybe (or not) want those clients to share the same server process, COM Out Of Process Servers can be an option.

In case of COM, you would have to use DCOM to communicate with the server process. In case of services, you could use DCOM, named pipes, RPC, or some other IPC mechanism.

If you wish to code the server in C#, however, DCOM seems a bit of an odd choice -- it is possible to create DCOM servers in C#, but it is really awkward. As Kevin noted, WCF/WAS/Remoting might be the easier choice. But keep in mind that such a solution will almost necessarily have a significantly higher overhead w.r.t. memory consumption than a native COM server or service. If this piece of software is going to be installed on client machines, I would therefore prefer a native solution.

Answer 4

You seem to be asking for two things -

1. a way to host a long-running, persistent application on Windows, which will fiddle with some device or other over the serial port.
2. a way to communicate to that application from other applications.

A Windows Service is a nice solution to the first. The Windows Service acts as an application host for your custom logic. It gives you start/stop and lightweight monitoring and config capability through a common UI and API. It's easy to build Windows Services in C#. It is easy to start and stop Windows Services from the command line, from an app, from a GUI tool.

Think of WCF as primarily a communication interface. WCF can be used to construct the external interface exposed by the Windows Service. If you want to connect to the app (service) from .NET or HTTP clients (REST or SOAP), then WCF will work for you.

COM .... The confusion you are experiencing around where COM fits in, is due to the fact that COM couples an interface mechanism (IDispatch, IUnknown, etc) with a hosting + lifecycle model (Local servers, Inproc servers, Remote servers, auto start upon request, etc). The hosting and lifecycle stuff in COM worked, but it was always pretty slim. Hard to know which services were up, and for how long. Hard to start and stop on demand.

COM, in this situation, like WCF, is primarily of interest as a communication interface. If you want to use a component-based interface to connect to the service, COM may be a good complement to the Windows Service for hosting.

COM and WCF (REST or SOAP) are not mutually exclusive, and in fact many apps expose multiple interfaces. You might elect to do one, or the other, or both. There's no wrong answer, it depends on your requirements.

If I were doing this, I would use a Windows Service, and also I would expose a COM interface from that service, as described here. The lifecycle and hosting stuff is taken care of by the Windows Service. The service is then accessible via COM, which means via virtually any programming or script language / environment. Javascript, VB6, Excel or OFfice, Python, Perl, etc.

I'd also think about exposing a WCF interface from the service. This would allow any REST client to connect, as well. Think of WCF as the wireless phone, and COM as the landline. Sometimes you want only one. Sometimes you want both.