问题标签 [maf]

在 .NET 插件框架中，我可以在主机端获取 AddIn dll 位置吗？

AddInToken 包含具有 dll 位置的 _addin 字段，但我无法获取它，因为它是私有的。

我是插件框架的新手。现在我正在尝试创建返回 UserControl 的 WPF 插件（根据https://msdn.microsoft.com/en-us/library/bb909849(v=vs.110).aspx）。

问题是当我尝试从插件获取用户控制时，抛出异常：

1. 第一个例外是“找不到名为 '' 的资源。资源名称区分大小写。”。所有资源都存储在单独的库中，当我对 MEF 执行相同操作时（在 MAF 之前），它运行良好

2. 好的，我已经从我的 UserControl 中删除了所有 StaticResources，然后我得到了另一个异常：“{”无法加载文件或程序集 'Infralution.Localization.Wpf，PublicKeyToken=547ccae517a004b5' 或其依赖项之一。“}”。该库用于本地化。

注意：所有需要的库都与插件位于同一文件夹中

是否未加载插件引用的库？或者我哪里弄错了？

我正在开发需要支持插件不同程度隔离的系统。我选择了 MAF，因为它符合我的需求，支持开箱即用的单独进程隔离和 AppDomain 隔离。

下面的示例使用了单独的进程隔离：

但是，我在使 MAF 与主机和插件之间共享的库一起工作时遇到了问题。假设，我有项目（带有输出目录）：

和参考资料

这给了我一个干净的构建，每个管道目录中都有单个 dll，一切正常，管道已构建，有效且工作。

直到我添加有问题的：

这引入了一个问题，因为 My.PlugIn.AddIn 项目不能包含在管道中，因为：

1. 加载 My.PlugIn.AddIn 时出现问题 - 无法找到依赖项 My.AddIn.Shared（如果 AddInViews 包含带有插件库的单个 dll）
2. 无法将透明代理转换为我的 IContract 类型 - （当 colyLocal=true 并且 AddInViews 包含超过 1 个 dll 时）

此外，值得一提的是 My.PlugIn.AddIn 中只有单个类用 AddInBaseAttribute 修饰，共享程序集没有单个类。

因此，在这两种情况下都无法加载插件。我想通过我的自定义事件处理程序来解决问题

在调用 AddInStore.Rebuild 之前，但这只会影响我的主机应用程序正在运行的域，并且不会影响由 System.AddIn.Hosting.AddInStore 在内部创建的域“加载项模型发现工作者 AD”

由于此类是静态的，因此无法覆盖域的创建。此外，它不提供任何允许我访问内部域解决错误的事件。有什么方法可以注入我的自定义程序集解析规则或强制内部 appDomain 从我的主程序继承解析事件？

我有一个独立的 WPF 加载项。插件获取对公开事件的类型的引用。由于插件被隔离在特定的应用程序域中，主机对插件的 DLL 或存储在那里的类型一无所知。

合同：

handler 是一种暴露事件的类型，并且从 MarshalByRef 派生，以便将代理传递给插件：

在插件中，我们执行以下操作：

然而，这失败了，因为它尝试（以某种方式）将插件的引用传递给主机应用程序，并且由于对于主机，插件的 dll 是未知的，它无法加载类型并引发异常。我怎样才能仍然保持隔离，并能够执行上述操作？

我的应用程序存在权限问题：

我有一个在完全受信任的应用程序域中运行的主机应用程序。此主机通过 MAF 框架加载一个插件，并在另一个只有 Internet 访问权限的应用程序域中激活此插件。

Host 在主 App-Domain 中创建一个 Helper-Object，并通过 MAF-Pipeline 将其引用传递给 Add-In（使用 HostView 和 Add-In View Adapters）。加载项然后调用此 Helper-Object 上的方法，该方法应从文件系统加载文本文件。执行此操作时，我收到一个 SecurityException：

我已经调试了一下代码，发现在 Class FileStream.cs 中有如下检查：

Demand-Method 在 CodeAccessPermissions.cs 中实现，如果所有元素都有执行此方法的权限，它似乎会检查完整的调用堆栈：

当我直接从 Main 方法中对 Helper 类执行此方法时，一切正常。

当我将加载项的权限设置为 FullTrust 时，它也可以正常工作。

我还检查了 AppDomain 和 AppDomain.CurrentDomain.IsFullyTrusted 属性，这在所有情况下都是正确的。

所以似乎是AddIn在Call-Stack中的问题，这导致了Permission Problem。

我还尝试在新线程中执行此操作，以使调用堆栈中不再有 AddIn，但这没有任何效果。

这个问题对我来说非常重要，因为我不想授予插件完全权限，而是让插件在主机上执行方法。

有谁知道这个问题的解决方案？

在 System.AddIn（又名 MAF）管道适配器中，需要手动将值从一种 DTO 类型复制到另一种 - 从 HostView 类型到 Pipeline Contract 类型以及从 Pipeline Contract 类型到 AddIn 视图类型（然后再返回）。这似乎是使用自动映射器的理想情况。

但是，我不确定在 HostView 和 AddInView 适配器中使用和打包 3rd 方程序集的正确方法，尤其是当 AddIn 激活在单独的 AppDomain 中时。

