>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.