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.

Answer 2

Check this out: Multiple Instance .NET Windows Service

Answer 3

There is option #4 that I'm successfully using in my project aka "named instances".

Every installation of your app has custom name and each installation has its own service. They are completely independent and isolated from each other. MS SQL Server is using this model if you try to install it multiple time on single machine.