The only thing in our application that is inherited from ServiceBase is the MyService class in the EXE, as I showed. This starts up everything else in its OnStart() method ... "everything else" are just regular old classes, none of which are inherited from ServiceBase. And we have more than one. They are all instantiated and started here. And they really don't need to be inherited from ServiceBase ... that is my point. If you need threading and stuff like that, you can put that in your classes. What is so special in the ServiceBase class that you need for your classes? In other words, why do your classes need to inherit from ServiceBase?

If all your classes get started from the one ServiceBase sub-class in the EXE, and if they themselves do not inherit from ServiceBase (but are just plain classes), then you won't any problem moving the classes up into your Framework.

~~Bonnie


>>Michel, what we've done is to keep this ServiceBase class in the EXE as it is (MyService in the example I posted previously), but when MyService starts (in the OnStart() method), we create new instances of classes that live in our Framework, which themselves have Start/Stop methods. These other Framework classes are not sub-classed from ServiceBase (nor do they need to be). And everything works. I guess the key to this working is that those Framework classes are not sub-classed from ServiceBase (judging from your post, that can't be done, but I've never tested it, so I don't know for sure).
>
>Yes, it is correct that a DLL cannot negotiate with a Windows Service. Some have succeeded by using a svchost some kind of approach which I wouldn't want to introduce in my framework.
>
>So, this is why as soon as I move up that base class in the framework that nothing works. Based on what you wrote, I assume you have the EXE, which is the Windows Service console application, which is using your framework, which is a DLL. If I understand correctly, you kept your Windows Service base class inside the EXE and instantitate your framework from there. If this is what it is, this is exactly what I am doing as well. The main entry point is instantiating from the Windows Service base class, where its OnStart() method instantiate the framework. The only think I do not like about that is that I cannot move up into the framework that Windows Service base class and this is a lot of code that many Windows Service I need to handle should benefit from. This is the core of all automation process, formely known as a Robot desktop application, and I had to re-architect all that because we need to use the Windows Service route now for various benefits which will ease the transition into a new environment with lots of domain devices and accounts.