插件应用程序域解决方法 [英] Plugin AppDomains Workaround

查看:280
本文介绍了插件应用程序域解决方法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当与插件装配在自己的子目录处理,有众所周知的问题是,这些组件加载失败,一旦他们试图从它们的子目录加载各自的依赖关系。一个解决办法是加载插件的应用程序域其中有他们的 PrivateBinPath 在初始化时的 AppDomainSetup 对象设置。然而,这将导致有关编组/交叉AppDomain的通信的其它的困难,特别是如果插件都应该提供一些图形用户界面。

When dealing with plugin assemblies in their own subdirectories, there is the well-known problem that these assemblies fail to load once they try to load their respective dependencies from their subdirectories. A solution is to load the plugins in AppDomains which had their PrivateBinPath set in their AppDomainSetup object upon initialization. However, this causes other difficulties concerning marshalling/cross-AppDomain communication, in particular if the plugins are supposed to provide some GUI.

在安全性方面有较低的优先级(非关键实用的应用程序,一旦造成故障的插件崩溃,没有严重的问题),我有以下想法:在应用程序启动时,所有的插件目录应搜索,和一个新的AppDomain应当设立在其bin路径的目录。然后,整个应用程序和其GUI在于新的AppDomain运行,以及所有的插件。

When security aspects have a lower priority (non-critical utility application, no severe problems upon crashes caused by faulty plugins), I've had the following idea: Upon application start-up, all plugin directories should be searched for, and a new AppDomain should be created that has those directories in its bin path. Then, the whole application and its GUI run in that new AppDomain, along with all plugins.

在给定的情况下,有什么理由来避免这种解决办法?还是有可能的任何原因,该解决方案甚至不是可行?

Under the given circumstances, are there any reasons to avoid that solution? Or are there maybe any reasons why that solution isn't even feasible?

推荐答案

考虑考虑你所描述的情况,我不知道你的建议的第二个域相关的任何问题。不过,您也可以调查处理的初始域的组件加载失败的可能性,通过该加载项搜索自己的子目录,并从那里通过的 Assembly.LoadFrom

Taking in consideration your described scenario I don't know of any issue associated with your proposal for a second domain. However, you may also investigate the possibility of handling the assembly loading failures on the initial domain by searching yourself through the addins sub-directories and loading the assembly from there using Assembly.LoadFrom.

一种可能的设置此实施例,其中 FindAssemblyByName 将必须执行通过所有可能的位置,以搜寻:

Example of a possible setup for this, where the FindAssemblyByName would have to be implemented to search through all the possible locations:

static void Main(string[] args)
{
    AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;

    // ...
}

static Assembly CurrentDomain_AssemblyResolve(
    object sender, 
    ResolveEventArgs e)
{
    var assemblyName = new AssemblyName(e.Name);

    string assemblyFilePath = FindAssemblyByName(assemblyName);

    if (string.IsNullOrEmpty(assemblyFilePath))
        return null;

    return Assembly.LoadFrom(assemblyFilePath);
}

这篇关于插件应用程序域解决方法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