Getting the version (patch) incremented prior to build/publish

[muratg]

From @guardrex on November 26, 2015 20:39

The version that matches what we'll see in VS published output matches the version in project.json, so starting with ...

"version": "1.0.9"

... will lead to folder named 1.0.9 in <output_folder>/approot/packages/<project_package>.

If I establish a PS script that would modify the project.json version and run that script in prepare or build ...

"scripts": {
  "prepare": [ "powershell.exe -ExecutionPolicy ByPass -file %project:Directory%/net5-autoupdate-version.ps1" ]
},

... it does increment the version in project.json, but it does so after the build/publish. The version showing in project.json at that point is always one patch number higher than the actual version in the package that I'm publishing. I have the same outcome if I try to hook the script in the vsweb-publish script prior to the Publish-AspNet command.

Is there a way to (or a tip to) auto-increment the project version (patch) when publishing, preferably with a version (patch) number in project.json that matches the package version (patch) in the output folder?

Copied from original issue: aspnet/dnx#3209

[muratg]

From @guardrex on December 18, 2015 1:28

In case anyone is looking for it, my (crappy) version updater is here ... https://github.com/GuardRex/net5-autoupdate-version ... just don't get your hopes up too much. It's a bit of a stinker. 💩

[CoskunSunali]

@muratg Could you/someone possibly implement an official way of automatically incrementing the patch version "on demand" without a PS script or something while fixing the mentioned problem?

I quoted "on demand" because I know not everyone would like the patch number to increment at all times.

[PhilipDaniels]

I've been looking into this because I have been looking to improve the efficiency of our build systems at work. The conclusions I have come to is that it is best to have little utility programs to do what you need and then glue them together with a PowerShell script. The question is how to make it as easy as possible, and for me, I needed to support legacy (csproj) projects too. I was inspired to start by how easy it is to build a nupkg in the new .Net Core world, however, I have also come to the conclusion that you do not want to do that on every build, just because it slows things down.

Anyway, I have written a couple of command line exes, dnv.exe and updeps.exe. dnv allows you to set version numbers (using increments, timestamps, git commit shas, environment variables etc.) in both old and new style projects. updeps is a simple tool to update the dependencies node in a nuspec file. It's not needed for project.json projects.

They are available at https://github.com/PhilipDaniels/dotnetversioning You can just download the zip to get started, no config file is necessary.

Check out the usage.md for dnv.exe to get an idea of what is possible, I have also made 3 example projects which use the programs in different way - see the PowerShell scripts in the root of each example folder.

Interested in the team's thoughts...if you think there is mileage in integrating dnv into the core cli offering I would be willing to do that work, though I know you have said you are no longer accepting new commands at the moment.

[TheRealPiotrP]

@PhilipDaniels that sounds interesting. Can you take a look at http://dotnet.github.io/docs/core-concepts/core-sdk/cli/extensibility.html? It would be great to have these tools available as dotnet extensions!

[RehanSaeed]

NPM has the version command which lets you bump up each number. Having the same for dotnet would be great.