Plug-in Engine with Event Support

• Download source files - 22.9 Kb
• Download demo project - 22.3 Kb

Introduction

Currently, I am working on creating an advanced multi-protocol IM program similar to GAIM or Trillian. However, I wanted to make the program completely extensible so that anyone could create a plug-in with a simple understanding of the application core. I looked at some of the other plug-in engines on CodeProject but couldn’t find any that did exactly what I wanted. In order for those engines to work, they needed to know specific information about all of its plug-ins, which I didn’t want to know. I wanted it so that anyone could create a plug-in without having to recompile the core at all. I started with the Dynamic Plug-in Engine by Bob Aman.

Changes to the Original Plug-in Engine

Loading Plug-ins

I wanted the plug-in developers to have other classes in their DLL besides the actual plug-in, and so I wanted some way to distinguish between classes that should be loaded and those that shouldn’t. The solution that I decided was best was to simply force all plug-ins to have an attribute, and I would check for the existence of that attribute before I saved the type as a valid plug-in.

Instantiating Plug-ins

I was running into problems with Aman’s engine because of his RemoteClassLoader that was running in a separate AppDomain. Whenever I tried to get any information about the classes and types I created, I was getting FileNotFoundExceptions because the calls I was making were trying to cross the AppDomain. Therefore, I decided that it was best to create the instance in the LocalClassLoader and use the remote one just to store all of the types of plug-ins that could be loaded.

The new LocalClassLoader.CreateInstance:

public object CreateInstance(string typeName)
{
   string file;
   file  = remoteLoader.GetOwningAssembly(typeName);
   file = Path.Combine(PluginManager.pluginDirectory, file);
   ObjectHandle oh = Activator.CreateInstanceFrom(file, typeName);
   return oh.Unwrap();
}

The important method calls are GetOwningAssembly() and CreateInstanceFrom().

• GetOwningAssembly() is what I replaced RemoteClassLoader’s CreateInstance with, and all it does is find the assembly that contains the given type name, and returns the name of the file that contains the assembly.
• CreateInstanceFrom() is a standard system method that is used to create objects in the current AppDomain. This also includes any references so that there is no complicated crossing of the AppDomain.

Listening to Events from Plug-ins

Adding the Event Handlers

private static void AddEventHandlers(object o)
{
 foreach (EventInfo ev in o.GetType().GetEvents())
 {
    ev.AddEventHandler(o, 
      Delegate.CreateDelegate(ev.EventHandlerType, 
      typeof(Core), "Event"));
 }
}

This method uses reflection to find all of the public events in o, and adds an event handler for each of them that goes to the method Event. The advantage of this is that all events will be processed by one method, so there can be, in theory, an infinite amount of different events that the core doesn’t have to know anything about. The only requirement of these events is that they have the right delegate syntax. The delegate that I defined for the events is:

NotifyCore(object sender, string name, EventArgs e);

The sender and EventArgs are the same as a simple event handler, but the name parameter is where the real power of our plug-in engine happens, but I will go into that later.

Capturing the Events

Capturing the events is a trivial process because of the single method Event that listens to all the events thrown by any plug-in. The body of Event is:

internal static void Event(object sender, string name, EventArgs e)
{
   foreach (CoreEventListener cel in listeners)
   {
      cel.onEvent(sender, name, e);
   }
}

As you can see, this does nothing but iterate through all of the CoreEventListeners, and calls a method called onEvent with the same parameters that the event threw. The important thing is to now describe what a CoreEventListener is. A CoreEventListener is a special type of plug-in that, as you might have guessed, listens to events thrown from the other plug-ins. When a new CoreEventListener is created, it is added to the List called listeners.

Re-throwing the Events

The events are thrown back to the CoreEventListeners in the onEvent method:

public void onEvent(object sender, string Name, EventArgs e)
{
   if (sender != null && sender.GetType() 
                      == this.GetType()) return;
   foreach (MethodInfo mi in this.GetType().GetMethods())
   {
       if (mi.Name == Name)
        {
            mi.Invoke(this, new object[] { sender, 
               Convert.ChangeType(e, e.GetType()) });
       }
   }
}

The first thing this method does is check if this event came from the current CoreEventListeners, and, if so, return because listening to your own events could propose some problems. The foreach statement again uses Reflection to search for the method that has the same name as the event. That is the real magic of the Name parameter. You can put anything in there, and if someone created a method with the same name, it would “throw” the event to that class. Another interesting statement in this method is the Convert.ChangeType call. This allows for using subclasses of EventArgs to throw methods, and dynamically casts it to the correct type before it is sent so that the capturing method doesn’t have to cast it but can instead use the correct EventArgs in the method declaration.

Example

Included in the Plug-in Manager are two example plug-ins. These plug-ins emulate how easy it is to communicate using events. The plug-ins send a message event to the other and display the output on their form.

Conclusion

The Plug-in Engine start method has an Application.Run statement, so when you start it you need to close it. The reason I decided to do this is because it is a static class and it needs to stay open, so I decided it was best to do it this way. If you have any questions, suggestions, or comments, feel free to email me at rpgprog@gmail.com.