MEF: “Unable to load one or more of the requested types. Retrieve the LoaderExceptions for more information”

exceptionloadermefplugins

Scenario: I am using Managed Extensibility Framework to load plugins (exports) at runtime based on an interface contract defined in a separate dll. In my Visual Studio solution, I have 3 different projects: The host application, a class library (defining the interface – "IPlugin") and another class library implementing the interface (the export – "MyPlugin.dll").

The host looks for exports in its own root directory, so during testing, I build the whole solution and copy Plugin.dll from the Plugin class library bin/release folder to the host's debug directory so that the host's DirectoryCatalog will find it and be able to add it to the CompositionContainer. Plugin.dll is not automatically copied after each rebuild, so I do that manually each time I've made changes to the contract/implementation.

However, a couple of times I've run the host application without having copied (an updated) Plugin.dll first, and it has thrown an exception during composition:

Unable to load one or more of the requested types. Retrieve the LoaderExceptions for more information

This is of course due to the fact that the Plugin.dll it's trying to import from implements a different version of IPlugin, where the property/method signatures don't match. Although it's easy to avoid this in a controlled and monitored environment, by simply avoiding (duh) obsolete IPlugin implementations in the plugin folder, I cannot rely on such assumptions in the production environment, where legacy plugins could be encountered.

The problem is that this exception effectively botches the whole Compose action and no exports are imported. I would have preferred that the mismatching IPlugin implementations are simply ignored, so that other exports in the catalog(s), implementing the correct version of IPlugin, are still imported.

Is there a way to accomplish this? I'm thinking either of several potential options:

There is a flag to set on the CompositionContainer ("ignore failing imports") prior to or when calling Compose
There is a similar flag to specify on the <ImportMany()> attribute
There is a way to "hook" on to the iteration process underlying Compose(), and be able to deal with each (failed) import individually
Using strong name signing to somehow only look for imports implementing the current version of IPlugin

Ideas?

Best Answer

I have also run into a similar problem.

If you are sure that you want to ignore such "bad" assemblies, then the solution is to call AssemblyCatalog.Parts.ToArray() right after creating each assembly catalog. This will trigger the ReflectionTypeLoadException which you mention. You then have a chance to catch the exception and ignore the bad assembly.

When you have created AssemblyCatalog objects for all the "good" assemblies, you can aggregate them in an AggregateCatalog and pass that to the CompositionContainer constructor.

Related Solutions

C# – MEF – Do I need to implement IPartImportsSatisfiedNotification

I'm not sure about using MEF to manage the runtime flow of a program like this. MEF is a great choice for locating and loading plugins, but it is designed for very loosely-coupled systems, so you may not have the level of control you need.

For example, though the dependency resolution process will provide tasks with their dependencies, there's no opportunity to inspect what the dependency structure is.

Things may be tricky when, for instance, you want to guarantee that a task executes only once, or when you want to substitute one task with another.

My recommendation is that you use MEF to find the plug-ins, but develop a rich object model independent of MEF for executing them.

E.g.:

[Export(typeof(IPlugin)), ExportMetadata("Name", "ConfigureX")]
public class ConfigureXPlugin : IPlugin { ...

Then use MEF to find all the available plugins:

public class BuildRunner {
  [ImportMany]
  Lazy<IPlugin, IPluginMetadata> plugins[];

  void RunBuild(...) {
    // Figure out which tasks should execute, in which order, and call each of them

Hope this helps. If you're still having trouble, posting some more information about your problem would help.

Nick

C# – MVC4 MEF-based dynamically loaded plugins

I'm currently working on the same issue. I've found this solution:

Blog post: http://blog.longle.net/2012/03/29/building-a-composite-mvc3-application-with-pluggable-areas/
Source code: https://bitbucket.org/darincreason/mvcapplication8.web

Basically it loads assemblies from specified location and with some name pattern on web application startup:

AssemblyInfo.cs:

[assembly: PreApplicationStartMethod(
  typeof(PluginAreaBootstrapper), &quot;Init&quot;)]

PluginAreaBootstrapper.cs:

public class PluginAreaBootstrapper
{
    public static readonly List<Assembly> PluginAssemblies = new List<Assembly>();

    public static List<string> PluginNames()
    {
        return PluginAssemblies.Select(
            pluginAssembly => pluginAssembly.GetName().Name)
            .ToList();
    }

    public static void Init()
    {
        var fullPluginPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Areas");

        foreach (var file in Directory.EnumerateFiles(fullPluginPath, "*Plugin*.dll", SearchOption.AllDirectories))
            PluginAssemblies.Add(Assembly.LoadFile(file));

        PluginAssemblies.ForEach(BuildManager.AddReferencedAssembly);

        // Add assembly handler for strongly-typed view models
        AppDomain.CurrentDomain.AssemblyResolve += AssemblyResolve;
    }

    private static Assembly AssemblyResolve(object sender, ResolveEventArgs resolveArgs)
    {
        var currentAssemblies = AppDomain.CurrentDomain.GetAssemblies();
        // Check we don't already have the assembly loaded
        foreach (var assembly in currentAssemblies)
        {
            if (assembly.FullName == resolveArgs.Name || assembly.GetName().Name == resolveArgs.Name)
            {
                return assembly;
            }
        }

        return null;
    }
}

But I believe you can create some directory observer which can dynamically load assemblies, so you don't even need to restart your web application.

In my opinion it meets your 1, 2 and 4 needs. It's very simple, doesn't require any frameworks, has minimal configuration, allows dynamic loading of the plugins and works with MVC 4.

This solution plugs assemblies into Area directory, but I believe you can quite easily tune it to play as you like using routing.

Best Answer

Related Solutions

C# – MEF – Do I need to implement IPartImportsSatisfiedNotification

C# – MVC4 MEF-based dynamically loaded plugins

Related Topic