project.json's version property should be extensible

[muratg]

From @AArnott on November 18, 2015 0:1

We want the libraries and packages we build with DNX to be stamped with a version as unique as the source code. And we want semver to roughly understand (assuming linear versioning) how to pick newer packages from older ones independent of a particular build server. We want reproducible builds, such that if I build a commit locally or in the cloud, the result is exactly the same, including the version that is calculated that is stamped onto the package and the assembly.

We also want to be able to backtrack from an assembly or package version to the source code that produced it.

This is encoded in Nerdbank.GitVersioning but this extends MSBuild to work its magic. DNX doesn't use MSBuild so we need another way to influence where DNX gets its package versions, and the several assembly versioning attributes it produces while compiling. I'd love for this Nerdbank.GitVersioning package to be applicable to DNX projects via adding as a dependency and have it automatically work with DNX to get the version right.

Copied from original issue: aspnet/dnx#3178

[muratg]

From @davidfowl on November 24, 2015 7:5

You could just use assembly attributes for this. Specifically [AssemblyMetadata]

[muratg]

From @AArnott on November 24, 2015 16:22

I don't think that resolves the issue. The values for these assembly metadata need to be computed at build time, and DNX (AFAIK) doesn't offer me a way to hook into that pipeline.
Also, that doesn't address the NuGet package version.

[muratg]

From @guardrex on November 24, 2015 17:10

@AArnott You can script your way to a new version for each publish operation. You can run a PS script on "prepare" and provide whatever versioning logic you want. I needed a new patch version for each publish, so I whipped this up: https://github.com/GuardRex/net5-autoupdate-version

[muratg]

From @AArnott on November 24, 2015 17:44

Thanks, @guardrex. But that requires a source code change to impact the build. Then to ensure the number keeps incrementing you have to check in the change. What I'm looking for is automation that can control the version without changing source code every time I build or publish.
And I want build and publish to be effectively the same thing. Every time I build a commit, the result should be the same, regardless whether it's a CI build, a local build, or a release build.

[PhilipDaniels]

@muratg can you take a look at my comment on https://github.com/dotnet/cli/issues/549 and let me know if that does what you want? Making it possible for developers to make proper local builds that look just like CI builds was one of my aims.

[AArnott]

@PhilipDaniels This is actually my (@AArnott) issue, but @muratg copied it from a deprecated project.

And no, #4608 doesn't come close to what I want. I don't want to have to make a commit in a git repo (or otherwise change any source code) in order to build a package with a different version number than the prior commit in git. I don't want to keep having to increment a patch version in project.json with every commit that I build. Besides adding tons of noise and overhead, it would introduce merge conflicts between branches that change the value.
The extensibility that I'm asking for lets me do much more powerful things with versioning, like adding git commit ID to the version, etc.

[TheRealPiotrP]

@AArnott take a look at the CLI repo itself. It implements a particular versioning strategy and uses existing --version-suffix capabilities to have that strategy respected throughout the CLI repo. If you think that there are better hooks to be exposed by CLI to enable other versioning strategies, perhaps you can suggest a design along with scenarios that it would address?

[AArnott]

I just looked into that. The --version-sufix switch doesn't appear any more flexible at least at first glance than the DNX version support was.

For instance, I set my project.json version field to "1.0.*". Then I tried to build and specify the rest of the version at the command line:

> dotnet build --version-suffix 124.32-pre
'1.0.*' is not a valid version string.
Parameter name: value

The position of the asterisk, and what values are allowed to be substituted in where the asterisk is, is extremely limited. Even if where it could appear can be expanded, having to specify the version to substitute in for each build is very burdensome. A proper build extension could automatically calculate the appropriate version on every build automatically.

Also, there are multiple aspects to versions. There is package version, assembly version, assembly file version, etc. All these have their purpose and while corefx uses the same (or similar) version everywhere, a great many projects don't. Flexibility in this area is important, especially for desktop CLR targeted projects. You can see some of the flexibility folks require in the version.json that NB.GV supports.

I think I read recently that dotnet CLI is adding some support for development/build dependency packages in project.json. I might have misinterpreted it, but it seemed like a great place to add a build extension. Ideally, I can adjust the NB.GV nuget package to also export whatever extensions it needs to plug into dotnet.exe so that it can supply all the version information, add source files to the compilation, etc. that it needs to so that people who migrate from msbuild to dotnet CLI can continue to have the automatic and flexible versioning policies that they are used to.

[RehanSaeed]

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

[TheRealPiotrP]

The team is actively working on enabling MSBuild and the component affected will be superseded by the new project system, so I am closing this issue.