Oct 20 2009
.NET Plugin DLL Hell (aka assembly binding nightmares)
I’ve worked on a few .NET WinForms applications that utilized a “plugin” model. You’ve probably seen similar apps out there, where a main application searches a directory for DLLs, and then tries to load them into the AppDomain, using some code like below:
Assembly plugin = System.Reflection.Assembly.LoadFrom(pluginFileName);
object pluginClass = Activator.CreateInstance(plugin.GetType("Plugin.PluginClass"));
This kind of architecture is pretty standard, and is one of the few ways to accomplish this plugin model in .NET (other than some cutting-edge things like MEF). It works for the most part, but has some obvious limitations, such as:
- Once a DLL is loaded in this manner, it cannot be unloaded from memory (unless you mess around with AppDomains for each plugin)
- If your plugins want to talk to one another, they pretty much have to go through a lot of plumbing code in the main app
Where it really starts to have problems is when your plugin DLL needs to reference other DLLs used by the main application, or other plugin DLLs, and you find yourself in .NET Plugin DLL Hell.
Here is the crux of the problem:
When you add a reference to a DLL via Visual Studio, the framework will always try to load an exact matching version of that assembly, and will fail if it can’t find it. So, good luck if that DLL you depend on ever gets upgraded to a new version.
You can usually control this with a standalone application, because when you upgrade the app, you upgrade all the dependencies at the same time. In a plugin model, you can’t control when other dependencies are upgraded, and so your plugin will simply fail to load when this happens.
There is no way in the .NET framework to tell it to use a particular version of a DLL or any newer version it finds.
Here’s a scenario to demonstrate this:
- You have a WinForms application, that loads plugin DLLs when the app starts.
- The main application uses a third-party control library.
- You write a plugin that also needs the controls, so you add a reference to the version that the main app uses.
- At some point, someone working on the main app upgrades it to use a newer controls DLL, recompiles the app, and distributes it along with the newer controls DLL.
- Since no work was actually done on your plugin, no one has recompiled it against the newer controls DLL.
- When the upgraded application starts and loads your plugin, your plugin goes BOOM!
Another scenario:
- Your plugin references another plugin
- The other plugin gets upgraded without your plugin getting recompiled
- Your plugin now goes BOOM!
When I say “BOOM!”, I mean you’ll probably see something like this from the Fusion log:
"System.IO.FileNotFoundException: Could not load file or assembly ‘YourDependentAssemblyNameHere’ or one of its dependencies. The system cannot find the file specified.”
I am having a similar problem with my Windows LiveWriter plugin, xPollinate. Every time Microsoft releases a new version of LiveWriter, all of its DLLs that I reference have new version numbers, and so my plugin will fail to load unless I recompile my plugin against the latest versions of the DLLs.
Well, so what are our options to deal with this?
- You can simply not add any references in your plugin project via Visual Studio, and just use reflection for everything (yuck). This is probably a little easier now with the dynamic keyword in C#, but not much.
- You can try to get the main application to put in assembly binding redirects in its config file for any common DLLs that might be referenced by plugins.
That’s all I can see at this point. Here’s to hoping a future version of the framework will make this easier for us.
Toth on Twitter