С# Проблема с динамической dll

У меня есть приложение, которое динамически загружает DLL. Приложение и dll используют файл Functions.dll, который может быть разной версией для приложения и для каждой dll, но при выполнении приложение и dll используют одну и ту же версию dll (та, которая используется EXE) и совместно используют статический переменные...

Как я могу заставить их использовать свои собственные Functions.dll (n-версия)?

-Подробности:

  • Я попытался загрузить dll с помощью «Assembly dll = Assembly.LoadFile(» и «Assembly dll=domaindll.Load(»
  • В Functions.dll все методы и объекты являются статическими.
  • Я использую Functions.dll «статически», ссылаясь на него через VS во всех случаях, а не динамически.
  • DLL и Functions.dll также разработаны на C#.

-Структура папки:

Заявление:

Application.EXE
Functions.dll(version 1.2)
DLLS:
    EXAMPLEDLL1:
        EXAMPLEDLL1.DLL
        Functions.dll(version 1.1)
    EXAMPLEDLL2:
        EXAMPLEDLL2.DLL
        Functions.dll(version 1.0)
    EXAMPLEDLL3:
        EXAMPLEDLL3.DLL
        Functions.dll(version 1.2)

dynamic c# load dll assemblies
person VSP    schedule 10.06.2009    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Вы можете принудительно привязать конкретную версию DLL, подписав ее строгой подписью. Вы также можете попробовать установить для параметра «Конкретная версия» значение true в свойствах ссылки, но, насколько мне известно, это влияет только на привязку во время компиляции, и во время выполнения может быть загружена другая версия, если сборка не имеет строгой подписи.

Это должно помочь вам начать работу: Подпись строгого имени для управляемых приложений

Имейте в виду, однако, что любые типы, объявленные в этой dll, не будут эквивалентны по типам тому же типу в другой версии сборки. Например, если я объявляю класс с именем Foo в Functions.dll, то экземпляр Foo из версии 1.0 не будет того же типа, что экземпляр Foo из версии 1.1. Что касается CLR, то это совершенно разные типы.

Если все, что у вас есть, это статические функции в сборке, а типы не определены, то все должно быть в порядке. В противном случае вам нужно изучить другой подход.

person Adam Robinson    schedule 10.06.2009
comment
Это хорошее решение ... но я не могу подписать Functions.dll, потому что, когда я использую подписанную Fuctions.dll в тесте (статически ссылаясь на проект), он дает случайные ошибки в каждом методе dll. (Этого не происходит с неподписанным) Примеры: Лучшее совпадение перегруженного метода для -'Funciones.FunSAP.comboboxvaciar(SAPbouiCOM.ComboBox)' имеет некоторые недопустимые аргументы -'x.Application' не содержит определения для 'Formx' и не удалось найти метод расширения «Formx», принимающий первый аргумент типа «x.Application» (вам не хватает директивы using или ссылки на сборку?) - person VSP; 11.06.2009
comment
Возможно, вам следует отредактировать свой вопрос и опубликовать реальный пример кода. Это может сделать проблему более очевидной. - person Adam Robinson; 11.06.2009

arrow_upward
0
arrow_downward

Чтобы сделать это, я думаю, вам придется загружать ваши (пример) библиотеки DLL в отдельные домены приложений. Выполнение вызовов между доменами приложений влечет за собой небольшое снижение производительности, но это неизбежно в рассматриваемом вами сценарии.

person jerryjvl    schedule 10.06.2009
comment
Проблема в том, что это несовместимо с проектом разработки/отладки (см. мой другой вопрос: конфликт версии C# dll), поэтому я не тестировал это решение... я не знаю, сработает ли оно для конкретной проблемы (использование доменов приложений будет полезно также для возможности динамической выгрузки dll...) Если у меня будет время протестировать его, я опубликую результаты, чтобы другие люди знали... (я нашел хорошую ссылку для тестирования, когда смогу.. experts-exchange.com/Programming/Languages/C_Sharp/) - person VSP; 11.06.2009
comment
Я не думаю, что в одном домене приложения вы можете загружать несколько разных версий одной и той же библиотеки, если, возможно, не подписываете ее, чтобы она имела строгую идентичность. - person jerryjvl; 11.06.2009

arrow_upward
0
arrow_downward

В конце концов я решил это, переименовав Functions.dll, чтобы он соответствовал EXAMPLEDLL, который его использует.

Постданные: в другом случае, когда я мог правильно подписать DLL, я думаю, что ответ Адама Робинсона был бы правильным (и jerryjvl - вторым ответом).

person VSP    schedule 15.06.2009