Как две сборки плагина могут ссылаться на разные версии библиотеки зависимостей?C#

Место общения программистов C#
Ответить Пред. темаСлед. тема
Anonymous
 Как две сборки плагина могут ссылаться на разные версии библиотеки зависимостей?

Сообщение Anonymous »

Представьте, что у меня есть:
  • Игра .NET (Unity), поддерживающая моддинг (не моя игра, поэтому я не у меня нет никакого контроля над этим)
  • Он загружает моды, которые являются сборками .NET, которые могут приносить свои зависимости (DLL-библиотеки deps попадают в ту же папку, что и DLL мода)
    Они используют разные версии библиотеки зависимостей утилит, в идеале опубликованной на NuGet.
Теперь я ее автор сторонняя библиотека утилит.
Мне бы хотелось, чтобы моды могли использовать ее, не беспокоясь о конфликтах версий сборки. Например, ModOne загружает Утилиту 1.0.0, а ModTwo загружает Утилиту 2.0.0.
В этом случае по умолчанию используется самая последняя версия сборки (или первая загружаемая версия). не уверен) победит, и один из модов сломается.
Мне нужен совет, как решить эту проблему, не создавая кошмара для авторов модов.Я много искал в Интернете, но не нашел ничего четкого и определенного для моего конкретного случая использования.
Я рассматриваю два варианта:
  • Создайте зависимость сборки со строгим именем. Могут ли авторы модов ссылаться на него через
    , затем использовать для указания токена открытого ключа, а затем использовать псевдоним для принудительного использования определенной версии. Это вообще сработает? Я также могу пропустить NuGet и напрямую предоставить загружаемую .dll, если это поможет.
  • Публикуйте новые версии, но добавляйте новые пространства имен по мере возникновения критических изменений, например. UtilityLib.Feature.V2. Это будет работать до тех пор, пока всегда загружается новейшая версия сборки, но я не знаю, всегда ли это так, похоже, это зависит от используемой среды выполнения .NET, и я не знаю, как игра/Unity обрабатывает этот. Насколько мне известно, явное перенаправление привязки сборки невозможно, поскольку мы не контролируем конфигурацию игры.
  • Опубликуйте зависимость как мод, но по разным причинам мне бы хотелось этого избежать это решение.
Мне нужны конкретные рекомендации по этой проблеме, поскольку на подобные вопросы, но для немного других вариантов использования, уже были даны ответы, как правило, в расплывчатой ​​форме. Не будучи хорошо знаком с .NET, я в растерянности.
В заключение: вообще возможно сделать это в .NET детерминированным способом, не требующим сложных обходных путей. и сложная настройка для авторов модов, или мне следует отказаться?
Изменить
Только что попробовал подход № 1 со случайным уже существующим строгим именем сборки.
Это конфигурация в одном моде:

Код: Выделить всё



$(PkgDapper_StrongName)\Dapper.StrongName.dll
$(PkgDapper_StrongName)\Dapper.StrongName.dll


Второй мод имеет то же самое, что и версия 2.0+.
Хотя обе сборки присутствуют в выходных каталогах, и эта связь работает правильно в редакторе, во время выполнения все равно только версия 2.0, загруженная для обоих модов (ведение журнала typeof(typeof(DapperV*::Dapper.SqlMapper).Assembly.GetName().FullName)).


Подробнее здесь: https://stackoverflow.com/questions/786 ... ency-libra
Реклама
Ответить Пред. темаСлед. тема

Быстрый ответ

Изменение регистра текста: 
Смайлики
:) :( :oops: :roll: :wink: :muza: :clever: :sorry: :angel: :read: *x)
Ещё смайлики…
   
К этому ответу прикреплено по крайней мере одно вложение.

Если вы не хотите добавлять вложения, оставьте поля пустыми.

Максимально разрешённый размер вложения: 15 МБ.

  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «C#»