Управление версиями nuget от бета-версии до выпуска в VS2017 для .net core2.1 при создании конвейера в Azure Devops

Question

Мне нужно создать пакет nuget для .net core 2.1 как часть процесса сборки и выпуска в Azure Devops. Что я хотел бы сделать

1) В разделе сборки соберите проект, а затем добавьтескомпилированный код для артефакта

2) В определении Release будет 2 развертывания, одно для бета-версии, где версия будет похожа на 1.2.3-Beat.2, и push-to-azure артефакт nuget, а другое развертывание для выпуска, где версиябудет похож на 1.2.3.2 и push to azure nuget артефакта.

В настоящее время у меня есть только одно определение сборки, которое будет собираться (пакет nuget создается в процессе сборки) и push to azure артефакт nuget.

Трубопровод, который я хотел бы создать

Answer 1

Используйте задачу dotnet pack с параметром --no-build, а на этапе подготовки к выпуску установите значение VersionSuffix .

Примечание. Моя текущая команда использует набор Powershellскрипты для добавления данных номера сборки к данным Major.Minor, найденным в .csproj (или AssemblyInfo.cs для netFramework), но это не меняет ответа на ваш вопрос.Как только вы выясните, какими будут данные Major.Minor.Patch [.Build], вы можете использовать свойство VersionSuffix в задаче dotnet pack с --no-build, чтобы сообщать о качестве пакета какон движется по вашему конвейеру.

Учитывая файл .csproj, который выглядит следующим образом:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>
  <PropertyGroup>
    <PackageVersion>1.0.0.1</PackageVersion>
    <AssemblyVersion>1.0.1812.201</AssemblyVersion>
    <FileVersion>1.0.1812.201</FileVersion>
  </PropertyGroup>
  <ItemGroup>
    <Content Include="Assemblies\*">
      <Pack>true</Pack>
      <PackagePath>lib\$(TargetFramework)</PackagePath>
    </Content>
  </ItemGroup>
</Project>

Опять же, еслимы игнорируем используемый шаг контроля версий, задача dotnet pack на изображении конвейера выше создаст пакет с версией 1.0.0.1-Beta.

Затем на этапе стабильной версии не устанавливайте значение суффикса и дайте пакету получить свою версию из файла .csproj, как обычно (например, 1.0.0.1).

---

Элементы и значения в приведенном выше примере файла .csproj могут быть записаны как прямые правки в .csproj или их можно установить с помощью вкладки Свойства >> Пакет .

Если значения не изменяются в меню свойств или добавляются явно, элементы и значения не отображаются в .csproj и предполагаются командами dotnet build | test | pack .

---

Найти правильную комбинацию этих свойств и значений может быть непросто, если вы не знакомы с их сочетанием.Я нашел эту статью полезной при попытке расшифровать свойства версии.

Кроме того, вы должны понимать 1.0.1-b2 <<code>1.0.1, поэтому ваша предварительная версия может быть 1.2.3.2-beta1 иВаша стабильная версия будет 1.2.3.2.

---

Answer 2

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

Что может быть интересным в вашемcase использует концепцию представлений в артефактах Azure, это позволит вам перевести пакет в представление выпуска в более позднем состоянии без необходимости перестраивать пакет.На торговой площадке есть отличное расширение, которое позволит вам сделать это из релиза: https://marketplace.visualstudio.com/items?itemName=rvo.vsts-promotepackage-task

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

Недостатком этого является то, что Nuget не идентифицирует пакеты как предварительные версии, так как вы не будете упаковывать их с соответствующим semver для этого