Make dotnet pack usage more CI / build system friendly

[fubar-coder]

Steps to reproduce

Assume, that have a project.json with a version placeholder (e.g. 1.0.0). It would be nice, if there would be a way for a CI system (like TeamCity) to update this version number without requiring the usage of regular expressions.

Expected behavior

One or more of the following:

• Support for $version$ as version value.
• Support for --version parameter

The $version$ would get replaced by the version of the AssemblyInformationalVersionAttribute or (when the former is missing), the value of the AssemblyVersionAttribute. The --version parameter would enforce the usage of the given version (and thus overriding the found assembly version).

Actual behavior

dotnet pack uses the version from the project.json and the CI system (like TeamCity) must patch the project.json, which is error prone, because it must not update the version values of dependencies.

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-rc2-002485)

Product Information:
 Version:     1.0.0-rc2-002485
 Commit Sha:  d3c65aee87

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10586
 OS Platform: Windows
 RID:         win10-x64

[TheRealPiotrP]

@yishaigalatzer @emgarten can you guys comment on this? We want to be sure that dotnet pack is consistent with the nuget behavior.

[smbecker]

You can use environment variables like you could with DNX: https://github.com/dotnet/cli/blob/rel/1.0.0/src/Microsoft.DotNet.ProjectModel/ProjectReaderSettings.cs

[yishaigalatzer]

There is no point in investing in dotnet pack. We are retiring it right after rc in favor of nuget pack

[yishaigalatzer]

I do agree with the ask, but there is strong pushback to add replacement parameters to project.json. the package version is easy, it is the dependencies that get super tricky and it leaks into restore

[fubar-coder]

@smbecker Using DOTNET_BUILD_VERSION is not a solution, because it's for the version suffix, and not for the version itself
@yishaigalatzer What is the proposed solution for setting the version from the CI system? What happens with the restore/build when a different version is specified during nuget pack?

[yishaigalatzer]

There are two discussions going on, I have an answer for one at the moment (which is current pack is going away).

As for your other question (control version on CI) there is no answer yet. I do agree it is a problem that needs resolution. Still debating the design with various team members.

The scenario to keep in mind is as such:

Project a references project b, both of them produce packages.

Hence the version of project b affects packing of project a, which means that we can't just solve this problem at the pack level (since restore treats projects and packages as interchangeable)

[PaulTrampert]

Realize this is an older issue - but as a workaround, I build a custom dotnet-version command, found here: https://github.com/PaulTrampert/dotnet-version/

Just import it in the tools section of your project.json (it's available on nuget), and call it with dotnet version <your_version>. This has to be done from the project directory though - can't figure out how to get it to work from solution root.

[TheRealPiotrP]

This is now fixed, since Pack is driven by csproj file which can easily include parametarized properties.

[tpluscode]

@piotrpMSFT so how does one pass build parameters to dotnet pack command?

[conniey]

@tpluscode https://docs.microsoft.com/en-us/nuget/schema/msbuild-targets An example is:

dotnet msbuild .\GitVersionTask.csproj /t:Pack /p:PackageVersion=1.2.0-alpha

[ardalis]

So the solution is to not use dotnet pack, but instead use dotnet msbuild ?

[conniey]

@ardalis

If the arguments available through dotnet pack are not sufficient for you, then you would use dotnet msbuild. For example, if all the information is specified in the csproj, and you don't need to modify anything other than the build configuration then dotnet pack -c Debug would be fine.

dotnet pack --help
.NET Core NuGet Package Packer

Usage: pack [arguments] [options] [args]
... other stuff ...
Additional Arguments:
Any extra options that should be passed to MSBuild. See 'dotnet msbuild -h' for available options.

[ardalis]

My goal is to specify the version number, completely (not just a suffix). This would be from a CI build, so the easiest thing is to specify a version in the build configuration as something like 1.0.{0} and have it replace the last number with the build number. Is there any way to specify the version via dotnet pack that I'm not seeing (or another way to do what I'm looking at doing)?

[dasMulli]

@ardalis You could introduce an msbuild property for your build number as such:

  <PropertyGroup>
    <BuildNumber Condition=" '$(BuildNumber)' == '' ">0</BuildNumber>
    <Version>1.2.$(BuildNumber)</Version>
  </PropertyGroup>

$ dotnet pack /p:BuildNumber=34
Microsoft (R) Build Engine version 15.1.548.43366
Copyright (C) Microsoft Corporation. All rights reserved.

  foo -> /Users/martin/foo/bin/Debug/netstandard1.4/foo.dll
  Successfully created package '/Users/martin/foo/bin/Debug/foo.1.2.34.nupkg'.

[tpluscode]

@ardalis I have since learned that /p:Version=1.2.3 does indeed work with dotnet pack. Not only dotnet msbuild

[conniey]

Browsing through the code, the command dotnet pack just forwards the argument /t:pack to msbuild. It all makes sense now. :D PackCommand.cs L31-34

[derekgreer]

Okay, so this works:

dotnet msbuild *.sln /target:Clean;Build /p:Configuration=Release /p:Version=2.0.0

Is this is official Microsoft recommendation for specifying the version number via CI build?

[shoff]

https://github.com/dotnet/cli/issues/2676#issuecomment-214938537

That comment didn't age very well.