Разрешая блоки, нечеткий путь

Question

Разрешая блоки, нечеткий путь

Вот установка:

Чистая библиотека классов DotNET загружается неуправляемым настольным приложением. Библиотека классов действует как плагин. Этот плагин загружает небольшие собственные детские плагины (все Библиотеки классов DotNET), и он делает так путем чтения dll в память как поток байтов, затем

Assembly asm = Assembly.Load(COFF_Image);

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

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

Короче говоря, как я надежно иду от Системы. ResolveEventArgs. Поле имени к dll пути к файлу, предполагая у меня есть список всех папок, где этот dll мог скрываться)?

11

c# assemblies resolveassemblyreference

задан starblue 28 April 2010 в 19:21

3 ответа

Мне никогда не везло с AssemblyResolver. Я обычно делаю один из этих трех:

Требуйте, чтобы плагины не имели внешних ссылок, которых нет в GAC. Если они суки, скажите им ILMerge.
Требуйте, чтобы плагины сбрасывали все свои dll в известный каталог плагинов. Загрузите все сборки из этого каталога в память.
Требовать, чтобы зависимости подключаемых модулей существовали в пути, который исследуется слиянием. Вы можете выяснить, где папка ищет сборки, включите журнал слияния (fuslogvw.exe - не забудьте перезагрузиться после включения ведения журнала!).

1

ответ дан 3 December 2019 в 10:03

Managed Extensibility Framework (MEF) похоже на то, что решит все Ваши проблемы. Он может сканировать папки, чтобы найти библиотеки DLL, разрешить зависимости любой глубины и в целом управлять составом подключаемых модулей. Каждая часть (или «плагин») просто должна объявить, что ей нужно и что она предоставляет, а MEF позаботится о подключении. Если MEF удалось укротить зверя расширяемости VS2010, то он сможет справиться с чем угодно.

2

ответ дан 3 December 2019 в 10:03

Другие вопросы по тегам:

c# assemblies resolveassemblyreference

Похожие вопросы:

score 7 · Accepted Answer

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

что-то вроде этих строк:

string name = GetAssemblyName (args); //gets just the name part of the assembly name
foreach (string searchDirectory in m_searchDirectories)
    {
    string assemblyPath = Path.Combine (executingAssemblyPath, searchDirectory);
    assemblyPath = Path.Combine (assemblyPath, name + ".dll");        
    if (File.Exists (assemblyPath))
        {            
        Assembly assembly = Assembly.LoadFrom (assemblyPath);
        if (assembly.FullName == args.Name)
            return assembly;
        }
    }

для полноты:

private string GetAssemblyName (ResolveEventArgs args)
    {
    String name;
    if (args.Name.IndexOf (",") > -1)
        {
        name = args.Name.Substring (0, args.Name.IndexOf (","));
        }
    else
        {
        name = args.Name;
        }
    return name;
    }