[Question] Externally providing version for dnu pack?

[roji]

Apologies if this has been answered/discussed.

I am looking for a way to create nuget packages of my project with dnu pack, but with an externally-provided version (instead of the one specified in the project.json). The use-case is a tool like GitVersion, which automatically determines the version from gitflow; it is executed at the build server, setting some variables for versions which should later be used when creating the nuget package. When creating nugets in the old way (nuget pack) the -Version switch does this work.

On a very related note, we also need some way to access this version variable from within the project.json when specifying dependencies on other packages. The scenario is multiple nugets created from the same repository, with automatic dependencies between them on the exact version as derived from gitflow. In the old way the nuspec could simply contain $version$.

[davidfowl]

Today we do this but only with the prerelease suffix. You can make a project.json that looks like:

{
   "version": "1.0.0-*"
}

If you set the DNX_BUILD_VERSION environment variable, it'll replace the -* with -{DNX_BUILD_VERSION}. This is how we're producing our builds. We set DNX_BUILD_VERSION to the team city build number.

[roji]

Thanks for the quick answer.

Any plans to make this work with the version itself and not just the prerelease? My current situation is that I can bump patch, minor and even major versions simply by performing git operations (and not modifying a single nuspec or AssemblyInfo.cs). I think it's important not to lose this capability in DNX...

[davidfowl]

There are not plans currently to make this work. Is this a CI scenario or mostly just how things are controlled in general?

The scenario makes sense and I'm not opposed to bring back the version replacement token. I do have some questions about how that works with project references:

• Are you versioning the entire solution with the same version?

[roji]

Well, it's how things are controlled in general, although the logic is important mainly for the CI (versions don't matter much for local developer builds, at least in my setup).

Normally when you go with an automated GitFlow-based versioning scheme (à la GitVersion) yes, you're constrained to the entire solution being versioned with the same version; this is a simple consequence of the version being derived from your git branch (develop, master).

Of course other scenarios exist out there for deriving versions; some people store the version in some arbitrary text file and read that as part of the build. This allows you to manage different versions for individual projects within the same solution. IMHO the important thing is to make any versioning scheme possible by allowing a full environment variable plus replacement token.

I'd be happy to provide any other details you're interested in.

[davidfowl]

I know you're asking for a feature that exists in NuGet but I still want to understand the scenario better because in practice things are usually only used in a few ways. That's not an excuse for removing features, it's a way to figure out what a better workflow would be in the common case. For example, we're looking at a feature to enable specifying the version in global.json so that you can version projects under that global.json with a single version.

The reason we only supported replacement for the pretag is exactly what you said, usually on the CI is where you bump versions. Our local build scripts actually use it the same way, when you build, we generate a timespant t{current date as a long} for your package version.

That said it's pretty important to be able to pass any initial version as input to the build. We'd want to allow that for global.json if we did that feature as well.

[roji]

The global.json-specified feature sounds like a good idea (regardless of allowing an external version from an environment variable). All the rest sounds good too.

My basic need in life is to be able to never touch (and commit) any file as part of a version bump operation, any scheme allowing that would probably be OK. I imagine that the easiest way to support this is probably via an environment variable that gets set by a tool such as GitVersion...

[davidfowl]

Sounds good, care to do a pull request? The relevant code is here https://github.com/aspnet/dnx/blob/dev/src/Microsoft.Framework.Runtime/Project.cs#L186

[roji]

Sure, I'll be happy to contribute on this, but here are some design questions:

