Пользовательские AppDomain и PrivateBinPath

Я использую C# 4.0 и консольное приложение только для тестирования, следующий код выдает исключение.

AppDomainSetup appSetup = new AppDomainSetup()
{
    ApplicationName = "PluginsDomain",
    ApplicationBase = AppDomain.CurrentDomain.BaseDirectory,
    PrivateBinPath = @"Plugins",
    ConfigurationFile = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile
};

AppDomain appDomain = AppDomain.CreateDomain("PluginsDomain", null, appSetup);

AssemblyName assemblyName = AssemblyName.GetAssemblyName(System.IO.Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Plugins", "sample.dll"));

Assembly assembly = appDomain.Load(assemblyName); //This gives an exception of File not found

AppDomain.Unload(appDomain);

Я постоянно получаю файл не найден исключение при использовании загрузить на моем созданном AppDomain.

спасибо.

8
appdomain appdomainsetup c#

3 ответов

сначала убедитесь, что Plugins является подкаталогом вашего AppDomain базовый путь. PrivateBinPath будет работать только в подкаталогах, как описано здесь

Если это не проблема, взгляните на свои журналы привязки fusion. Используйте фьюжн просмотра журнала есть также хороший Блоге об этом. Журналы слияния сообщат вам, где он искал сборку. Это должно сказать вам, включен ли ваш путь в поиск.

один из другие возможности заключаются в том, что он находит вашу сборку, но не одну из ее зависимостей. Снова Fusion Log viewer скажет вам.

9

Я думаю, что я понял, почему это происходит, потому что текущий домен должен загрузить сборку тоже, даже если ваша загрузка сборки в другом домене приложения, текущий домен должен знать об этом и загружать его, потому что как был разработан .NET.

проверьте здесь для подробностей.

http://msdn.microsoft.com/en-us/library/36az8x58.aspx

и когда я проверил журналы слияния, я обнаружил, что недавно созданный домен приложения успешно удалось загрузить сборку из частного пути bin, и причина, по которой вы все еще получаете исключение "файл не найден", потому что это исключение изначально принадлежит текущему домену приложения.

Это означает, что если вы скопировали сборку в текущем пути приложения или в путь, где текущий домен зондирует, вы обнаружите, что вы можете загрузить сборку в свой пользовательский домен.

надеюсь, это поможет.

5

я наткнулся на этот поток при попытке динамически загрузить dll-файл из каталога за пределами каталога bin. Короче говоря, я смог это сделать, используя AppDomain.CurrentDomain.AssemblyResolve событие. Вот код:

//--begin example:

public MyClass(){
    AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;
}

private Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
    foreach (var moduleDir in _moduleDirectories)
    {
        var di = new DirectoryInfo(moduleDir);
        var module = di.GetFiles().FirstOrDefault(i => i.Name == args.Name+".dll");
        if (module != null)
        {
            return Assembly.LoadFrom(module.FullName);
        }
    }
    return null;
}

//---end example

метод CurrentDomain_AssemblyResolve вызывается каждый раз, когда AppDomain.CurrentDomain.Load("...") метод называется. Этот пользовательский обработчик событий выполняет работу по поиску сборки с помощью собственной пользовательской логики (что означает, что вы можете указать ей искать где угодно, даже за пределами пути bin и т. д.). Надеюсь, это сэкономит кому-то еще несколько часов...

5