Assembly.GetTypes()-ReflectionTypeLoadException [英] Assembly.GetTypes() - ReflectionTypeLoadException
问题描述
我们为应用程序实现了一个插件框架，并使用Assembly.Loadfrom加载插件程序集.然后，我们使用GetTypes()并在每个插件文件中进一步检查类型，以了解受支持的接口.
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.
我们从一个代码库(appA_1和appA_2)构建了两个版本的软件.
We build two versions of software from the one code base (appA_1 and appA_2).
当插件是由与插件文件同时构建的应用程序加载时，加载插件的效果很好.但是，如果我们构建appA_2并指向appA_1的插件文件夹，则在调用GetTypes()时会出现异常.
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.
我们代码的基本版本是
var pluginAssembly = Assembly.LoadFrom(FileName);
foreach (var pluginType in pluginAssembly.GetTypes())
{
我们收到"ReflectionTypeLoadException"异常.
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?
在遍历LoaderExceptions之后，我们发现只有一个文件libPublic.dll生成System.IO.FileNotFoundException异常.奇怪的是，该文件位于应用程序目录中，并且插件引用了项目文件.
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"
推荐答案
几件事:
-
确保插件目录中没有重复的程序集(即，您已经从应用程序目录中的主应用程序中已加载的程序集.)否则，当您加载插件时，它可能会加载同一程序集的其他副本.这可能会导致有趣的异常，例如:
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:
"MyObject"类型的对象不是"MyObject"类型.
Object (of type 'MyObject') is not of type 'MyObject'.
如果实例化类型时遇到异常，则可能需要处理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;
}
我知道必须告诉CLR，为了解析程序集，找到具有我们用来解析的名称的程序集，这有点奇怪，但是我看到没有它会发生奇怪的事情.例如，我可以从插件程序集中实例化类型，但是如果我尝试使用TypeDescriptor.GetConverter，即使它可以在类中看到Converter属性，也找不到该类的TypeConverter.
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.
这篇关于Assembly.GetTypes()-ReflectionTypeLoadException的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
