#nuget
#nuget
Вопрос:
Мы создаем все решения для общего каталога bin. Наличие разных проектов, ссылающихся на разные версии одной и той же зависимости, вредно для нашей сборки.
Итак, мы объединили зависимости — отлично. Но теперь версии снова начинают смещаться. Мы не хотим время от времени консолидировать их вручную — мы хотим полностью предотвратить смещение.
Почему мы не хотим использовать Пакет? Основная причина в том, что, похоже, мы потеряли бы возможность переносить зависимости пакета NuGet в новые элементы PackageReference в проектах. Итак, в настоящее время у нас есть файлы package.config, но мы планируем заменить их соответствующими ссылками на пакет. Это означает, что мы будем использовать внутреннюю поддержку NuGet в msbuild, которая, похоже, не оставляет места для пакета.
Я предполагаю, что мы не уникальны в этом мире, и у других такая же проблема, как и у нас. Как вы это решаете?
РЕДАКТИРОВАТЬ 1
У нас есть наше внутреннее репозиторий NuGet, но мы используем его для зависимостей, которые не имеют органического представления в Nuget.org и для совместного использования наших собственных внутренних пакетов.
Один из подходов заключается в использовании только из внутреннего репозитория NuGet. Это сопряжено с проблемами, такими:
- Кто загружает туда зависимости? Разработчики? Но тогда как убедиться, что они не загружают разные версии одной и той же зависимости? Преданные люди? Тогда они становятся узким местом.
- Небольшая вещь, но нам нужно заблокировать фиксации в центральном NuGet.config
- Загрузка зависимости во внутреннее репозиторий NuGet происходит не сразу. Вы не можете просто загрузить его с NuGet.org и загрузить во внутреннее, потому что это приведет к отсутствию каких-либо переходных зависимостей. Итак, процесс должен быть построен вокруг этого.
Все это возможно, но я неохотно иду по этому пути … Должен быть лучший способ.
ПРАВКА 2
Хотя мы планируем перейти на PackageReference, это займет время. И, к сожалению, пока у нас есть Silverlight (по крайней мере, еще год), целая куча проектов в выделенном решении Silverlight (80 ) не будет перенесена в PackageReference, потому что при этом становится невозможной отладка кода с помощью VS 2015.
Далее, предположим, что мы действительно переносим ВСЕ проекты, а затем переносим все элементы PackageReference в один целевой файл, импортированный всеми проектами. Это возможно при использовании общего каталога bin, как мы планируем сделать. Но при проверке в VS 2017 эта настройка выдает неверную картину, что каждый отдельный проект зависит от всего набора зависимостей NuGet. Я бы предпочел избежать этого.
Комментарии:
1. Вы думали о создании пользовательского репозитория для собственного использования, который вы могли бы обновлять по мере необходимости, чтобы ваши проекты указывали на пользовательский репозиторий? Затем вы могли бы управлять обновлениями по мере необходимости. У нас вроде как та же проблема. Мы обнаружили, что наличие пользовательского репозитория помогло свести проблему к минимуму. Пока не полностью искоренить … все еще изучаю.
2. Вы имеете в виду пользовательский канал NuGet? Это интересная идея, которая может оказаться полезной.
3. @tster — Да. создание пользовательского репозитория действительно может помочь сохранить контроль над изменением версий, по крайней мере, для нас.
4. Смотрите ПРАВКУ 1 .
5. что касается вашего последнего комментария в правке 2, я не предлагаю помещать ваши
PackageReferenceфайлы во внешний файл и заставлять все ваши проекты иметь одинаковые зависимости. Вместо этого ваши отдельныеcsprojфайлы имеют<PackageReferene Include="packageid" Version="$(SomeMSBuildProperty) />, и вы сохраняете значениеSomeMSBuildPropertyв одном / центральном файле. Таким образом, когда вы хотите изменить версии, вы редактируете один файл, и все ссылки обновляются до одной и той же версии, но отдельные проекты по-прежнему выбирают, от каких пакетов они зависят.
Ответ №1:
Как только вы перейдете к PackageReference, вы можете воспользоваться преимуществами MSBuild. Например, у вас может быть файл MSBuild, содержащий все ваши версии зависимостей. Это может быть файл, который вам нужен во <Import ... /> всех ваших csproj файлах, или вы могли бы использовать Directory.Build.props . Наконец, в каждом из ваших проектов измените номер версии в любой <PackageReference переменной MSBuild, которая использует свойство, которое вы ранее определили. Большинство репозиториев Microsoft с открытым исходным кодом используют этот метод с небольшими изменениями в именах файлов и в том, импортируется ли он автоматически с помощью Directory.Build.props или явно <Import ... /> .
Хотя вы все еще можете использовать пользовательский интерфейс менеджера пакетов в Visual Studio для проверки обновлений, вы не сможете обновлять версии пакетов с его помощью (по крайней мере, это не сохранит, как и где определены версии). Однако просто убедитесь, что ваш файл MSBuild, который определяет версии, находится в вашем решении, чтобы вы могли тривиально открыть файл в обозревателе решений, а затем ввести номер новой версии. Добавление новых ссылок на пакеты требует немного больше усилий, но обычно это делается не часто, и это все еще очень просто с проектами в стиле SDK, поскольку Visual Studio позволяет редактировать csproj, пока проект все еще загружен.
Ответ №2:
Поскольку вы не приняли другое решение, может быть, вы могли бы взглянуть на пакет
Это менеджер пакетов для dotnet, который (среди прочих функций) содержит файл блокировки зависимостей для всего решения. Оно очень настраиваемо, и хотя оно решает МНОЖЕСТВО проблем, как и любой инструмент, создает некоторые новые. По моему опыту, новые гораздо менее раздражают 🙂
Комментарии:
1. В итоге мы написали инструмент, который запускается перед сборкой и проверяет зависимости всех проектов во всех решениях, гарантируя, что все они одинаковы.