Используя две разные версии одного пакета NuGet

Я хотел использовать две разные версии одной библиотеки (OpenCVSharp 2.x и OpenCVSharp 3.икс) Ну, я загрузил эти два пакета как в отдельный проект (назовем его OCV2Wrapper и OCV3Wrapper), так и в мой проект. Мне пришлось переименовать библиотеки из одного пакета (2.x) и ссылаться на них вручную, потому что:можем ли мы добавить 2 разные версии одного и того же пакета в NuGet. Я читал о внешних псевдонимах, и я использовал внешний псевдоним в одной из оберток (2.икс в моем случае.) Но у меня есть некоторые серьезные проблемы:

  • мои переименованные библиотеки не копируются в сборку проекта запуска (ту, которая ссылается на обе оболочки), но находится в сборке 2.х фантик
  • Он не работает, потому что пока он не может найти тип из моего 2.X wrapper даже когда я вручную копирую переименованные библиотеки из 2.x обертка.

каков правильный подход для этого сценария в C#?

Я хочу использовать обе обертки в решении потому что 2.версия x содержит алгоритмы (SIFT и SURF) и 3.X verison содержит алгоритмы (Kaze и AKaze). Я могу жить, что оба пакета будут из nuget, но я предпочитаю 3.x-от nuget и 2.версия x настраивается вручную.

10
.net c# libraries reference

2 ответов

Как уже говорилось, нет ничего плохого в ссылках на 2 разные версии пакета nugget, если эти ссылки сделаны в разных проектах Visual Studio.

но здесь также заканчивается легкая часть, но я думаю, что осталось несколько вариантов. В зависимости от ваших потребностей я вижу следующие варианты.

  1. создайте шаг сборки post, который регистрирует сборки с несколькими версиями в GAC. Покуда каждое собрание имеет по-разному версия агрегата, CLR выберет вверх правый агрегат от GAC когда нужно.
  2. создайте шаг сборки post, который копирует различные сборки в подпапку вашей папки bin приложения, например bin / package-v1 и bin / package-v2. Тогда вы можете в своем приложении переопределить AssemblyResolve событие, как описано здесь https://msdn.microsoft.com/en-us/library/ff527268 (v=против 110).aspx. Это сделает его возможно для вас загрузить сборку в правильной версии в момент необходимости.
  3. если вы не хотите играть с AssemblyResolve, то вы также можете изменить свой web / app.config для перенаправления/зондирования сборки, как описано здесь https://msdn.microsoft.com/en-us/library/4191fzwb (v=против 110).aspx

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

8

OK Итак, я решаю это, загружая весь исходный код для 2.X версия обертки. Переименовал свое пространство имен в ABCDEF2, где ABCDEF было исходное пространство имен. Создайте свой собственный пакет nuget с моим собственным ключом и... опубликуйте его на нашем частном сервере nuget. Это такое хромое решение, но нет другого способа, кроме как вручную загружать исходные пакеты и ссылаться на него напрямую с другим именем файла и т. д., И вы теряете преимущества nuget.

1