在Azure Devops中建立管道时，管理nuget版本从Beta到VS2017 for .net core2.1中的版本

Question

在Azure Devops中，我需要为.net core 2.1创建nuget程序包，作为构建和发布过程的一部分 我想做什么

1）在构建部分中构建项目，然后将编译后的代码添加到工件中

2）在“发行版”定义中，将有2个部署，其中一个是Beta版，其版本将类似于1.2.3-Beat.2，并推送到天蓝色的nuget，而另一个版本将发布，其版本将类似于1.2.3.2和。推到天蓝色的人造物小块。

目前，我只有一个构建定义可以构建（在构建过程中创建了Nuget包）并推送到天蓝色工件nuget。

我想创建的管道

Answer 1

由于在执行“ nuget pack”时通常会包含软件包的版本（通常在构建过程中会执行该版本），因此以后更改该版本可能会变得有些复杂。

在您的情况下，可能有趣的是使用Azure Artifacts中的视图概念，这将使您可以在以后的状态下将程序包升级到发布视图，而不必重建程序包。 市场上有一个不错的扩展，可让您从一个发布版本中进行操作：https://marketplace.visualstudio.com/items?itemName=rvo.vsts-promotepackage-task

使用此流程，只要您愿意，就可以在预发布视图/提要中包含这些程序包，并在合适时在发布视图中使它们可用。

缺点是Nuget不会将这些软件包标识为预发行软件包，因为您不会使用适当的semver对其进行包装

Answer 2

将dotnet pack任务与--no-build选项一起使用，并在发布前的阶段中设置 VersionSuffix 值。

注意：我目前的团队使用一组Powershell脚本将内部版本号数据附加到.csproj（或netFramework的AssemblyInfo.cs）中找到的Major.Minor数据，但这不会改变问题的答案。一旦确定了Major.Minor.Patch [.Build]数据的内容，就可以在dotnet pack任务中将 VersionSuffix 属性与--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的软件包。

然后在稳定的发布阶段，不要设置后缀值，而应像正常情况（例如1.0.0.1）那样，让软件包从.csproj文件获取其版本。

---

上面的示例.csproj文件中的元素和值可以直接编辑为.csproj，也可以使用 Properties >> Package 标签设置。

如果未在属性菜单中更改值或未明确添加值，则元素和值不会出现在.csproj中，并由 dotnet build | test | pack 命令假定。

---

如果您不熟悉如何将这些属性和值组合在一起，那么找到它们的正确组合可能会令人生畏。尝试破译版本属性时，我发现this article很有用。

此外，您应该了解1.0.1-b2 <1.0.1，因此您的预发行版本可能是1.2.3.2-beta1，而稳定版本将是1.2.3.2。

---