A simple IoC container for a a small plugin system

Question

I am designing a simple plugin framework a for a .NET 3.5 application (WinForms).

Our current application needs to start supporting dynamic loading and "hooking" of different "plugins" / "extensions" that are unknown to the application at compile time.

These extensions would be "hooked" into different areas of the application, such as aded as event handlers of certain classes.

For example (simplified):

public class SomeSystem
{
     public event Action<string> Completed;

     public event Action<string> Failed;

     public event Action<string> Stopped;
}

One use case I'd like to have is for developers to be able to define handlers for such events in a plugin assembly, without having the application know about them.

From my knowledge, IoC containers allow dynamically discovering objects at runtime and registering them in a container.

Is an IoC container able to also do this hooking into various events for me? Or is this task easier to do without such a framework?

How does one go about designing how to integrate an IoC container for such a task? (suppose that there are multiple extension points, such as different events that can be used to register on).

Some questions i found myself asking :

1. Is it common that the plugin itself offer a Register method to do the registration?
2. Should the IoC do the registration? (how is that usually done?)
3. How can extension points be easily defined when using an IoC container ?

Answer 1

You probably want to look at MEF. It allows all of the things you have asked about. The terminology it uses (ComposableParts, Exports, etc) is initially confusing, but it's very straightforward to use.

Is it common that the plugin itself offer a Register method to do the registration?

MEF makes the application do the work of finding and registering plugins. The plugin only needs to implement an interface that states "I am a plugin that can do X".

Should the IoC do the registration? (how is that usually done?)

An application that will consume MEF plugins is able to specify how it will load the plugins. This could be by searching a directory for DLLs, reading the configuration file for a list of assembly names, checking the GAC - anything at all. It's totally extensible (in that you can write your own search classes)

How can extension points be easily defined when using an IoC container ?

MEF uses interfaces to define a Contract between the application and plugin.