views:

3110

answers:

5

What is the standard way for allowing and implementing a plugin system for your application?

In my last application I made a simple interface for all plugins that they must implement. I then load all assemblies in the apps directory and toss out any that don't implement that interface.

One of the methods in the interface is a DoWork() method that periodically gets called on all loaded assemblies to perform any actions the plugins may have.

What is the "proper" way to do a plugin system? Do you just create an Interface for plugins? Should you periodically call a particular method in all plugins? Is there a more sophisticated way?


EDIT:

Thank you Matt Hamilton for the reference to the System.Addin namespace. This will most likely be the way I implement my plugins. However, I am still curious about plugin architecture in general and wouldn't mind some background on the best way they should be designed, implmemented.. how you should call on them once loaded, etc.

+7  A: 

Check out the System.AddIn namespace as per this response to a similar question.

Matt Hamilton
+7  A: 

There are some great walkthroughs over on the dnrTV website:

Carl Franklin on Plug-Ins in .NET

Mark Miller on Load on Demand

Miguel Castro on Extensibility

Matt Hamilton
+5  A: 

Glenn Block and Brad Abrams at Microsoft have recently released the Managed Extensibility Framework that provides a framework for dealing with exactly what you are talking about.

The documentation and download are available here.

Glenn's and Brad's blogs are also great resources for MEF.

JeremiahClark
+3  A: 

From a strictly design pattern perspective, you may want to take a look at OSGi (this is highly Java oriented, but is considered to be a very, very good plugin/module system). Might be overkill for what you are trying to achieve, but there is a lot of really good stuff in there about how to handle loading and unloading modules dynamically in the middle of a run, etc...

Kevin Day
+2  A: 

Miguel Castro's screencast was a really good.

David Robbins