4

Technologies:

Proget – Nuget Package management server

TFS – On premise 2017 Update 1

Issue: When re-releasing a build from TFS release, to re-package a CI Nuget package that has already gone to my Proget development feed, there does not appear to be a way to get automatic Semantic versioning. The help dialog that appears in regards to setting the version within the Nuget packager setup is as follows.

Use Date and Time If you choose 'Use the date and time', this will generate a SemVer-compliant version formatted as X.Y.Z-ci-datetime where you choose X, Y, and Z.

Use an Environment Variable If you choose 'Use an environment variable', you must select an environment variable and ensure it contains the version number you want to use.

Use the Build Number If you choose 'Use the build number', this will use the build number to version you package. Note: Under General set the build format to be '$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)

enter image description here

I’d like to be able to re-release a Nuget package that has gone from my CI build in TFS to my Proget development feed, over into my production Proget feed. Microsoft has a great article on Versioning NuGet packages in a continuous delivery world. In that article they elude to the fact that they are doing something similar, but they aren’t providing any real direction for how it was accomplished.

Question:

How would you configure the Nuget packager so that upon creating the package you would input a build variable? Or is there a way that you could set the major version and just have the minor increment each time? How are others handling the promotion of packages from development to production?

Have tried the following:

Tried $(Version) as a build & release variable, and it doesn’t seem to work. The package gets tagged with the date. Also, this only seems to be really functional in the Build portion of TFS where the modal window contains a spot to modify this value.

Tried using the date & time method, and it sticks CI into the build number. This is almost exactly what we want minus the CI definition. Because it automatically inserts CI, this is not suitable for production.

Turned it off and it pulls the version from the Nuspec, but then this would assume that in your CI build you are always upping the version number to one more than current after you have pushed your last release version. This is because the nuspec is in the build files that you are re-releasing through the TFS release chain. Confusing to say the least.

Use the build number set to $(BuildDefinitionName)$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r) What I’d like here is $(Major).$(Minor).$(Patch). Trying $(Version)$ with a version of 1.0.0 gets you a file named with that has 2017.11.3.1 as the output, seemingly ignoring the $(Version) variable.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
GetFuzzy
  • 2,116
  • 3
  • 26
  • 42

1 Answers1

0

Not sure if I totally got your point, seems you would like to create a semantically versioned nupkg after ci process on TFS.

Usually the nupkg should be as shown MSVersioningSample: 1.0.8-ci-20171106-156033.nupkg

However you would like to rename nupgk and republish it to nuget server as the release version simply MSVersioningSample: 1.0.8.nupkg The same as $(Major).$(Minor).$(Patch).

You need to edit NuGetPackager.ps1 in the build agent, change the $VersionRegex value, details you could have a look at the answer in this question: How do I get TFS 2015 to parse 3 digit versioning for NuGet packaging

Also give a try with some 3-rd party extension to handle with Semantic Versioning in TFS build, release task, nuget package, a sample for your reference: Semantic Versioning Build and Release Tasks

Besides just a note: Semantic Versioning 2.0.0 is only supports with NuGet 4.3.0+ and Visual Studio 2017 version 15.3+.

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
  • 2
    Turns out we can almost do what we want, but it's still a giant pain. We are reverting to using post build process within the solution file to trigger our builds for the production package feed. – GetFuzzy Nov 16 '17 at 14:16
  • @GetFuzzy Great to hear this, using a post build process within the solution maybe a little complex and cumbersome, but effective. Once your got a complete solution, you could share it here. – PatrickLu-MSFT Nov 16 '17 at 15:55
  • You can turn automatic versioning off and just provide this extra parameter on the PACK command. `Version=1.0.$(Build.BuildId)` – Piotr Kula Nov 06 '18 at 15:24
  • Would had been nice if the dotnet pack Task had an Output Variable for the version, now it requires a lot of pre work to set a variable in the build number and use that build number. Automatic package versioning is not effective. What about the Index Sources & Publish Symbols integration task? it requires a version as well... – rfcdejong Mar 19 '19 at 15:28