【问题标题】:Meeting assembly dependencies in a MEF environment在 MEF 环境中满足程序集依赖项
【发布时间】:2012-01-06 05:18:53
【问题描述】:

我有一个应用程序,我在其中使用 MEF 来动态加载扩展程序集。一个组件是域层,第二个是视图。域程序集加载并按预期工作。伪结构如下所示:

  • 解决方案
    • 域项目
    • 查看项目

我遇到的问题是视图程序集包含 1..N 个用户控件,它们是第一个程序集中域对象的可视代理。这对视图组件施加了约束,因为它依赖于域层组件。例如从上面看,View Project 程序集依赖于 Domain Project 程序集。我怀疑将可视化代理从视图项目移到域项目中可以解决问题,但是,它会违背关注点分离。

在视图程序集上调用 Assembly.LoadFile() 方法时,我收到典型的 FileNotFoundException。我相信这是因为首先加载的域层程序集位于应用程序运行的根目录之外,因此不在探测路径内。在这个过程中我希望的是,因为核心程序集已经被加载,所以视图程序集对它的依赖将会得到满足。不幸的是,情况并非如此。

AppDomainSetup.PrivateBinPath 不适合我。这将限制扩展开发人员将其安装在已安装应用程序的文件结构中,这将导致污染,这不是我们需要或不希望的。我知道这项任务在已安装的应用程序根目录下有一个 Extensions 目录会简单得多。

我想做的是能够加载程序集并让其他已加载并添加到 AggregateCatalog 的程序集满足它们的依赖关系。

有没有人有任何想法、建议或建议可以帮助我实现目标?

【问题讨论】:

  • 你在哪里以及为什么在视图程序集中调用Assembly.LoadFile()
  • 当我构建一个特定于机器的扩展时,每个程序集文件引用都被添加到一个 AssemblyCatalog 中,而后者又被添加到一个 AggregateCatalog 中。在使用相关实例时,我正在加载视图程序集以满足视觉代理依赖性。

标签: .net dependencies mef assembly.load probe


【解决方案1】:

好的,我的解决方案是不使用module initialization through assembly injection。虽然非常巧妙,但在从 C# 加载程序集时,似乎根本没有为框架 4 调用它。它可能在其他情况下工作。

我的解决方案是回归基础并依赖当前 AppDomain 的 AssemblyResolve 事件。首先,在构建我的扩展的 ComposablePartCatalog 时,我将扩展路径存储在一个集合中。当程序集加载失败时,AssemblyResolve 事件会触发,我会遍历我的扩展路径集合以查找扩展的依赖关系。

这非常符合我将已安装的应用程序与任何已安装的扩展分开的目标。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2020-09-11
    • 2019-09-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-11-23
    • 1970-01-01
    • 2016-07-27
    相关资源
    最近更新 更多