• Should the DNX_BUILD_VERSION envvar now simply contain an entire version (e.g. 2.2.0-rc1) rather than just the prerelease component now? Or should we have two schemes (i.e. one envvar for the prelease component only, like now, plus a new envvar for the entire version which would take precedence if defined)? Two schemes sounds like too much to me but anything currently using 1.0.0-* would break otherwise.
• Maybe consider renaming DNX_BUILD_VERSION to DNX_VERSION (the other envvar, DNX_ASSEMBLY_FILE_VERSION, doesn't have a BUILD prefix in it).
• Regarding the version substitution token: should it be $version$ like in today's nuspec?
• Should it be possible to place the version substitution token anywhere in the project.json or only in dependency version fields?
• In addition to the envvar, should we also make available a command-line switch to dnu pack, like nuget pack?

[roji]

Any ideas on the questions above?

[Tasteful]

@davidfowl @roji Any news about this request?
In my situation I have about 20 projects in the solution that all should have the same version number when it is built so any progress regarding this will be lovely.

[MiguelAlho]

Something that comes to my mind when considering this situation:

I'm a fan of the global version for the solution - normally changes are done in the context of a solution, builds in CI are in the solution's context, etc. So versioning at the solution makes it easy to relate changes to the set of projects as a cohesive unit. Cognitive load is reduced when managing the dependencies. Nonetheless, by changing at the solution level, we are breaking the version changes' meaning at specific projects. If a specific project has no changes, should the output assembly / package have a new version? If it is acceptable, and I can comprehend that a dev or team may accept this, then some packages simply will have version changes without having any internal change (possibly not even dependency changes). The benefit (and option) of having this may outweigh the loss of coherent semantics in the version number alterations.

Also, as somewhat mentioned in @roji 's original post, the version number in the global.json should establish the minimum version number for package dependencies that is generated within the solution. This would be so that nuget version resolution can correctly update all the dependencies (especially all those generated in the same solution) when any package update is performed in other solutions. I've had multiple problems of this sort in projects (generate stuff from one solution, then update packages in another, but guaranteeing that all have consistent dependencies), and i believe should be taken into consideration.

[roji]

@davidfowl, @glennc or others, can we have a quick discussion on the design questions I asked above? After that I can work on a PR.

[xanather]

Is there any chance this could get looked at @davidfowl or anyone who works on DNX?

[davidfowl]

Sure @glennc can we setup a design meeting for this?

[roji]

If you guys need any more input on usage scenarios etc. let me know!

[roji]

Here are some input thoughts on what is needed and how to achieve it. Some common versioning scenarios (bumping refers to all version bumps, not just prerelease tags):

• Manual version bumping per project: update each project.json's version by hand (currently supported)
• Manual version bumping for all projects in a solution: update global.json by hand once
• Solution-wide automated versioning (e.g. GitVersion): external program determines the version (from git branch or other). Should be able to pass a cmdline switch to dnu pack for this (and also possibly an environment variable). Note that GitVersion also takes care of automatically setting the value of the AssemblyVersion attribute (and related).

Here's a proposal for supporting the above requirements, ordered by descending priority:

• If a -Version cmdline switch is passed to dnu pack, use it
• If a DNX_VERSION environment variable exists, use it
• If a version is defined in the global.json, use it
• If none of the above was satisfied, use the version in the project.json (or emit an error if one was not defined)

dnu currently supports a half-half model, where the base version is manually-defined in the project.json, and the prerelease is passed externally through the DNX_BUILD_VERSION environment variable. This can be maintained via a DNX_PRERELEASE_VERSION environment variable (and possibly command-line switch), although it may be sufficient to simply allow the entire version to be externally-determined as proposed above (discarding the half-half mode).

Note that there should also ideally be a way to refer to the global.json version when specifying versions of dependencies. This is important for creating same-version dependencies between projects of the same solution (as mentioned above).

[pranavkm]

Should the variable be named DNX_ASSEMBLY_VERSION? DNX_VERSION sounds like something you'd use to specify the DNX version, not the application being built.

[roji]

@pranavkm good point. DNX_ASSEMBLY_VERSION sounds a bit misleading to me since it seems to imply that the AssemblyVersion attribute is affected, which I don't think is the case (that could be a feature on its own). Maybe DNX_PROJECT_VERSION...

[pranavkm]

DNX_PROJECT_VERSION sounds good to me.

[RichiCoder1]

Bump! I have a similar issue now.

[TerribleDev]

👍 I would most certainly enjoy this feature

[roji]

@glennc @davidfowl any progress on this?

[RehanSaeed]

+1 for @roji's latest list of requirements. Would really like to build projects in a CI scenario and it's not currently as easy as it should be.

[RehanSaeed]

Has anyone been able to get the DNX_BUILD_VERSION environment variable to work from @davidfowl's comment? Here is my PowerShell script:

# Continuous Integration server passes version into the PowerShell script.
$version = $args[0]

[Environment]::SetEnvironmentVariable("DNX_BUILD_VERSION", $version, "User")

dnu restore Source\MyProject\project.json
dnu publish Source\MyProject\project.json --configuration Release --include-symbols --no-source --out artifacts

I'm still getting my .nupkg files output with a 1.0.0 version on Beta 8.

[roji]

@RehanSaeed, don't forget the version in your project.json must contain "1.0.0-*" for the DNX_BUILD_VERSION to be taken into account.

[RehanSaeed]

@roji I've done that, it's the default anyway:

{
  "version": "1.0.0-*",
  ...
}

[muratg]

This issue was moved to dotnet/cli#571

[IEvangelist]

👍