views:

409

answers:

2

We implement a plugin framework for our application and load plugin assemblies using Assembly.Loadfrom. We then use GetTypes() and further examine the types with each plugin file for supported Interfaces.

A path for the plugins is provided by the user and we cycle through each of the files in the folder to see if it (the plugin) supports our plugin interface. If it does, we create an instance, if not we move onto the next file.

We build two versions of software from the one code base (appA_1 and appA_2).

Loading the plugins works well when the plugins are loaded by the application that was built at the same time as the plugin file. However if we build appA_2 and point to the plugin folder of appA_1, we get an exception when GetTypes() is called.

A basic version of our code is;

var pluginAssembly = Assembly.LoadFrom(FileName);    
foreach (var pluginType in pluginAssembly.GetTypes())
{

We get a "ReflectionTypeLoadException" exception.

This is concerning because we want our application to be able to load the types of any plugin, built by anyone. Is there something we are missing?

EDIT: After iterating through the LoaderExceptions we have discovered that there is a single file libPublic.dll that generates a System.IO.FileNotFoundException exception. The strange thing is that this file resides in the application directory and the plugin is referenced to the project file.

EDIT 2: In the exception log we find the following "Comparing the assembly name resulted in the mismatch: Revision Number"

+1  A: 

A few things:

  • Make sure you don't have duplicate assemblies in the plugin directory (i.e. assemblies that you're already loading in your main app from your app directory.) Otherwise, when you load your plugin, it may load an additional copy of the same assembly. This can lead to fun exceptions like Object (of type 'MyObject') is not of type 'MyObject'.

  • If you're getting the exception when instantiating a type, you may need to handle AppDomain.AssemblyResolve:

    private void App_Startup(object sender, StartupEventArgs e)
    {
        //Since we'll be dynamically loading assemblies at runtime, we need to add an appropriate resolution path
        //Otherwise weird things like failing to instantiate TypeConverters will happen
        AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;
    }
    
    
    private Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
    {
        var domain = (AppDomain) sender;
    
    
    
    foreach (var assembly in domain.GetAssemblies())
    {
        if (assembly.FullName == args.Name)
            return assembly;
    }
    
    
    return null;
    
    }

I realize it's a bit strange to have to tell the CLR that, in order to resolve an assembly, find the assembly with the name we're using to resolve, but I've seen odd things happen without it. For example, I could instantiate types from a plugin assembly, but if I tried to use TypeDescriptor.GetConverter, it wouldn't find the TypeConverter for the class, even though it could see the Converter attribute on the class.


Looking at your edits, this is probably not what's causing your current exception, though you may run into these issues later as you work with your plugins.

Dan Bryant
A: 

Check out Suzanne Cook's blog post about load contexts (too lazy to find the link again).

erikkallen