IsAssignableFrom()应返回true时返回false

当包含当前程序集引用的类型IPlugin的程序集与包含您正在迭代的类型的程序集引用的程序集之间不匹配时,通常会发生这种情况。

我建议您打印:

typeof (IPlugin).Module.FullyQualifiedName

和

foreach (var type in t.GetInterfaces ()) 
{    
    Console.WriteLine (type.Module.FullyQualifiedName)
}

查看不匹配的位置。

当接口在一个单独的程序集中定义为实现类型时,我也遇到了同样的问题。 如上所述,迭代并从根文件夹加载程序集(其中包含带有类的dll和带有接口的dll)会导致类型不匹配。

LoadFrom() 到 LoadFile() 这个 LoadFrom 该方法有一些缺点,这是其中之一:

克服此问题的另一种方法是将所有具有实现接口的类型的DLL放在单独的文件夹中,而不是复制引用的程序集( CopyLocal = False )所以 Assembly.LoadFrom 将不会加载内存中包含接口的dll。

IsAssignableFrom 方法我同意,结果是用错了。

试着做一点实验 在你的代码中,看看它是否有效。例如:

替换:

if (typeof(IPlugin).IsAssignableFrom(t))

if (t.IsAssignableFrom(typeof(IPlugin)))

有时,动态程序集引用另一个程序集时会出现问题。

如果.NET不知道如何初始化类型,也可以实现程序集解析器。

        AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler([Resolve Function]);

如果您使用的是.net core,并且遵循 this link 然后请确保您记得将其添加到您的插件项目中

<ItemGroup>
    <ProjectReference Include="..\PluginBase\PluginBase.csproj">
        <Private>false</Private>
        <ExcludeAssets>runtime</ExcludeAssets>
    </ProjectReference>
</ItemGroup>

如链接中所述。如果没有,则会出现上述错误。 This also helped me

我在Java中工作,它有相同的API方法,我只是无法在阅读代码时思考它(出于某种原因);因此,在你的例子中,我总是以相反的方式阅读它,因为“t可分配给IPlugin”。因此,如果C#has如Jonathon所建议的那样是“is”,我会一直使用它-在Java中反映时,“instanceof”不适用于类对象,只适用于对象的实例。

当应用于测试继承或检测接口实现时,Type.IsAssignableFrom方法的名称模糊且容易混淆。以下用于这些目的的包装将更有意义:

    public static bool CanBeTreatedAsType(this Type CurrentType, Type TypeToCompareWith)
    {
        // Always return false if either Type is null
        if (CurrentType == null || TypeToCompareWith == null)
            return false;

        // Return the result of the assignability test
        return TypeToCompareWith.IsAssignableFrom(CurrentType);
    }

    bool CanBeTreatedAs = typeof(SimpleChildClass).CanBeTreatedAsType(typeof(SimpleClass));
    CanBeTreatedAs = typeof(SimpleClass).CanBeTreatedAsType(typeof(IDisposable));

此方法代替“is”关键字的优点是,它可以在运行时用于测试未知的任意类型,而“is”关键字(和泛型类型参数)需要特定类型的编译时知识。