Design Pattern for implementing plugins in your application?

Question

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.

Answer 1

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

Answer 2

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.

Answer 3

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...