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

It is to benefit of overrides and overloads such as mentioned in the other message I just wrote. It implies to do things in reverse.

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

Yes, that is what I have now. But, each Windows Service application have some custom initialization code, some custom initialization code for every loop of the process and some custom methods. That is why this is called from the framework as they are hooks. That is why I was looking for a while to encapsulate all that into one single class that would allow me to do that. But, for now, it seems that is the only way to do it.

Thanks