我尝试了以下方法：

• 将 automapper 的 nuget 引用添加到 AddIn 适配器项目并在其中创建映射配置文件。（我对初始化配置文件的适配器使用了静态 ctor，因为 MAF 负责实例化适配器。）

• 与直觉相反，为了让管道定位并激活适配器支持的插件，我必须确保 automapper DLL 位于我主机的 bin 目录中- 在实际适配器 DLL 旁边的“AddInAdapters”文件夹中拥有 automapper DLL没有效果。

通过这种安排，我能够在我的开发盒上找到并激活插件（win 7）。但是完全相同的二进制文件在 Server2008R2 上不起作用。（我知道，我知道：我无法控制开发或服务器操作系统的选择）

我们正在使用（和目标）.Net 4.5.1 - 是的，它在桌面和服务器上。我们正在使用 automapper 2.2.1 - 不，它不在我的开发箱的 GAC 中

适配器使用的第 3 方程序集应位于何处（插件端和主机端）。尤其是在考虑 AppDomain 隔离时

为什么上述安排适用于 Windows 7，而不适用于 2008R2？

我正在使用 MAF 为用户/客户提供增强我们软件的可能性。加载项将以有限的权限运行，并且对于我们以及客户来说可能是不受信任的代码，以防他们从第 3 方开发人员那里购买了加载项。

在我们的例子中，Host 和 Host-Side Adapter 在主 AppDomain 中以完全权限运行，而 Add-In 和 Add-In Side Adapter 在几乎没有权限的情况下运行。

当我通过 AddInStore.FindAddIns 获得插件令牌时，我只能验证插件程序集本身是否来自应有的供应商。如果攻击者交换插件程序集，那么我们会发现它并且不会激活该程序集。但无论如何，由于几乎没有权限运行，攻击者无法真正损害应用程序和环境（主机、内部网等）。

但也有可能的是，攻击者替换了主机端适配器组件。攻击者只需在正确的文件夹中放置一个新程序集。由于它以完全权限运行，因此攻击者代码可能真的会损害应用程序和环境。由于攻击者在主机和加载项之间（或多或少是中间人），它也可以更改两者之间交换的数据。

当我调试我的代码并在调试器中检查加载项令牌时，我可以看到不同程序集的所有路径，加载项存储用于构建管道：

不幸的是，关于所采取的组件的重要信息是私人的，我无法访问它们。

是否有解决方法来访问此信息？

我有一个 wpf 应用程序，它托管一组控件，这些控件通过 FrameworkElementAdapter 由另一个进程支持。出于某种原因，这些控件存在非远程控件似乎没有表现出的裁剪/Z 顺序问题。

上图中的 gridview 是这些托管控件之一，并且不正确地与右侧的面板重叠，而托管它的 contentcontrol 则按预期运行。我已经明确设置ClipToBounds = true了gridview。

我的问题是：有没有办法让我的控件正确剪辑并遵守 z 顺序，或者 FrameworkElementAdapter 是否通过例如将它们渲染到装饰层或其他东西来使这成为不可能？

xml:

C＃：

有趣的附注：如果我使用 Snoop 检查我的应用程序，当您将鼠标悬停在可视树图的某些部分上时，在预览 Snoop 显示中，远程控件根本不会出现，并且它们各自的主机内容控件显示为空，但大小合适

我正在使用 MAF (System.AddIn) 将插件加载到进程之外。我发现每当 Visual Studio 位于进程树中的任何位置时，插件都需要 2.5 秒以上才能激活。然而，当 Visual Studio 不在进程树中时，它只需要大约 250-300 毫秒。

我用来测试的代码是：

此延迟发生在调试或发布时，但仅当执行该激活的进程由 Visual Studio 启动时。我是否附加调试器似乎并不重要。如果我将可执行文件设置为 Visual Studio 中的工具并以这种方式启动它，就会发生这种情况。

如果我在 Visual Studio 之外运行完全相同的可执行文件，那么我会看到改进的启动时间。

这就是为什么我似乎认为只有当 Visual Studio 位于进程树中时才会出现问题。

我已经尝试过使用不同的 MAF 管道和接口并看到类似的结果。

有谁知道什么会导致 Visual Studio 启动该过程导致性能出现如此大的差异？

我正在构建一个 MAF 管道，加载项也可以使用它来回调主机系统以使用来自主机的某些服务。这些方法可能会引发应由加载项处理的异常。处理这种情况不仅意味着要抓住它们，而且还要分析它们。

与往常一样，有两个选项可以让对象跨越 appdomain 边界：通过序列化它们或通过扩展MarshalbyRefObject.

实际上我对这两种选择都有问题：

当我使用序列化时，我的加载项需要知道异常的确切类型，否则它无法反序列化异常。这意味着我不能在抽象层上工作。Exception 类本身被标记为可序列化，因此所有子类也需要标记为可序列化才能正常工作。对我来说，这不是一个真正的解决方案，因为我无法隔离主机和加载项之间的类型（因为我无法处理抽象）

使用 MarshalbyRefObject 的效果不如所有 Exception 都需要扩展“Exception”，因此不能扩展 MarshalbyRefObject。

有没有可以解决这个问题的标准模式？