I'm building a distributed system with separate modules in C# and .NET that will interact over the network. Each module will have common underlying features in that it will run as a Windows service, it will have logging features, support for loading settings from an XML file, support for connecting to other modules based on that XML file and so on. I have no problem implementing all this but what I am struggling a little with is whether I can abstract all this away in a clean manner so that that the actual logic that will sit on top of this can be implemented fairly easily. Ideally all the creation of a new module would require is implementing a class that inherits from another that implements the service, the logging features etc. and having to specify this inherited class somewhere, presumably at creation in the application entry point. The problem I'm running into is primarily with abstracting out the Windows service stuff and I think creation of a new module is going to be a little less simple in that the application entry point will have to initialize the service, but also that it's not straightforward to inherit from the default Windows service created by VS being a partial class with part being looked after by the code designer. Each service will just need an icon in the system tray and handle input via the network, process it and pass it back over the network so there's nothing particularly special required there. Does anyone have any recommendations on the cleanest way to architect Windows services like this such that the logic is cleanly separated from the underlying core and common components of the service? Thanks in advance!

Since you are using C# and .net it is not as hard as you are trying to make it. Instead of trying to abstract everything, instead you should auto-discover everything. Use "reflection" to find out what the modules can do and use them. It is much easier then trying to do anything else.

theTroll