Multiple Instances of same Application as a Windows Service?

Question

I have an application that manages the heavy processing for my project, and need to convert it to a "Windows Service." I need to allow running multiple versions instances of the application processing, which seems to be a fairly normal requirement.

I can see at least three approaches to do this:

1. Create a single installed directory (EXE, DLLs, config) but install as multiple Services instances from it.
2. Have a single Services instance spawn multiple instances of itself after launching, a la Apache.
3. Have a single Services instance spawn multiple threads that work within the same process space.

My intention was approach #1, but I kept tripping over the limitations, both in design and especially documentation for Services:

• Are parameters ever passed to OnStart() by the normal Services mechanisms on an unattended system? If so, when/why?
• Passing run-time parameters via the ImageKey registry seems a kludge, is there a better mechanism?
• I got the app to install/uninstall itself as a pair of services ("XYZ #1", "XYZ #2", ...), using the ImageKey to hand it a command line parameter instance number ("-x 1", "-x 2") but I was missing something. When attempting to start the service, it would fail with "The executable program that this service is configured to run in does not implement the service.

So, the questions:

1. Is there a concise description of what happens when a service starts, specifically for those situations where the ServiceName is not hard-coded (see Q above).
2. Has anyone used approach #1 successfully? Any comments?

NOTE: I've side-stepped the problem by using approach #3, so I can't justify much time figuring this out. But I thought someone might have information on how to implement #1 -- or good reasons why it isn't a good idea.

[Edit] I originally had a 4th option (install multiple copies of the application on the hard drive) but I removed it because it just feels, um, hackish. That's why I said "at least three approaches".

However, unless the app is recompiled, it must dynamically set its ServiceName, hence that has the solution to the third bullet/problem above. So, unless an instance needed to alter it's install files, #1 should work fine with N config files in the directory and a registry entry indicating which the instance should use.

Answer 1

Though I can't answer your questions specific to option #1, I can tell you that option #2 worked very well for us. We wanted to create an app domain for each 'child' service to run under and for each of them to use a different configuration file. In our service's config file we stored the app domains to start and the configuration file to use. So for each entry we simply created the app domain, set the configuration file etc and off we went. This separation of configuration allowed us to easily specify the ports and log file locations uniquely for each instance. Of additional benefit to us was that we wrote our 'child service' as a command-line exe and simply called the AppDomain's ExecuteAssembly() on a new thread for each 'child' service. The only 'clunk' in the solution was shutdown, we didn't bother to create a 'good' solution for it.

Update Feb, 2012

Some time ago we started using 'named' services (like SQL Server). I detailed the entire process on my blog in a series "Building a Windows Service – Part 1 through Part 7". They take you through creating a command-line/windows service hybrid complete with self-installation. The following goals where met:

• Building a service that can also be used from the console
• Proper event logging of service startup/shutdown and other activities
• Allowing multiple instances by using command-line arguments
• Self installation of service and event log
• Proper event logging of service exceptions and errors
• Controlling of start-up, shutdown and restart options
• Handling custom service commands, power, and session events
• Customizing service security and access control

A complete Visual Studio project template is available in the last article of the series Building a Windows Service – Part 7: Finishing touches.