- Игра .NET (Unity), поддерживающая моддинг (не моя игра, поэтому я не у меня нет никакого контроля над этим)
- Он загружает моды, которые являются сборками .NET, которые могут приносить свои зависимости (DLL-библиотеки deps попадают в ту же папку, что и DLL мода)
Они используют разные версии библиотеки зависимостей утилит, в идеале опубликованной на NuGet.
Мне бы хотелось, чтобы моды могли использовать ее, не беспокоясь о конфликтах версий сборки. Например, ModOne загружает Утилиту 1.0.0, а ModTwo загружает Утилиту 2.0.0.
В этом случае по умолчанию используется самая последняя версия сборки (или первая загружаемая версия). не уверен) победит, и один из модов сломается.
Мне нужен совет, как решить эту проблему, не создавая кошмара для авторов модов.Я много искал в Интернете, но не нашел ничего четкого и определенного для моего конкретного случая использования.
Я рассматриваю два варианта:
- Создайте зависимость сборки со строгим именем. Могут ли авторы модов ссылаться на него через
, затем использовать для указания токена открытого ключа, а затем использовать псевдоним для принудительного использования определенной версии. Это вообще сработает? Я также могу пропустить NuGet и напрямую предоставить загружаемую .dll, если это поможет. - Публикуйте новые версии, но добавляйте новые пространства имен по мере возникновения критических изменений, например. UtilityLib.Feature.V2. Это будет работать до тех пор, пока всегда загружается новейшая версия сборки, но я не знаю, всегда ли это так, похоже, это зависит от используемой среды выполнения .NET, и я не знаю, как игра/Unity обрабатывает этот. Насколько мне известно, явное перенаправление привязки сборки невозможно, поскольку мы не контролируем конфигурацию игры.
- Опубликуйте зависимость как мод, но по разным причинам мне бы хотелось этого избежать это решение.
В заключение: вообще возможно сделать это в .NET детерминированным способом, не требующим сложных обходных путей. и сложная настройка для авторов модов, или мне следует отказаться?
Изменить
Только что попробовал подход № 1 со случайным уже существующим строгим именем сборки.
Это конфигурация в одном моде:
Код: Выделить всё
$(PkgDapper_StrongName)\Dapper.StrongName.dll
$(PkgDapper_StrongName)\Dapper.StrongName.dll
Хотя обе сборки присутствуют в выходных каталогах, и эта связь работает правильно в редакторе, во время выполнения все равно только версия 2.0, загруженная для обоих модов (ведение журнала typeof(typeof(DapperV*::Dapper.SqlMapper).Assembly.GetName().FullName)).
Подробнее здесь: https://stackoverflow.com/questions/786 ... ency-libra