Wednesday, October 09, 2002
Windows Service Plug-Ins
Windows Services are difficult to create and debug. There is no user interaction by design, and the system usually has a hard time releasing the service once installed and ran. In the first part of this two-part series, Rob Chartier shows how to create an extensible Windows Service that accepts custom plug-ins and never needs modification. [Sam Gentile]
I came up with a similar design for a prototype. I wanted to avoid reinstalling the service every time I need to update the behavior of the service. The code that the service runs lives in a separate assembly. The service talks to that core assembly through a well-defined interface.
But there are a lot of security concerns. What happens if someone replaces the core assembly with a malicious one? If you load the assembly based on a class name in the configuration file then it is even easier to get in trouble this way.
My initial thought would be to use a strongly named assembly. Then verify the assembly you are loading before running the code it contains. But it would take a lot of testing to make sure you get this right.
You could/should also create a sandbox using Code Access Security. But this would make it difficult to create a generic "plug-in" service that solves a wide range of problems.
I guess what I'm saying is this: If you need someone to walk you through the process of creating a Windows Service in VS.NET, you have no business implementing the design that Robert Chartier describes.
Nothing is as Simple as it Seems.
11:18:51 AM
