Pattern/Method for C# Plugin Functionality

Question

Hello!

I'm working on a fresh new product that eventually will have different functionality built up around it based on individual customer requirements. Therefore, I'd like to implement the ability to have plugins that I can deploy and the core application will detect the plugins and change accordingly. The kicker is that the product will most likely be targeting earlier versions of .Net that do not support System.Addin or the possibility of MEF.

That said, which patterns/methods of programming lend themselves well to supporting plugins in C#? I'd like to stay away from third party frameworks altogether, although feel free to name one. Ideally, I would like to have the ability to drop in a plugin have it modify the main menu and/or a context menu and/or provide a new service. In Java this was handled nicely via extension points. Am I basically stuck to write my own extension point manager?

Answer 1

Hi,

You want to look at the System.Reflection namespace to aid you in this task. One approach would be to create a common interface for your plugin classes (lookup strategy pattern) and then use reflection at runtime to look at all the dll's in a given folder (maybe where the exe is or a special add-in folder) making note of the classes that contain that particular interface. In specific keep a dictionary of the types (the ones with your special interface that designates it as a plugin class). Once you have a list of those types that contain the interface designating them as a plugin you can dynamically instantiate them at will using the System.Activator class. Do the initial probing for the add-in classes at application startup and then use a abstract factory to load the plugin based on type or some other metadata that can be attributed to the class using .net attributes.

If you need specific code examples I can do this for you but, you should take the time to become familiar with System.Reflection, System.Activator, and .net attributes if you intend to build a robust and flexible add-in system.

Enjoy!

Answer 2

I'm a Java person, but since your question is related to software design patterns...

The Strategy Pattern is likely what will help you out here, on a very abstract level. So, perhaps your core application has a very basic set of "strategies" that it uses to operate... rather than, say, creating a menu bar, you call a simple menu bar strategy object to create it for you. Then, provide methods for swapping strategies (so, deploying a plugin would essentially be a matter of calling a bunch of setStrategy() methods on affected objects, or however you please). The plugin would provide alternative strategies. As for the runtime loading of plugin classes, I'm not familiar enough with C# to answer this.

As I said before, this is all very abstract. Try to avoid reflection as much as possible - while sometimes necessary, there are performance, security, and design disadvantages of using reflection.

Hope that helps!

Answer 3

Almost any "plug-in" architecture will be based on some variant of a Builder pattern - pretty much by definition.