Plugin-Ready Application Development

Introduction

Days ago I was thinking about creating some plugins for an application that I had developed. How to do that? The idea: distribute plugins as .NET DLLs that expose specific interfaces.

Architecture

Each plugin must have at least one main method attending to a specific duty. In a simple plugin system a single method is enough to draw the architecture.

Design of the interface

Supposing the plugin computes a value from a parameter, the plugin’s interface is:

interface IPlugin {
staticint MainMethod(object o);
}

All the plugins must implement this interface.

Linking to the plugin

Now it is necessary to explain how to use the plugin at runtime. The plugins are saved in the ‘\Plugins’ directory inside the startup path of the application. The code for the usage of plugins is very simple: (Please note the using clause:)

Using plugins

After invoking loadPlugins(), all the plugins can be used as follows:

myResult = plugins[myIndex].MainMethod(myParam);

Now, it is enough to smartly manage the myIndex value…

Improvements

This technique is very 'general purpose'. For your application you may define different interfaces to implement many useful functions. You can use a main interface that tells the plugin-user app which type of plugin to expect and invoke the correct methods. Another ‘support’ interface may expose the menu entries and toolbar buttons.

Conclusions

This article is an abbreviation (and a generalization) of a real project that is currently working. Once you know how to design the architecture, you can do your job without much problems, but it is not always very easy, particularly while developing certain types of plugin, where you have to modify the interfaces and update all the old plugins…

Comments and Discussions

Just wanted to let you know that it isn't possible to use a static method inside an interface.Not that it would be meaningfull anyway.You use an interface to define some same methods for different classes, so when you use an instance of them you can use the same method. But for static methods you use the class.

a plugin *cannot* crash but it raises an exception that can be catched inside the plugin or in the application. if not, the app will terminate.

to unload plugins, you can close the app. in the class System.Reflection.Assembly there is not a method to unload DLLs. usually you can invoke the Finalize() method on the assembly, for example asm.Finalize()

note that if you not unload the DLLs, a very few quantity of memory will be wasted...

Are you sure that calling the Finalize method on the Assembly object will actually unload the assembly and all its related types from memory? I am really not sure that this is the case. My experience tells me that if you want to unload plugins or dynamically loaded assemblies, then you have to load them into a different Application Domain, and then unload that specific appdomain.

maybe you're right. usually we can 'hope' Finalize do its work. in fact the MSDN library tells that Finalize is inherited from object without any specific modification. personally I haven't much experience with AppDomains, but it can be a valid solution. I only repeat that leaving some (not many...) DLLs in memory is not a big problem. think about Photoshop: it loads all the plugins at startup and it doesn't unload them until shutdown...

Assemblies cannot be unloaded separately and calling Finalize will not unload the assembly.

They are unloaded when the AppDomain they've been loaded into is unloaded. In the case of most .NET applications 1 Application equals 1 AppDomain, so any assemblies loaded at runtime are released when the application is terminated.

In order to be able to remove plugins at runtime you'll have to load them into a separate AppDomain (but then you'll have to marshal each call between the 2 AppDomains). I think I remember several other articles on plugins here that also deal with this topic.