C# DLL's plugin-architecture

Question

I have a program that i developed to use a basic plugin architecture. Effectively, when the program loads it uses reflection to search the directory for dll's that fit a certain interface and then loads them. It now appears that the current list of plugins is all that will be used.

Therefore, is my current practise of check the dll files still the best practise, or are there better ways to load each dll?

Thanks.

Answer 1

From your question it looks like you've built (or are trying to build) your own kind of plugin architecture. Its not such a good idea since .NET already has what you're looking for.

.NET comes with 2 ways to allow plugins.

1. System.Addin
2. MEF - Managed Extensibility Framework

(1) System.Addin - I've barely heard/read much about it. But you can take a look at a few articles here:
System.Addin article from MSDN magazine <- Note the Year 2007
System.Addin tools and examples at Codeplex

(2) Now, MEF, MEF is just awesome! Its a great and easy way to introduce a plugin architecture into your system. MEF is also a part of Silverlight and Visual Studio 2010 uses it. I can see you want to load dlls with plugins dynamically, with MEF you can design your app in such a way the classes you package with your software can be in your own assembly (.exe) and then you can use MEF to dynamically look for dlls in the future that will have classes that you need. The whole procedure itself is very simple in MEF.

Mike Taulty has a brilliant video series on MEF

MEF Article at Codeproject - Part 1 MEF Article at Codeproject - Part 2

MEF is Open Source on Codeplex

I personally think you should go with MEF, its new, easy and even visual studio uses it, even so you can take a look at:
Choosing between MEF and MAF (System.AddIn)

Do check out other top voted questions on the mef tag at SO

Answer 2

You can use the FileSystemWatcher class to monitor a directory for changes.

publicvoid CreateWatcher()
{
//Create a new FileSystemWatcher.
FileSystemWatcher watcher = newFileSystemWatcher();

//Set the filter to only catch DLL files.
watcher.Filter = "*.dll";

//Subscribe to the Created event.
watcher.Created += new
FileSystemEventHandler(watcher_FileCreated);

//Set the path to C:\Temp\
watcher.Path = @"C:\Temp\";

//Enable the FileSystemWatcher events.
watcher.EnableRaisingEvents = true;
}

Then it becomes a plug and play affair :)

Answer 3

refer to MEF It's a very powerful architectural solution for creating Plugin designs.

Answer 4

This is good. Alternatively, you can define which assemblies to be loaded in the config file also, if you feel that having numerous DLLs in the said folder might affect your application and there might be some security issue as anybody might push a DLL into that folder.

Answer 5

• Since plugin mean: "you donot know the dll to load in advance" there is no way to early bind ths "unknown-dll" you have to load and search for interface implementation and use a kind of late binding.
• "Searching the dll" instead of "editing a configfile" is very userfriendly. in most cases searching dll is not a performance issue since its done only once at program start.

I think your design is ok.

Answer 6

For your scenario I recommend using MEF and its DirectoryCatalog to load plugins from a particular folder. If you additionally configure the file system watcher and refresh DirectoryCatalog on folder change, thanks to recomposition feature of MEF, you will be able to pull new plugins in runtime! BTW, you can see a nice recomposition sample I did for one of my MEF talks.