Управление версиями NuGet с зависимостями ProjectReference - PullRequest
Новая
       51

Управление версиями NuGet с зависимостями ProjectReference

0 голосов
/ 13 ноября 2018

У меня есть решение, содержащее несколько проектов. Допустим, PackageA и PackageB , где PackageB зависит от PackageA с ProjectReference .
Каждый проект также настроен на вывод пакета NuGet при сборке. Сам этот процесс работает отлично, но я не могу указать диапазон версий пакета для отдельных сборок. Например. Я хотел бы ограничить PackageB ссылками только на PackageA версии 1.0. * (Шаги исправления). 

<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
  <PropertyGroup
    <TargetFrameworks>netstandard2.0;netcoreapp2.0;net46</TargetFrameworks>

    <RootNamespace>PackageB</RootNamespace>
    <Company>MyCompany</Company>
    <Authors>John Doe</Authors>
    <Description>This package depends on a specific version of PackageA.</Description>
    <Version>1.1.0</Version>
    <Copyright>Copyright © 2018 John Doe</Copyright>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\PackageA\PackageA.csproj" />
  </ItemGroup>
</Project>

MSBuild, похоже, игнорирует любые Version = "1.0. *" или AllowVersion = "1.0. *" аргументы в теге ProjectReference .
Есть ли возможность указать диапазон версий, не нарушая ProjectReference или используя PackageReference ?

Ответы [ 2 ]

0 голосов
/ 16 ноября 2018

Хорошо, давайте подумаем, что до конца?Проект может иметь номер версии, встроенный в него где-то, но, скорее всего, это будет последняя или предыдущая версия, которая может даже не быть собрана, и нет никакой гарантии, что на следующем этапе сборки это значение не будет обновлено.Точка, в которой система сборки создает версионный артефакт, находится в конце сборки, обычно это последний шаг, который обычно является этапом упаковки или публикации.

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

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

Одна вещь, которую вы никогда не должны делать, - это создание двух разных пакетов с одинаковыми номерами версий.Проекты Visual Studio разбиты по дизайну в области управления версиями, так как по умолчанию они используют статическую строку версии, которая должна быть задана до сборки.Если вы забудете поднять это число, вы нарушите это правило семантического контроля версий.

Даже если разработчики Nuget / VS дадут вам то, о чем вы просите, это не хорошее решение.Что, если в настоящее время извлеченный проект предназначен для версии за пределами указанного диапазона?Предполагая, что разработчики могут выяснить, какой код следует проверить в контроле версий, это действительно то, что вы хотите, чтобы происходило на вашем устройстве разработки?Любое решение, которое они придумают, будет сложным и подверженным ошибкам.Даже если у вас есть проверенная версия, Nuget не может знать, что вы не внесли в нее существенных изменений.

Лучше запустить независимые конвейеры кода, просмотреть, собрать, упаковать, проверить и опубликовать, используя в качестве зависимостей только опубликованные пакеты.

0 голосов
/ 13 ноября 2018

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

Но пока эта функция включена только на PackageReference. Docs .

...