对于不需要的类型，是否可以避免 MEF 中的 TypeLoadException？

Question

我有一个项目，它使用具有以下结构的 MEF 加载实现：

   MyProject
       |
       | (Imports with MEF)
       |
MyImplementation
       |
       | (has reference to)
       |
 ThirdPartyLib
    /      \
   /        \ (has refs to)
  /          \
USB.dll      Bluetooth.dll

当我尝试在我的开发/测试机器 - Windows 11 上导入

MyImplementation

时，它工作正常。

但是，在用户的计算机（Windows 10，内部版本 1607）上，我遇到以下异常：

System.TypeLoadException：找不到 Windows 运行时类型“Windows.Devices.Bluetooth.GenericAttributeProfile.GattCharacteristicsResult”。

System.TypeLoadException：找不到 Windows 运行时类型“Windows.Devices.Bluetooth.GenericAttributeProfile.GattDescriptorsResult”。

System.TypeLoadException：找不到 Windows 运行时类型“Windows.Devices.Bluetooth.GenericAttributeProfile.GattDeviceServicesResult”。

对其中一种类型的快速查找显示它仅在 Win 10 Build 15063 中引入，这解释了 1607 上的异常 - 这很好，因为我实际上并不使用蓝牙功能（我假设这些

Bluetooth.dll

使用了 3 种类型。事实上，如果我使用一个直接引用

ThirdPartyLib

的示例应用程序。工作正常，没有任何异常。

我只能控制

MyProject

和

MyImplementation

的代码。有没有办法允许其中任何一个（最好在

MyImplementation

中）忽略特定的异常，以便 MEF 无论如何都可以组合这些部分？

（或者，如果可以包含另一个库来填补这些缺失类型的空白，我会很高兴 - 但不确定这是否可能）。

Answer 1

我通过删除

MyImplementation

到

ThirdPartyLib

的引用解决了这个问题，然后使用反射来解析我需要的类型、属性和方法。

    private object _tpClass;
    private Type _tpType;
    private Assembly _tpAssembly;

    public MyImplementation() 
    {
        _tpAssembly = Assembly.LoadFrom(Path.Combine(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), @"ApiLib", @"ThirdPartyAssembly.dll"));
        _tpType = _wbpAssembly.GetType(@"ThirdPartyAssembly.ThirdPartyAssembly");
        _tpClass = Activator.CreateInstance(_tpType, "myparam");
    }

    public string GetSomeInfo() 
    {
        var method = _tpType.GetMethod("Get3partyResult");
        var result = method.Invoke(_tpClass, null);

        return result.GetType().GetProperty(@"TheData").GetValue(result);
    }

等等。

感觉有点像 hack，代码有点混乱（而且可能效率低下），但对于组成各个部分的 MEF 来说，就缺少依赖项而言，这是一种“眼不见心不烦”的情况。 请注意，我必须将 ThirdPartyLib 及其关联的 dll 放在子目录中 - 即与

MyImplementation

和正在组成的其他实现不在同一目录中，否则我会得到与上面相同的异常。

顺便说一句 - ChatGPT 建议处理

AssemblyResolve

事件并仅返回 null。这对我不起作用 - 它确实因缺少依赖项而被解雇，但我仍然遇到异常。