Каким образом можно решить эту проблему?Взаимодействовать посредством интерфейсов. Принцип аналогичен тому, который в COM.
В нашей компании есть следующая проблема: имеется несколько плагинов использующих общие библиотеки. При этом, если на машине установлен один из плагинов, и рядом ставится второй плагин с обновлённой общей библиотекой, то возникает конфликт.Решение очевидно - не делать так. Или не менять общие библиотеки или обновлять и ставить одновременно все плагины, использующие эти общие библиотеки.
Решение очевидноочевидно в текущем контексте. - так будет корректней.
За всю свою историю работы я ни разу не столкнулся с проблемами в работе своих .NET плагинов, использующих мною же созданных общих DLL.Тут существенно местоимение "Я". Замени его на "Мы" и вполне возможно что возникнет проблема.
и вполне возможно что возникнет проблема.И на чём же она должна возникнуть, если контракт не нарушен? Пример, если не сложно.
И на чём же она должна возникнуть, если контракт не нарушен? Пример, если не сложно.Главная проблема именно в том, что если созданием/развитием общих библиотек занимается не один, а несколько человек, то контракты часто нарушаются ("правила игры меняются по ходу игры"). Результаты мы видим у MikhailTAP.
Вариантом был бы StrongName, но сделать это невозможно, т.к. библиотеки Акада которые используются - не подписаны.давно известный факт, причём автодеск утверждает, что это безобразие создано специально (http://adndevblog.typepad.com/autocad/2012/07/can-i-sign-my-autocad-net-plug-in-with-a-strong-name.html).
Может быть, есть у кого-то интересные идеи по данному вопросу? Или критические замечания по такой схеме?Пока на уровне интуиции я могу сказать, что так делать не следует.
Во-первых не следует полагаться на порядок загрузки. Я не проверял, но мне кажется, что он читает каталоги внутри ApplicationPlugins и обрабатывает их не в алфавитном порядке, а в том порядке в котором они находятся в каталоге (а это совершенно необязательно отсортированные по алфавиту).Вот да, именно так! На уровне подсознания где-то, есть понимание, что это весьма ненадежно :)
Во-вторых, я бы предпочел в методе Initialize своих приложений загружать необходимые сборки если они еще не загружены, а если их загрузить не удаётся, то сообщал бы пользователю.А это уже весьма интересная идея! Надо будет проверить, как это будет работать.
В-третьих, я бы вообще не включал их ни в какие BUNDLE'ы - если это библиотечные файлы, то зачем отдавать их загрузку на волю AutoCAD?Да, согласен. Если Ваша идея с подгрузкой из Initialize хорошо покажет себя в работе, то от загрузки библиотеки через bundle можно отказаться.
А это уже весьма интересная идея! Надо будет проверить, как это будет работать.Главное, чтобы у тебя не было статических переменных, которые инициализируются значениями, использующие классы и методы из этих "библиотек". Насколько я помню инициализация статических переменных происходит до вызова метода Initialize (могу ошибаться).
Главное, чтобы у тебя не было статических переменных, которые инициализируются значениями, использующие классы и методы из этих "библиотек". Насколько я помню инициализация статических переменных происходит до вызова метода Initialize (могу ошибаться).Нет, не ошибаетесь. Это естественное поведение при загрузке любого .NET класса.
Я в этом моменте плюю на размер в угоду надежности. В БД если обновляется любой компонент, то автоматом создается архив со всеми сборками и пр. компонентами и при загрузке автокада "загрузчик" увидев новую версию в БД все переписывает на локальном компе (с учетом "уровня" пользователя) - то есть чистит все "свои" сборки и разворачивает по новой весь загруженный архив. И если что, можно в момент откатить до любой предыдущей версии - пока правда такое "счастье" миновало, но все возможно.У меня "загрузчиков" никаких нет. Для приложений я создаю инсталляторы с помощью WIX. Наверное, в проект инсталляции тоже можно добавить программу, которая будет анализировать уже имеющиеся приложения и библиотеки в них, но я пока до этого не дорос.
Если раскомментить строки 44-46 (обращения к методам вспомогательных библиотек), то метод Initialize не выполнится и DLL с этим кодом не будет загружена. Не знаю, почему так.Ну для начала их тоже нужно обернуть в try/catch, так как если в Initialize остаётся необработанное исключение, то сборка не работает.
Главное, чтобы у тебя не было статических переменных, которые инициализируются значениями, использующие классы и методы из этих "библиотек".Ваш совет натолкнул меня на идею - вынести загрузку библиотек в статический конструктор класса. В таком варианте работает как надо! Еще раз, спасибо за идею! Теперь надо обкатать ее на рабочих сборках.
Со сторонними библиотеками есть проблемы - использования разных версий в разных плагинах.Я уже третий год использую схему, которую описал в предыдущем своём сообщении в этой теме - такой проблемы у меня больше нет.
Если скопировать более свежую System.Data.SQLite.dll из Плагина#2 в Плагин#1 - всё работает.Собственно говоря это единственный мне известный метод. Две разных версии одной сборки загрузить в один домен нельзя.
там используются не только managed, но и native dll-файлыох, с таким еще не сталкивались, слава богу 😁
Собственно говоря это единственный мне известный метод. Две разных версии одной сборки загрузить в один домен нельзя.Спасибо. Ох, это прям фиаско.
Можно переименовать дллку и грузить ее принудительно. В некоторых случаях помогает.Просто сменить имя файла? Проверял, не сработало.
Может мой вопрос покажется дилетантским и риторическим, но вот интересно, как в компании Autodesk предполагали работу их системы?1. Причем здесь AutoCAD? Это касается любого exe-файла, для которого создаётся система плагинов. Тут скорее претензия к Microsoft, что они не предусмотрели такое...
В своем проекте выставил для System.Data.SQLite.dll свойство 'Specific version'=false. Надеюсь, это хоть немного увеличит шансы пользователей в нелегком деле копирования файловТеоретически это могло бы помочь если бы под капотом не использовались native dll-файлы. А так очень сомнительно...
Получается, что конфликт просто неизбежен?Да, это так. Даже если сделать систему распространения своих приложений таким образом, чтобы исключались конфликты версий вспомогательных библиотек, это не поможет, если используются сторонние плагины с теми же библиотеками других версий. Я, например, тоже System.Data.SQLite использую в одном из плагинов. И я не помню, когда последний раз его версию обновлял.
Получается, я облегчаю себе жизнь, как разработчику, вынося повторяющийся функционал в общие библиотеки, но этим усложняю жизнь пользователям.Вот именно. И это одна из причин, почему я пошел обратным путем - один плагин = одна dll. Ни каких вспомогательных. А исходные коды во всех проектах плагинов на 90% одни те же - вставлены в проект как ссылки. Да, я теряю в скорости компиляции, вынужден заталкивать все новые файлы CS во все проекты. Зато у пользователя нет проблем совместимости.
1. Причем здесь AutoCAD? Это касается любого exe-файла, для которого создаётся система плагинов. Тут скорее претензия к Microsoft, что они не предусмотрели такое...Претензия не к функционалу. Просто факт не очевидный. На месте человека, который выбирает язык программирования под AutoCAD, я бы хотел это узнать как можно раньше.
Сигнатуры там не менялись, обычный IDbConnection ...Может попробовать через рефлексию? Если вызовов не сильно много, может и не сильно сложно получится.