[Bug] GitVersion.MsBuild and gitversion/execute@0 task produce different NuGet package versions

[ThomasBarnekow]

Description

Trying to find a way to produce NuGet packages with Azure pipelines in a Continuous Delivery mode, I tested different approaches:

• gitversion.tool with the gitversion/setup@0 and gitversion/execute@0 tasks in azure-pipelines.yml vs.
• GitVersion.MsBuild without the above two tasks in azure-pipelines.yml.

In both cases, version 5.8.1 is used with the following GitVersion.yml file:

assembly-versioning-scheme: MajorMinorPatch
mode: ContinuousDelivery
next-version: 2.0.0
branches: {}
ignore:
  sha: []
merge-message-formats: {}

The azure-pipelines.yml file looks like this:

trigger:
  branches:
    include:
    - main
    - feature*

pool:
  vmImage: windows-latest

variables:
  buildConfiguration: 'Release'

steps:
# The following task does not exist in case GitVersion.MsBuild is used
- task: gitversion/setup@0
  displayName: 'Set up GitVersion'
  inputs:
    versionSpec: '5.x'

# The following task does not exist in case GitVersion.MsBuild is used
- task: gitversion/execute@0
  displayName: 'Execute GitVersion'
  inputs:
    useConfigFile: true
    configFilePath: 'GitVersion.yml'
    additionalArguments: '/updateprojectfiles'

- task: DotNetCoreCLI@2
  displayName: 'Build $(buildConfiguration) configuration'
  inputs:
    command: 'build'
    arguments: '-c $(buildConfiguration)'

- task: DotNetCoreCLI@2
  displayName: 'Pack NuGet packages'
  inputs:
    command: 'custom'
    custom: 'pack'
    arguments: '--no-build -c $(buildConfiguration) -o $(Build.ArtifactStagingDirectory)'

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)'
    artifactType: 'pipeline'
    artifactName: 'drop'

Let's now assume we run the above pipeline (with the two tasks) on the main branch and the FullSemVer and NuGetVersion values reported by the gitversion/execute@0 task are 2.1.3+3 and 2.1.3, respectively. The following version tag can then be found in the .nuspec file contained in the NuGet package:

    <version>2.1.3</version>

The above version 2.1.3 is exactly what I would expect. However, if I use the GitVersion.MsBuild NuGet package in the next pipeline run (without the two tasks), the corresponding version tag would be as follows:

    <version>2.1.3+4</version>

The issue here is that this is (a) not what I would expect and (b) different from what I get when using gitversion/execute@0.

As a side note (and potentially additional issue or bug), when using the DotNetCoreCLI@2 task to build the solution or project, I do not have access to the GitVersion variables e.g., $(GitVersion.FullSemVer) or $(GitVersion.NuGetVersion). If I remember correctly, I did have access to those variables when using the VSBuild@1 task in another pipeline.

Expected Behavior

Using GitVersion.MsBuild, the NuGet package version is in the format 2.1.3 and identical to what gitversion/execute@0 would produce.

Actual Behavior

Using GitVersion.MsBuild, the NuGet package version is in the format 2.1.3+4 and different from what gitversion/execute@0 would produce.

Possible Fix

Unfortunately, I don't have a fix.

Steps to Reproduce

1. Create a super-simple SDK-style C# project (I'm targeting net50 in mine) with a single class and the above GitVersion.yml and azure-pipelines.yml.
2. Run the pipeline and check the version value in the .nuspec file contained in the NuGet package produced by the pipeline run.
3. Install the GitVersion.MsBuild NuGet package and uncomment the two gitversion tasks in azure-pipelines.yml.
4. Run the pipeline again and check the version value in the .nuspec file contained in the NuGet package.

Context

As I said above, I am trying to produce NuGet packages in a Continuous Delivery mode. I've spent a ton of time trying to find out how to make this work, because GitVersion.MsBuild does not produce the expected NuGet package versions. It seems that the gitversion.tool is the way to go (as it also updates the build number, which GitVersion.MsBuild does not do).

Your Environment

• Visual Studio 2019 on Windows 10
• Azure DevOps with Azure Repo and Azure Pipelines
• Option 1: GitVersion.MsBuild version 5.8.1
• Option 2: gitversion.tool version 5.8.1

[asbjornu]

If GitVersion.Tool gives you the version number you want, why do you want to use GitVersion.MSBuild? You can try to configure the MSBuild task. Setting UseFullSemVerForNuGet to false should yield a version number without the build metadata (+4).

[ThomasBarnekow]

@asbjornu, I had been using the GitVersionTask for quite some time. When you deprecated it, the natural move was to use GitVersion.MsBuild. This, however, did not yield the expected results. Therefore, I tried the GitVersion.Tool, which did produce the expected results. This is somewhat puzzling.

Since the difference between those two options might not be what you guys intended, I filed an issue.

[asbjornu]

I see @ThomasBarnekow. I agree the behaviour should be consistent. If you find the inspiration to submit a pull request to fix this, please do.

[ThomasBarnekow]

Thanks, @asbjornu, I will unfortunately not have the time to do this. However, I hope that my detailed description of the issue is still helpful.