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

[stefc]

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`

[TheRealPiotrP]

The attribute is being tested in the Pack scenario only, today. Do you need it in build as well?

https://github.com/dotnet/cli/blob/6d57ca7e140f945f182b75a836ad2a0a86dcbd67/test/dotnet-pack.Tests/PackTests.cs#L87

[adamhathcock]

@piotrpMSFT --version-suffix is listed on the publish command as well and doesn't seem to work.

It's listed on build, publish, pack I think it should be on all of those commands, not just pack

Is the intent for it to only be on pack? I'd like to publish an app with versions too. Not just libraries.

[khellang]

Isn't it weird that pack does something else than build when it comes to building the actual assembly? I'd expect pack to call build (if needed) and that they'd behave exactly the same.

[adamhathcock]

I apologize. publish with --version-suffix does actually work for me. I was doing something stupid.

However, it is still listed on the build command so this issue still stands as before :)

[ctaggart]

The same command is working with 1.0.0-rc3-004530, but not 1.0.0-rc4-004771. I'm toggling between the two with global.json:

{
    "sdk": {
        "version": "1.0.0-rc3-004530"
        // "version": "1.0.0-rc4-004771"
    }
}

dotnet pack -c release --include-symbols -o ../bin --version-suffix b001

rc4 is not appending the suffix.

Feedback: It would be really helpful if I could set the entire version with dotnet pack, not just the suffix.

[ctaggart]

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.

[NickCraver]

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

[dasMulli]

@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.

[NickCraver]

@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.

[mloeffen]

@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.

[NickCraver]

@mloeffen setting a Version through the VS UI in a dozen places is definitely not a goal. We almost always want to set it in build tooling.

The current behavior isn't broken, but I do maintain it's unintuitive due to the property names. We've worked around it in our build setups everywhere already by generating Version externally and passing it in.

[dasMulli]

A hack would be to add a Directory.Build.targets file that re-sets Version and PackageVersion since it is imported after each csproj in the directories at/below it. But protecting from bad VS edits isn't really a good practice 😂

[kevinkuszyk]

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!

[ormico]

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.

[mairaw]

@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.

[sabbour]

This worked for me for .NET Core 2.0.5.

Code:

var assemblyVersion = System.Reflection.Assembly.GetEntryAssembly().GetCustomAttribute<System.Reflection..AssemblyInformationalVersionAttribute>().InformationalVersion;x
Console.WriteLine(assemblyVersion);

myproject.csproj

<PropertyGroup>
    <VersionPrefix>1.0.0.1</VersionPrefix>
</PropertyGroup>

publish using

dotnet publish  --version-suffix alpha

outputs

1.0.0.1-alpha

[nickw360]

@kevinkuszyk Looks like you are doing something similiar to me, for the CI suffix. I'm automatically setting the alpha / beta / rc suffix as well based on the GitFlow branch but how are you managing the SemVer? if you are setting the version using the build step are you extracting from the csproj or manually setting / incrementing parameters?

[kevinkuszyk]

@nickw360 how do? It's been a while!

I haven't looked at this for some time, but looking over the code it looks like we use the AppVeyor build number.

Have a look at our appveyor.yml and build log for an example.

HTH.

[vadian]

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!

[livarcocc]

Closing as this now works. Thanks for all the comments and details on how to do this appropriately.