Plugin architecture with GUI

Question

I'm developing an application that makes heavy use of plugins. The app is in C# and I'm thinking about building the configuration GUI in WPF. I got the plugin architecture down in terms of how to manage the actual plugins themselves. However, each plugin has its own configuration, and that's where I'm looking for help.

The plugin architecture is simple -- there's an interface that plugins implement and I just load all the plugins inside a directory. However, where do the plugins get their configuration from? I'd like to have some generic way of handling this, so that each plugin isn't responsible for reading its own configuration file. Also, I'd like the GUI to expand with each plugin -- that is, each plugin installed should add a tab to the GUI with the specific configuration options for that plugin. Then upon save, the configuration file(s) would be saved.

What's my best way of going about this?

Answer 1

i suggest taking a look at how the Castle Windsor DI/IoC framework handles the extra requirements you're after, and perhaps consider using it.

But in general, your plugins should support an interface, property or constructor by which you can inject a configuration object from a common source such as your app.config file.

Answer 2

Define an interface for configurable plugins:

public interface IConfigurable
{
  public void LoadConfig(string configFile);

  public void ShowConfig();

  // Form or whatever, allows you to integrate it into another control
  public Form GetConfigWindow();
}

The just invoke the IConfigurable interface for configurable plugins.

Answer 3

Take a look at Composite WPF. Using something like this should allow you to have each plug in define the tab(s). The shell application would then only be responsible for loading each module to that modules respective view.

• Samples using Composite WPF
• Walkthrough using WPF Composite
• MSDN Walk through using Prism

Answer 4

Mono.Addins is a very good library for implementing plugins of any kind (even ones which can update themselves from a website). MEF can also accomplish this, but it's a bit lower level. But MEF is going to be part of .NET 4.

Answer 5

Microsoft promote developers to use this approach - Composite Application Guidance for WPF and Silverlight

Answer 6

The way I did my implementation to handle exactly the same problem (since dll-files cannot read their config files) was that I defined two interfaces one for the plugin IPlugin and one for the host IHost. The plugin was created and initialized with a reference to the host (implementing the IHost interface).

interface IHost {
     string[] ReadConfiguration(string fileName);
}

interface IPlugin {
     void Initialize(IHost host);
}

class MyPlugin : IPlugin {
     public void Initialize(IHost host) {
         host.ReadConfiguration("myplygin.config");
     }
}

IHost can then supply any common functions that you need between all your plugins (as reading and writing configuration), and the plugins are also more aware of your host application, without being locked to a specific host application. You could for example write a Web Service application and one Forms application that uses the same plugin API.

Another way would be to initialize the plugin with the configuration information read by the host application, however, I had the need for the plugin to be able to read/write it's configuration, and perform other actions, on demand.