Несколько плагинов с общими библиотеками

[Роман Малютин]

Собственно говоря это единственный мне известный метод. Две разных версии одной сборки загрузить в один домен нельзя.

Спасибо. Ох, это прям фиаско.
Может мой вопрос покажется дилетантским и риторическим, но вот интересно, как в компании Autodesk предполагали работу их системы? В плагинах же повсеместно используются популярные библиотеки для типовых операций - работа с БД, экспорт данных в Excel/Word/PDF, всякие там ORM, мапперы... Получается, что конфликт просто неизбежен?
Только в App Store более 4000 приложений, думаю там немало на .net.
Заставлять пользователя рыться в файлах плагинов и выискивать конфликтные библиотеки - это конечно рабочее решение, но в 99% случаев сами знаете что будет.

Можно переименовать дллку и грузить ее принудительно. В некоторых случаях помогает.

Просто сменить имя файла? Проверял, не сработало.

В своем проекте выставил для System.Data.SQLite.dll свойство 'Specific version'=false. Надеюсь, это хоть немного увеличит шансы пользователей в нелегком деле копирования файлов 

[Александр Ривилис]

Может мой вопрос покажется дилетантским и риторическим, но вот интересно, как в компании Autodesk предполагали работу их системы?

1. Причем здесь AutoCAD? Это касается любого exe-файла, для которого создаётся система плагинов. Тут скорее претензия к Microsoft, что они не предусмотрели такое...
2. Кто заставляет тебя пользоваться сторонними библиотеками в своих приложениях? Для ObjectARX допустима вообще только конкретная версия Visual Studio с конкретным пакетом обновлений. И ничего - никто не жалуется. :-)

В своем проекте выставил для System.Data.SQLite.dll свойство 'Specific version'=false. Надеюсь, это хоть немного увеличит шансы пользователей в нелегком деле копирования файлов 

Теоретически это могло бы помочь если бы под капотом не использовались native dll-файлы. А так очень сомнительно...

[Дмитрий Загорулькин]

Получается, что конфликт просто неизбежен?

Да, это так. Даже если сделать систему распространения своих приложений таким образом, чтобы исключались конфликты версий вспомогательных библиотек, это не поможет, если используются сторонние плагины с теми же библиотеками других версий. Я, например, тоже System.Data.SQLite использую в одном из плагинов. И я не помню, когда последний раз его версию обновлял.
Возможно, в случае с SQLite можно как-то избежать проблемы, если найти возможность использовать те же самые DLL, которые использует сам AutoCAD для работы с ней. Где-то среди его файлов установки я находил библиотеки SQLite. Но, возможно, что это только в Civil 3D. И, скорее всего, там используется Native версия SQLite.

[avc]

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

Вот именно. И это одна из причин, почему я пошел обратным путем - один плагин = одна dll. Ни каких вспомогательных. А исходные коды во всех проектах плагинов на 90% одни те же - вставлены в проект как ссылки. Да, я теряю в скорости компиляции, вынужден заталкивать все новые файлы CS во все проекты. Зато у пользователя нет проблем совместимости.

[Дмитрий Загорулькин]

avc, адаптеры к БД тоже свои пишете? 

[avc]

Неее Доступ к SQL встроен в .Net - им и пользуюсь. А если что-то надо подключить - вариант только искать open source. Пока все что надо находил

[Роман Малютин]

1. Причем здесь AutoCAD? Это касается любого exe-файла, для которого создаётся система плагинов. Тут скорее претензия к Microsoft, что они не предусмотрели такое...

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

Из-за меня тут люди пострадали. Делали-делали свой шедевр, а в итоге пользователь просто удалил их плагин, т.к. он конфликтует с моим. А могло быть и наоборот!

Попытался проскочить нахаляву:

Код - INI [Выбрать]

1. ildasm /all /out=System.Data.SQLite.il System.Data.SQLite.dll
2. (правка il файла в VS Code)
3. ilasm /dll /out=System.Data.SQLite222.dll System.Data.SQLite222.il

Не вышло. Переименовать получилось, работает, но всё равно конфликтует. Теперь застрял на PublicKeyToken. Видимо все же придется компилировать из исходников...

[Дмитрий Загорулькин]

Сигнатуры там не менялись, обычный IDbConnection ...

Может попробовать через рефлексию? Если вызовов не сильно много, может и не сильно сложно получится.

[Роман Малютин]

Итак, вот чем закончилась моя история с SQLite:
Поковырял исходники - не моя лига  Там такой навороченный MSBuild, что Visual Studio даже файлы классов внутри проекта отобразить не может. Всё подключается на каком-то лютом автомате.

Плюнул я на это дело, и обратился к фрилансерам. $40 - цена вопроса на Upwork. Курс доллара конечно огорчает, зато теперь у меня есть "своя" dll для SQLite, которая ни с кем не конфликтует.
Исходники не понадобились, исправили готовую dll. Сравнил il-код до и после - много мелких изменений, мне не понятных. Похоже софтинка какая-то есть специальная.
Всем спасибо за поддержку.

[Дмитрий Загорулькин]

Тоже вариант