sdk: dotnet build --version-suffix not working?

Steps to reproduce

project.json has the following version number :

{ "version": "1.1.0-beta-*" }

The following C# snippet I use for retrieve the version number :

public class Program { public static void Main(string[] args) { var versionInfo = (typeof(Program) .GetTypeInfo() .Assembly .GetCustomAttribute(typeof(AssemblyInformationalVersionAttribute)) as AssemblyInformationalVersionAttribute)?.InformationalVersion; Console.WriteLine(versionInfo); } }

After this I build with the following cli command :

dotnet build --version-suffix 1234

But the output of the programm would only “1.1.0-beta” without the suffix ? What did I miss?

Expected behavior

Output ‘1.1.0-beta-1234’

Actual behavior

Output ‘1.1.0-beta’

Environment data

`.NET Command Line Tools (1.0.0-preview2-003121)

Product Information: Version: 1.0.0-preview2-003121 Commit SHA-1 hash: 1e9d529bc5

Runtime Environment: OS Name: Windows OS Version: 6.1.7601 OS Platform: Windows RID: win7-x64`

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 20 (9 by maintainers)

Most upvoted comments

@NickCraver Try this in your csproj-file:

<VersionSuffix>$(VersionSuffix)</VersionSuffix>
<Version>1.0.6</Version>
<Version Condition=" '$(VersionSuffix)' != '' ">$(Version)-$(VersionSuffix)</Version>

This way people can set the Version-property through the Visual Studio UI and if you supply a VersionSuffix it still gets appended.

+44

mloeffen on May 4, 2017

@dasMulli After posting this, I dug in and realized the same: <Version>4.0.0</Version> with --version-suffix doesn’t work. That’s not intuitive, IMO. It’s a suffix, meaning it gets appended to the end…that’s the meaning of the word. Intuitively, I would expect the <Version> + <VersionSuffix> to work, or error when both are supplied since won’t work, due to it being unintuitive.

I think <VersionPrefix> is not the correct name, it’s really <VersionNumber> given the behavior.

I have moved to <VersionPrefix> in my projects, but it’s not a great. For example, if a user edits the Version through the UI (just once), that changes the .csproj from <VersionPrefix> to <Version> (both are there, but <Version> trumps), and all the build arguments just stop working. I just don’t agree with the current behavior, it defaults to failure and releasing not-ready code in several unintuitive and accidental cases.

As a practical impact: I will now have to make sure in every PR that no one used the UI to edit the version number in order to bump it (as one would intuitively do), since that will break all of my versioning until fixed.

+22

NickCraver on Mar 18, 2017

just stumbled across this and I wanted to say that the current state of the documentation is certainly not clear. I’ve been reading https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-build?tabs=netcore2x and there was no mention of <VersionPrefix> even though it tells you to us --version-suffix. I’ve been trying to set ‘*’ in Version and AssemblyVersion but that just errors. This thread has given me more info than I found anywhere else and that’s probably not a good thing.

+11

ormico on Oct 26, 2017

Found the answer at https://github.com/dotnet/cli/issues/5568#issuecomment-278565824. This works:

dotnet pack -c release --include-symbols -o ../bin /p:Version=1.2.3-betaABC

You should just remove the --version-suffix option which is no longer working.

ctaggart on Feb 18, 2017

After many iterations of trial and error, the following command worked for me:

dotnet build -c release --version-suffix "ci.4" -p:VersionPrefix=1.2.3-alpha1 -p:FileVersion=1.2.3.4

It produced a nuget package called R4Mvc.1.2.3-alpha1-ci.4.nupkg, and put the version numbers into the built DLLs:

I wouldn’t call that combination of arguments intuitive!

kevinkuszyk on Jun 8, 2017

@NickCraver What exactly doesn’t work? Setting the VersionSuffix msbuild attribute should affect assembly info generation on build and nuget package version on pack. The two bugs I’m currently aware of:

Packing multiple projects only affects the package version but dependency versions of referenced projects aren’t updated https://github.com/NuGet/Home/issues/4337
Changing version arguments between multiple builds will not update the generated AssemblyInfo https://github.com/dotnet/sdk/issues/967 (just opened a PR for it)

There are a few things to consider:

If <Version> is set in the project file, this will not allow the use of a version suffix. => Set <VersionPrefix>1.2.3</VersionPrefix> to only specify the version number. The SDK will then create a Version property based on VersionPrefix and VersionSuffix: https://github.com/dotnet/sdk/blob/5d50497b550dbcbe972434c10fc2de4de71a8b94/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.DefaultAssemblyInfo.targets#L18-L22
If any property is specified on the command line, it will unconditionally override any change made to it in the project file. e.g. <VersionSuffix>$(BuildNumber)-$(VersionSuffix)</..> cannot override a version suffix passed in through the command line call.

dasMulli on Apr 4, 2017

Tangential, but this thread (@mloeffen especially) solved a major problem for me, and I think pointing it out might help others. We were using version to supply our major/minor, and want TeamCity to provide an auto-increment followed by the branch name for feature builds.

Unfortunately, the hardcoded ($VersionPrefix)-($VersionSuffix) does not allow for this, as we need a period separator rather than the dash. Based on the comments above here’s the solution I arrived at, to allow for supplying the revision/build number as a suffix:

<VersionSuffix>$(VersionSuffix)</VersionSuffix>
<VersionPrefix>0.131.337</VersionPrefix>
<Version Condition=" '$(VersionSuffix)' != '' ">$(VersionPrefix).$(VersionSuffix)</Version>
<Version Condition=" '$(VersionSuffix)' == '' ">$(VersionPrefix)</Version>`

Much appreciated, and hope this helps someone in the same boat!

vadian on Dec 13, 2018

@livarcocc @KathleenDollard can you please let me know where this stands and what are the changes I should make to the docs? Someone recently posted on the dotnet build article that they found the information they were looking for here and that our docs are outdated.

mairaw on Mar 2, 2018

I hit this today, is this a bug in code or documentation? Should it just be removed from the CLI? A break would be better than silence here, since the failure case improperly releases alpha/beta/etc. code as release quality.

/cc @terrajobst

NickCraver on Mar 18, 2017