Принудительная версия Nuget - PullRequest
0 голосов
/ 21 мая 2019

Возможно ли получить доступ к одному и тому же пакету nuget, но к разным его версиям в одном и том же проекте netcore?

У меня есть чистое ядро ​​API, которое регистрируется вasticsearch. Он использует пакет: Serilog.Sinks.Elasticsearch - 6.5.0, который имеет Elasticsearch.Net - 6.0.0 в качестве собственной ссылки.

Все отлично работает и делал это месяцами. Но теперь, когда я для другой функциональности добавил Elasticsearch.Net - 7.0.0-alpha2 вручную в проект, также обновляется подузел для Serilog.Sinks.Elasticsearch, что нарушает функциональность.

Новый код на основе Elasticsearch.Net - 7.0.0-alpha2 работает отлично.

Есть ли способ заставить ссылку на nuget для Serilog.Sinks.Elasticsearch, чтобы он использовал Elasticsearch.Net - 6.0.0, в то время как мой новый код использует Elasticsearch.Net - 7.0.0-alpha2?

Nugets перед новым кодом:

enter image description here

Nugets с новым кодом:

enter image description here

Ответы [ 2 ]

1 голос
/ 21 мая 2019

В основном нет, но немного да. Это зависит:)

Система сборки (NuGet, .NET SDK, msbuild) создает выходные данные сборки со всеми библиотеками в одном каталоге. Если вам нужно elasticsearch.dll из двух разных версий пакета, как это может работать? Очевидно, что у вас не может быть двух файлов с одним именем, поэтому по крайней мере один из них нужно будет переименовать, но тогда, когда CLR нужно загрузить elasticsearch.dll, как он узнает, что у него другое имя, и как он знаете, как новое имя?

Таким образом, использование встроенных функций в системе сборки невозможно.

Однако .NET Framework поддерживает загрузку разных версий DLL, вам просто нужно поработать с копированием файлов и сообщить ему, где находятся разные версии. Используя элемент codebase в файле app.config, вы можете сказать ему, где находятся dll. Вы можете увидеть пример этого в %userprofile%\AppData\Local\Microsoft\VisualStudio\{your vs version folder}\devenv.exe.config. Подавляющее большинство этого файла связывает перенаправления и элементы codeBase. Вам понадобятся более сложные сценарии сборки, которые просто запускают dotnet publish, чтобы получить все ваши библиотеки в нужных местах. Это, вероятно, не позволит вам запустить сеанс отладки из VS, но вы всегда можете подключить VS как отладчик к работающему процессу, так что отладку все равно можно выполнить, это просто сложнее.

Это может быть только .NET Framework. Если это не работает в .NET Core, вы можете посмотреть AssemblyLoadContext, но я никогда не видел полного примера, кроме реализации no-op, которая просто использует контекст по умолчанию, но Я думаю, что это может помешать загрузке нескольких версий одновременно.

Еще один пример загрузки нескольких версий сборки в одном процессе в .NET Framework - использование доменов приложений. Но это определенно только .NET Framework на тот случай, если вам потребуется поддержка .NET Core или будущего One .NET (.NET 5). AssemblyLoadContext ближе всего подходит к доменам приложений в .NET Core, но это не то же самое.

Насколько мне известно, Mono не поддерживает загрузку нескольких версий сборки одновременно, но я предполагаю, что это изменится после выпуска .NET 5. Но это предположение, в котором отсутствуют какие-либо доказательства или какие-либо внутренние знания.

0 голосов
/ 21 мая 2019

Проблема, с которой вы столкнулись, известна как «Ад Dll», существует множество подходов к ее решению, например:

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

Может быть, этот старый пост также может помочь вам.

...