Организация и размещение пользовательских dll и пакетов nuGet.

Автор Тема: Организация и размещение пользовательских dll и пакетов nuGet.  (Прочитано 3328 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн dmitrymaslakovАвтор темы

  • ADN OPEN
  • Сообщений: 40
  • Карма: 1
Как правильно размещать пользовательские dll и пакеты nuGet на которые ссылается наша сборка, загружаемая в автокад?
Предположим, есть проект myProject.dll, находящийся локально на нескольких компах. Для успешной загрузки myProject.dll требует, что бы зависимые сборки и пакеты nuGet были в одной папке с ней. При этом этих сборок может быть достаточно много и копировать их на все компы не хочется. Как бы их разместить на удаленный сервер, а компы ссылались бы на этот сервак. Мне не совсем ясен этот механизм, на dll-ки, идущие в комплекте с framework-ком и автокадом свойству copy local можно присвоить false, а у всех остальных надо ставить true, ибо работать не будет. Из всего, что я успел прочитать я только могу выделить assembly probing, но пока что не пробовал. Как быть в этой ситуации?

Отмечено как Решение dmitrymaslakov 02-06-2021, 15:04:06

Оффлайн Владимир Шу

  • ADN Club
  • *****
  • Сообщений: 611
  • Карма: 155
    • ПГСу Бложик
на dll-ки, идущие в комплекте с framework-ком и автокадом свойству copy local можно присвоить false, а у всех остальных надо ставить true, ибо работать не будет
я не пробовал, но думаю на остальные так же можно поставит false и при загрузке библиотеки нужно будет самостоятельно подгрузить нужные dll и сопутствующие файлы.
Смотри System.Reflection.Assembly.LoadFrom() и Autodesk.AutoCAD.Runtime.SystemObjects.DynamicLinker.LoadModule()
Как некоторый пример: https://adn-cis.org/kak-sredstvami-opredelit-raspolozhenie-tochki-otnositelno-kontura.html

Оффлайн Александр Ривилис

  • Administrator
  • *****
  • Сообщений: 13829
  • Карма: 1784
  • Рыцарь ObjectARX
  • Skype: rivilis
dmitrymaslakov,
Категорически не рекомендую располагать .NET dll-файлы в сети.
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение

Оффлайн dmitrymaslakovАвтор темы

  • ADN OPEN
  • Сообщений: 40
  • Карма: 1
И в локальной сети предприятия?

Оффлайн Александр Ривилис

  • Administrator
  • *****
  • Сообщений: 13829
  • Карма: 1784
  • Рыцарь ObjectARX
  • Skype: rivilis
И в локальной сети предприятия?
Я имел в виду именно локальную сеть.
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение

Оффлайн dmitrymaslakovАвтор темы

  • ADN OPEN
  • Сообщений: 40
  • Карма: 1
Александр Ривилис, Какие проблемы меня ждут, если они будут лежать в сети?

Оффлайн Александр Ривилис

  • Administrator
  • *****
  • Сообщений: 13829
  • Карма: 1784
  • Рыцарь ObjectARX
  • Skype: rivilis
Александр Ривилис, Какие проблемы меня ждут, если они будут лежать в сети?
Например, они просто не загрузятся.
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение

Оффлайн Дмитрий Загорулькин

  • ADN
  • *
  • Сообщений: 2531
  • Карма: 735
Как правильно размещать пользовательские dll и пакеты nuGet на которые ссылается наша сборка, загружаемая в автокад?
Предположим, есть проект myProject.dll, находящийся локально на нескольких компах. Для успешной загрузки myProject.dll требует, что бы зависимые сборки и пакеты nuGet были в одной папке с ней. При этом этих сборок может быть достаточно много и копировать их на все компы не хочется. Как бы их разместить на удаленный сервер, а компы ссылались бы на этот сервак.
Полностью согласен с Александром Наумовичем: загружать DLL из сети либо совсем не получится, либо будут возникать проблемы.
Мне встречались жизнеспособные схемы, которые действовали по принципу ретрансляции. То есть, в сети располагается общая папка с dll надстроек, а на ПК у пользователей есть копия этой папки. А также, есть приложение, которое в определённый момент выполняет синхронизацию локальной и сетевой папки. Это можно делать в любой момент, пока dll ещё не загружены в AutoCAD, например, перед запуском AutoCAD.
Мне не совсем ясен этот механизм, на dll-ки, идущие в комплекте с framework-ком и автокадом свойству copy local можно присвоить false, а у всех остальных надо ставить true, ибо работать не будет.
Библиотеки, которые включены в Framework, загружаются автоматически. Они уже есть в системе, когда установлен .NET Framework. Поэтому их и не надо добавлять отдельными dll.
Библиотеки AutoCAD есть в установленном AutoCAD - все их можно найти в папке, в которую AutoCAD был установлен. Когда приложение запускается в среде AutoCAD, то эти библиотеки уже будут загружены самим AutoCAD. Потому и их тоже не надо прикладывать к приложению.
А остальные вспомогательные библиотеки - пользовательские, из Nuget-коллекции и т.п., они отсутствуют в .NET Framework и в AutoCAD, не загружаются ни .NET Runtime, ни AutoCAD'ом. Поэтому, их надо поставлять вместе с приложением.
Если эти библиотеки будут лежать рядом с основной dll приложения, то они будут загружены автоматически. Иногда, правда, это не срабатывает для сборок, которые имеют ссылки на WPF контролы.
Вспомогательные библиотеки также можно размещать в любом другом месте. Но тогда нужен механизм поиска и подгрузки этих вспомогательных dll, который будет запускаться до первого обращения к типам из этих dll. Владимир уже показал выше пару вариантов, как это можно сделать.
А, ну и самое главное, что я хотел сказать.
Как правильно размещать пользовательские dll и пакеты nuGet на которые ссылается наша сборка, загружаемая в автокад?
Нет какого-то одного "самого правильного" способа. Есть рекомендации как лучше не делать (например, не ссылаться на общие dll в сетевой папке). А в остальном  - всё на усмотрение разработчика.