C# DLL's plugin-architecture

Darren Young picture Darren Young · Jan 20, 2011 · Viewed 11.3k times · Source

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

gideon picture gideon · Jan 20, 2011

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