Click here to Skip to main content
Click here to Skip to main content

Plugin-Ready Application Development

By , 26 Jun 2005
 

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 {
   static int 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 System.Reflection;

private string pluginDir = Application.StartupPath + “\\Plugins”;

private IPlugin[] plugins;

private void loadPlugins() {

   string[] p = Directory.GetFiles(pluginDir);
   // Assuming there are no files different that plugins’ DLLs
   plugins = new IPlugin[p.Length];
    
   for(int i = 0; i < 0; i++) {
      Assembly asm = Assembly.LoadFrom(p[i]);
      // Must be a full-qualified name (MyNamespace.IPlugin)
      Type type = asm.GetType(“IPlugin”, true);
      plugins[i] = (IPlugin)Activator.CreateInstance(type);
   }
}

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…

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Dario Solera
Software Developer Aruba SpA
Italy Italy
Member
Software engineer at Aruba SpA (Italy), working on IaaS cloud computing. Cloud believer, (former) entrepreneur, F1 addict.
 
Follow me at dariosolera.it or on Twitter.

Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
GeneralUnLoad PlugInsmemberFredyAlfredo26 Jun '05 - 11:00 
How you Unload PlugIns in run-time ?
If a Plug-in crash, the main application crash too ?
GeneralRe: UnLoad PlugIns Pinmemberdarisole26 Jun '05 - 21:02 
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...
GeneralRe: UnLoad PlugIns PinmemberThomas Lykke Petersen26 Jun '05 - 21:09 
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.
 
Regards,
Thomas Lykke Petersen (MCP)
GeneralRe: UnLoad PlugIns Pinmemberdarisole26 Jun '05 - 21:16 
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...
GeneralRe: UnLoad PlugIns PinmemberThomas Lykke Petersen27 Jun '05 - 2:15 
I think you're right, it is not a problem to leave a few small plugins in memory for the entire lifetime of your application.
 
Regards,
Thomas Lykke Petersen (MCP)
GeneralRe: UnLoad PlugIns Pinmembermav.northwind26 Jun '05 - 23:15 
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.
 
Regards,
mav
GeneralRe: UnLoad PlugIns PinsussAnonymous18 Aug '05 - 4:06 
http://www.codeproject.com/csharp/DynamicPluginManager.asp?df=100&forumid=128153&exp=0&select=978766[^]

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Permalink | Advertise | Privacy | Mobile
Web04 | 2.6.130516.1 | Last Updated 26 Jun 2005
Article Copyright 2005 by Dario Solera
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid