Introduction
Making your application plugin-aware is an excellent way of ensuring easy upgradability should you want to change part, but not all of it.
Plugin Architecture
The best way to implement plugins in your application is with Interfaces. Any class implementing an interface must implement every member on the interface, so any application that knows about the interface knows exactly what to expect.
You start off by building a class library with the interface(s) in. Usually you would use at least two. The minimum you could have is one, which every plugin class would implement. However, in practice you generally need another interface, which the host implements so the plugins have some way of communicating back to the host application. When the interface class library has been built, you write the host application which references this library, and can inspect any number of DLLs to see if they contain classes that implement these interfaces. At this point you can develop the plugins themselves, again referencing the class library to implement those interfaces.
Writing the Interfaces
First we create a new project of type Class Library, and define the two interfaces. For the purposes of this tutorial they will be very simple. Each plugin will offer a property with the name of the plugin, and a function which accepts two integers and returns a double. The host interface will expose a method so that the plugin can cause the host to show a message box.
When you create a project of type Class Library, there will be one class there by default. We want to clear this and define an interface rather than a class:
public interface IPlugin
{
void Initialize(IHost Host);
string Name { get; }
double Calculate(int int1, int int2);
}
public interface IHost{void ShowFeedback(string strFeedback);}
Lastly we set the build output directory to a common directory, where we’ll also put the host application and the plugins.
Writing the first plugin
Since we’ll need at least one to test the host application with, now we can write a simple plugin. Again, we create a new project of type Class Library, set the build output directory, and make sure we reference the interface class library we just created. Next, we modify the class provided thus:
public class Class1 : PluginSample.Interfaces.IPlugin
{
private PluginSample.Interfaces.IHost objHost;
public void Initialize(PluginSample.Interfaces.IHost Host)
{ objHost = Host; }
public string Name {
get { return “Example Plugin 1 - Adds two numbers”; }
}
public double Calculate(int int1, int int2)
{
return int1 + int2;
}
}
We’ve just created a simple plugin, which adds the two numbers provided together. Although we are accepting and storing a reference to the host interface, we don’t actually use it. We’ll do that in the next plugin we write.
Writing the Host Application
We create a new project, of type Windows Application. The first thing to do is reference the class library we just created, and set the build output to the same directory.
The main content of this article is the process of examining DLLs to see if they contain plugins, storing the information about what plugins are available, and instantiating and using them. To do this, I will provide a class, PluginServices.vb, which will encapsulate all these things.
To get our list of plugins, we use the function FindPlugins which accepts a string containing the directory to search in, and a string with the full name of the interface we’re looking for classes that implement. This function enumerates over all files with the extension .dll in the directory supplied, loads them using Assembly.LoadFrom() and passes execution to another function to examine the assembly.
public static AvailablePlugin[] FindPlugins(string strPath, string strInterface)
{
ArrayList Plugins = new ArrayList();
string[] strDLLs = null;
int intIndex = 0;
Assembly objDLL = default(Assembly);
//Go through all DLLs in the directory, attempting to load them
strDLLs = Directory.GetFileSystemEntries(strPath, “*.dll”);
for (intIndex = 0; intIndex <= strDLLs.Length - 1; intIndex++) {
try {
objDLL = Assembly.LoadFrom(strDLLs(intIndex));
ExamineAssembly(objDLL, strInterface, Plugins);
}
catch (Exception e) {
}
//Error loading DLL, we don’t need to do anything special
}
//Return all plugins found
AvailablePlugin[] Results = new AvailablePlugin[Plugins.Count];
if (Plugins.Count != 0) {
Plugins.CopyTo(Results);
return Results;
}
else {
return null;
}
}
Once all files have been examined, the function returns an array of type AvailablePlugin if some were found, or Nothing if none were found. As you can see, this function calls ExamineAssembly to inspect a loaded assembly.
The ExamineAssembly function enumerates all types exported by the loaded assembly, and uses the GetInterface() method of each type to see if it implements our interface. Conveniently, this method takes a string containing the fully qualified name of the interface. In this case, it’s “PluginSample.Interfaces.IPlugin” we’re looking for. If a type is found that implements the interface, an entry is added to the ArrayList with the full path of the DLL and the full name of the class.
private static void ExamineAssembly(Assembly objDLL, string strInterface, ArrayList Plugins)
{
Type objType = default(Type);
Type objInterface = default(Type);
AvailablePlugin Plugin = default(AvailablePlugin);
//Loop through each type in the DLL
foreach (var objType in objDLL.GetTypes) {
//Only look at public types
if (objType.IsPublic == true) {
//Ignore abstract classes
if (!((objType.Attributes & TypeAttributes.Abstract) == TypeAttributes.Abstract)) {
//See if this type implements our interface
objInterface = objType.GetInterface(strInterface, true);
if ((objInterface != null)) {
//It does
Plugin = new AvailablePlugin();
Plugin.AssemblyPath = objDLL.Location;
Plugin.ClassName = objType.FullName;
Plugins.Add(Plugin);
}
}
}
}
}
Lastly, we write the function that will be used to create an instance of a plugin where needed. It accepts an AvailablePlugin structure and returns an Object, to be casted to the appropriate type by the calling procedure.
public static object CreateInstance(AvailablePlugin Plugin)
{
Assembly objDLL = default(Assembly);
object objPlugin = null;
try {
//Load dll
objDLL = Assembly.LoadFrom(Plugin.AssemblyPath);
//Create and return class instance
objPlugin = objDLL.CreateInstance(Plugin.ClassName);
}
catch (Exception e) {
return null;
}
return objPlugin;
}
That’s about it for the PluginServices.vb file. The rest of the application is pretty simple. In the Sub Main, we call the FindPlugins method and populate a list on the form. The user can select a plugin from this list, and has the opportunity to enter two numbers and run the plugin to see what it returns.
One more thing is needed however, and that is to create the class in the host application which implements the IHost interface, and provides the plugins with a way of calling methods in the host application. For the purposes of this sample, the method will simply display a message box.
I won’t go in to everything else in the host application, hopefully the code will explain itself. It’s worth noting, however, that while in this sample we create an instance of a plugin each time we want to perform a calculation, usually the lifetime of a plugin object would be much longer










Even though the interior decor is not a part of the marquee itself, it becomes associated with it. From flower and table arrangements to fire places and goldfish ponds, there are many ways to make your marquee the talk of the town.
Wholesale Hats