Introduction to Building a Plug-In Architecture Using C#

Using this technique, we will use the standard GOF State Pattern by having a host application expose a piece of functionality as interface. The host will then load different implementations based on some criteria that we'll be choosing. Once we have a class that implements this interface, it can be "plugged" into the host application by dropping the containing dll into a specified folder which provides the host application with a "pluggable" implementation of the exposed interface.

For this article we'll be using a the following very simple interface that will allow us to build plug-in components that the host can use to perform a calculation on two integers and expose the symbol representing the calculation. (Of course, in a real application the interface for the plug-in would probably be much more complex but we'll keep it simple here to keep the focus on the technique.)

We could have multiple implementations of this interface in our main project or in seperate assemblies that would all look similiar to this class with slightly different implementations:

Injecting our implementation of the ICalculator interface with the constructor, we could provide a default behavior (division) for a host class while at the same time allowing for other implementations to be injected into our host class. This pattern also makes the host class easier to unit test.

}

What we want to be able to do at the end of the day, is drop a new dll implementing ICalculator into a folder and have the application be able to consume and use the new functionality through a late binding mechanism. For this particular implementation we'll be placing all the plug-in dlls in a folder called "Plugins" which will a sub directory where the main application's assembly lives. (Note: Because this is just a sample app and not bullet-proof, when you unzip and build the samples, you may have to manually add the "Plugins" sub-folder to avoid a runtime exception. Of course, you'll also have to place the plug-in dlls into this folder for the host application to load them.).

Because our late-binding mechanism uses reflection we will be taking a perf hit. One way to minimize the impact is to try to cache the results of this operation. In order to do this, we'll use a static class to hold the results of our binding. One approach would be to perform our late binding when the application starts. In this particular implementation we'll use the lazy-load approach and create a loader method that will populate a list of CalculatorHost objects and so we will take the hit the first time the application requests the plugins (which will probably be early in the life of the application).

When Reload() is called for the first time, we will create the new list. We also may want to reload the plugins while our application is running. For instance, if we have dropped a new implementation in the "Plugings" subdirectory and can't afford to restart the application. In this case, we'll clear the existing calculators list.

Next we'll load all the assemblies in the "Plugins" subdirectory and iterate through them to locate the ones that we can use for creating a new CalculatorHost object.