Take the 2-minute tour ×

I am building a .NET based application, and would like to allow a more extensible and pluggable design.

For the sake of simplicity, the application exposes a set of operations and events:

  • DoSomething()
  • DoOtherThing()
  • OnError
  • OnSuccess

I would like to offer "plugins" to be loaded and hook into some of these operations (something like: When Event1 fires, run plugin1).

For example -- run plugin1.HandleError() when the OnError event fires.

This can be done easily with event subscription:

this.OnError += new Plugin1().HandleError();

The problem is that:

  1. My app doesn't know of the type "Plugin1" (it is a plugin, my app does not reference it directly).
  2. Doing so will instantiate the plugin before time, something i do not want to do.

In "traditional" plugin models, the application ("client" of plugins) loads and executes the plugin code at certain key points.For example -- an image processing application, when a certain operation is performed).

The control of when to instantiate the plugin code and when to execute it are known to the client application.

In my application, the plugin itself is to decide when it should execute ("Plugin should register on the OnError event").

Keeping the plugin "execution" code alongside "registration" code poses an issue that the plugin DLL with will get loaded into memory at registration time, something i wish to prevent.

For example, if i add a Register() method in the plugin DLL, the plugin DLL will have to get loaded into memory in order for the Register method to be called.

What could be a good design solution for this particular issue?

  • Lazily loading (or offering lazy/eager loading) of plugin DLLs.
  • Allowing plugins to control which various parts of the system/app they hook into.
share|improve this question

4 Answers 4

You are trying to solve a non-existing problem. The mental image of all the types getting loaded when your code calls Assembly.LoadFrom() is wrong. The .NET framework takes full advantage of Windows being a demand-paged virtual memory operating system. And then some.

The ball gets rolling when you call LoadFrom(). The makes the CLR create a memory mapped file, a core operating system abstraction. It updates a bit of internal state to keep track of an assembly now being resident in the AppDomain, it is very minor. The MMF sets the up memory mapping, creating virtual memory pages that map the content of the file. Just a small descriptor in the processor's TLB. Nothing actually gets read from the assembly file.

Next you'll use reflection to try to discover a type that implements an interface. That causes the CLR to read some of the assembly metadata from the assembly. At this point, page faults cause the processor to map the content of some of the pages that cover the metadata section of the assembly into RAM. A handful of kilobytes, possibly more if the assembly contains a lot of types.

Next, the just-in-time compiler springs into action to generate code for the constructor. That causes the processor to fault the page that contains the constructor IL into RAM.

Etcetera. Core idea is that assembly content always gets read lazily, only when needed. This mechanism is not different for plugins, they work just like the regular assemblies in your solution. With the only difference that the order is slightly different. You load the assembly first, then immediately call the constructor. As opposed to calling the constructor of a type in your code and the CLR then immediately loading the assembly. It takes just as long.

share|improve this answer
My question is about shifting the responsibility of deciding When to invoke the plugin from the client code to the plugin itself. How do i let the plugin say which event should load itself and execute, without loading itself too soon? Kinda chicken and egg situation. –  lysergic-acid Apr 25 '12 at 5:46
I think what Hans is trying to say is, that your RegisterForOperation1Hooks-approach doesn't load the full assembly into memory, thus being a good solution to your problem :) –  cwap Apr 25 '12 at 6:38
I am not sure how creating a type contained in my Plugin.dll and invoking a Register() method on it will not cause the dll to load into memory. My motive is of course unloading the DLL later on (will be loaded into its own AppDomain), this will not be possible using this solution. –  lysergic-acid Apr 25 '12 at 7:16
You are missing the point badly. My solution is "don't do anything special, it is already very efficient". Which doesn't prevent unloading AppDomains. –  Hans Passant Apr 25 '12 at 9:00

What you need to do is to find the path of the dll, and then create an assembly object from it. From there, you will need to get classes you wish to retrieve (for instance, anything that implements your interface):

var assembly = Assembly.Load(AssemblyName.GetAssemblyName(fileFullName));
foreach (Type t in assembly.GetTypes())
  if (!typeof(IMyPluginInterface).IsAssignableFrom(t)) continue;
  var instance = Activator.CreateInstance(t) as IMyPluginInterface;
  //Voila, you have lazy loaded the plugin dll and hooked the plugin class to your code

Of course, from here you are free to do whatever you wish, use methods, subscribe to events etc.

share|improve this answer
the drawback of this strategy is very slow when loading the assembly. This is common issue for reflection in .Net –  David.Chu.ca Apr 24 '12 at 22:37
Thanks i already know how to do this. What i'd like to design is a way to allow the plugin to register on certain events, without loading it beforehand. –  lysergic-acid Apr 25 '12 at 7:14
I don't think its possible for the plugin dll to do anything until it's actually loaded. One solution is to put a plugin definition class in each plugin assembly that sets up the plugin/tells the host about its capabilities. When your application starts you can find all the definition classes and take the appropriate action (perhaps just calling a "Configure" method on each). –  Ben Foster Apr 25 '12 at 9:02

Would the Managed Extensibility Framework fit your needs?

share|improve this answer

For loading plugin assemblies I tend to lean on my IoC container to load the assemblies from a directory (I use StructureMap), although you can load them manually as per @Oskar's answer.

If you wanted to support loading plugins whilst your application is running, StructureMap can be "reconfigured", thus picking up any new plugins.

For your application hooks you can dispatch events to an event bus. The example below uses StructureMap to find all registered event handlers, but you could use plain old reflection or another IoC container:

public interface IEvent { }
public interface IHandle<TEvent> where TEvent : IEvent {
    void Handle(TEvent e);

public static class EventBus {
    public static void RaiseEvent(TEvent e) where TEvent : IEvent {
        foreach (var handler in ObjectFactory.GetAllInstances<IHandle<TEvent>>())

You can then raise an event like so:

public class Foo {  
    public Foo() {
        EventBus.RaiseEvent(new FooCreatedEvent { Created = DateTime.UtcNow });

public class FooCreatedEvent : IEvent {
    public DateTime Created {get;set;}

And handle it (in your plugin for example) like so:

public class FooCreatedEventHandler : IHandle<FooCreatedEvent> {
    public void Handle(FooCreatedEvent e) {
        Logger.Log("Foo created on " + e.Created.ToString());

I would definitely recommend this post by Shannon Deminick which covers many of the issues with developing pluggable applications. It's what we used as a base for our own "plugin manager".

Personally I would avoid loading the assemblies on demand. IMO it is better to have a slightly longer start up time (even less of an issue on a web application) than users of the running application having to wait for the necessary plugins to be loaded.

share|improve this answer
Interesting. The drawback (for me at least) is the overhead of creating a new class for each event, and every time i'd like to expose a new event in my system. –  lysergic-acid Apr 26 '12 at 10:24
The time it takes to create these lightweight events and handlers is probably about the same as it takes to wire up a traditional event and handler. I can't see that there is a quicker way to publish new events. –  Ben Foster Apr 26 '12 at 10:31
Also, i (sort of) lose the ability to define .NET 'events' by += subscribing to them. The event dispatching is done per your example using a method call + letting the container resolve the 'subscribed' classes. –  lysergic-acid Apr 26 '12 at 21:02

Your Answer


