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"
Thanks to this post I could solve the
ReflectionTypeLoadException
that I was getting in aUITypeEditor
. It's a designer assembly (a winforms smart-tag used at design-time) of a custom class library, that scan for some types.You are getting an assembly version mismatch. Since your plugins refer to this
libPublic.dll
, you must version it carefully and in particular not bump its revision/build/etc. numbers at every compile.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:
If you're getting the exception when instantiating a type, you may need to handle
AppDomain.AssemblyResolve
: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 theTypeConverter
for the class, even though it could see theConverter
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.