Динамический вызов SevenZipSharp

Question

Добрый день! Что-то непозволительно долго ковыряюсь с казалось бы ерундовой затеей...

Задача - динамически загрузить сборку SevenZipSharp.dll (известная библиотека для работы с архивами), затем создать экземпляр SevenZipExtractor(string ArchiveFullName) и вызвать метод ExtractArcive(string directory), который должен распаковать указанный архив в заданную директорию.

Делаю так:

//Так как зависимостей у либы нет, то гружу сборку из ресурсов в массив байт, минуя выгрузку в файл.
var resourceBuffer = Properties.Resources.ResourceManager.GetObject(resnameSevenZipSharpLibrary) as byte[];
Assembly _SevenZipSharp = Assembly.Load(resourceBuffer);

//Сборка успешно загружается, получаем инфо по типу SevenZip.SevenZipExtractor
var extaractorClassType = _SevenZipSharp.GetType(SevenZip_ExtractorClassName);


string ArchiveFullPath = "D:\\TEST.ARJ";
//Пробуем создать экземпляр класса, передав одному из конструкторов в качестве аргумента полное имя архива:
var Extractor = Activator.CreateInstance(extaractorClassType, new object[] { ArchiveFullPath });

Собственно, тут и падает приложение с ошибкой:

System.Reflection.TargetInvocationException ("Адресат вызова создал исключение.")
...
Inner excepton: System.TypeInitializationException ("Инициализатор типа "SevenZip.SevenZipLibraryManager" выдал исключение.")

в SevenZip.SevenZipLibraryManager.LoadLibrary(Object user, Enum format)
в SevenZip.SevenZipExtractor.Init(String archiveFullName)
в SevenZip.SevenZipExtractor..ctor(String archiveFullName)

Inner excepton: System.ArgumentException ("Путь имеет недопустимую форму.")`

Если задать, к примеру, путь как ArchiveFullPath = "TEST.ARJ", то он выдаст ошибку файл не найден (что совершенно логично, ибо в CurrentDirectory архива нет). Т.е. путь в виде краткого имени файла он вроде как прожевывает, а вот если указать диск, то уже не хочет.

Возможно, кто-то сталкивался с аналогичной проблемой, или может быть, что-то не то творю. Замылился уже глаз, пробовал по-разному, через GetConstructor, например.

Разумеется, до вызова метода ExtractArchive дело даже не доходит.

Да, я знаю, что можно добавить в проект еще до компиляции ссылку на сборку, и беспрепятственно использовать классы из namespace SevenZip, просьба такой вариант не предлагать. Можно было бы сделать так - не парил бы мозг и сделал бы сразу.

Спасибо за внимание!

Если вызывать легально - проблема проявляется? — Monk, Nov 14 '16 at 11:40
Нет, проблемы не появляется, иначе не было бы вопроса. В тестовом проекте на либу ссылаюсь через Referencies, вполне себе работает вот так без всяких проблем: using (var arj = new SevenZipExtractor(arjArchiveName)) { arj.ExtractArchive(targetDir); } — BlackWitcher, Nov 14 '16 at 11:48

score 0 · Accepted Answer · edited Apr 13 '17 at 12:53

Ситуация решилась несколько иначе, желаемый результат был достигнут иным путём. Решение было навеяно вот этим вопросом, но не затрагивает Build Action и EmbeddedResource вкупе с событием AssemblyResolve.

Итого:

SevenZipSharp.dll была приаттачена к ресурсам самого проекта, т.е. внутрь сборки: Project --> Properties --> Resources наравне с 7z.dll, которая необходима для работы SevenZipSharp.dll.
В ссылках на сборки (References) была добавлена ссылка на файл SevenZipSharp.dll. В свойствах ссылки было задано Copy Local = False дабы при билде проекта эта сборка не копировалась туда же, где и основной бинарник проекта. Всё, теперь можно использовать namespace SevenZip в коде и создавать любые объекты без привлечения рефлексии.

Был написан несложный метод, который берет и извлекает ресурсы из проекта на диск в виде файлов. Да, можно было напрямую сохранять каждый ресурс, обращаясь к нему, например, так: byte[] lib = Properties.Resources.SevenZipSharp;. Но мне захотелось сделать выгрузку в файл по имени ресурса и повторно еще использовать этот метод:

private static bool ExtractBinaryResourceToFile(string resourceName, string filename)
{
    if (string.IsNullOrEmpty(resourceName))
    {
        throw new ArgumentNullException(resourceName, "Не указано имя извлекаемого ресурса.");
    }
    if (string.IsNullOrEmpty(filename))
    {
        throw new ArgumentNullException(filename, "Не указано имя файла, в который сохранять ресурс.");
    }
    var resourceBuffer = Properties.Resources.ResourceManager.GetObject(resourceName) as byte[];
    if (resourceBuffer == null) return false;
    try
    {
        File.WriteAllBytes(filename, resourceBuffer);
    }
    catch (Exception e)
    {
        throw e; //Поскольку в приложении есть обработчик ошибок, то просто генерим ошибку, которую он отловит.
    }
    return File.Exists(filename);
}

Работа с SevenZipSharp осуществляется довольно просто, примерно так:

        using (var arj = new SevenZip.SevenZipExtractor(ArchiveFullPath))
        {
            arj.ExtractArchive(TargetDir);
        }

PROFIT!!1

Поскольку у меня в проекте есть ряд ограничений (решение должно выглядеть в виде ОДНОЙ DLL, которая, в свою очередь, является модулем приложения), то пришлось поступать таким вот образом. Поэтому-то приходится при инициализации своего модуля распаковывать руками из ресурсов и 7z.dll, и SevenZipSharp.dll в ту же папку, где и находится основной модуль (тот самый, в котором и хранится всё это добро).

Тогда вот этом случае обработчик AssemblyResolve основного приложения видит библиотеку SevenZipSharp.dll, а та, в свою очередь, прекрасно видит 7z.dll даже без явного указания пути в SevenZipExtractor.SetLibraryPath().

Возможно, я что-то упустил, но иного разрешения ситуации придумать не смог. Ибо даже если загружать сборку SevenZipSharp.dll напрямую из ресурсов в AssemblyResolve, но такое вряд ли прокатит с неуправляемой 7z.dll.

Оттого сначала при инициализации моей сборки происходит выгрузка необходимых библиотек из ресурсов основной сборки в файлы.

Динамический вызов SevenZipSharp

1 Answers1