The specified version string does not conform to the required format - major[.minor[.build[.revision]]]

Question

I want to append our application version with the build number. For example, 1.3.0.201606071.

When setting this in the AssemblyInfo, I get the following compilation error:

Error CS7034 The specified version string does not conform to the required format - major[.minor[.build[.revision]]]

Assembly info:

[assembly:System.Reflection.AssemblyFileVersionAttribute("1.0.0.201606071")]
[assembly:System.Reflection.AssemblyVersionAttribute("1.0.0.201606071")]
[assembly:System.Reflection.AssemblyInformationalVersionAttribute("1.0.0.201606071")]

Why would this be happening?

Solution 1

The maximum value for either of the parts is 65534, as you read here. This is a limit imposed by the operating system, so not even specific to .NET. Windows puts the version numbers into two integers, which together form four unsigned shorts.

Adding some metadata to it (for the * option I guess) makes the maximum allowed value UInt16.MaxValue - 1 = 65534 (Thanks to Gary Walker for noticing):

All components of the version must be integers greater than or equal to 0. Metadata restricts the major, minor, build, and revision components for an assembly to a maximum value of UInt16.MaxValue - 1. If a component exceeds this value, a compilation error occurs.

Your 201606071 exceeds this limit.

Solution 2

If you are targeting netcoreapp2.0 and don't have AssemblyInfo.cs at all you can fix

error CS7034: The specified version string does not conform to the required format

by adding this into your .csproj file:

<PropertyGroup>
  <GenerateAssemblyInfo>False</GenerateAssemblyInfo>
  <Deterministic>False</Deterministic>
</PropertyGroup>

Solution 3

It's because each number in the version is a ushort! That's a pity.

Solution 4

In the .csproj file you must set Deterministic to false. Then accepts the compiler a '*' in the Build or Revision.

Solution 5

This limitation only applies to the Assembly and File version so if you are using .Net Core 2.x you can get around this limitation by settings a separate version of each in the csproj.

</PropertyGroup>
    <VersionPrefix>1.1.1.9000001</VersionPrefix>
    <VersionSuffix>$(VersionSuffix)</VersionSuffix>
    <AssemblyVersion>1.1.1.0</AssemblyVersion>
    <FileVersion>1.1.1.0</FileVersion>
</PropertyGroup>

View more solutions

Comments

[Gary Walker]

Actually its 65534 not 65535.

[Patrick Hofman]

No @GaryWalker msdn.microsoft.com/en-us/library/…

[Gary Walker]

@PatrickHofman - Yes, a ushort is limited to 65535, but the build number is limited to 65534

[Shimmy Weitzhandler]

I'm experiencing this issue when trying to set a star value (1.0.*) in a .NET Core project with the new csproj format file, having set GenerateAssemblyInfo to false. Any ideas? I'm looking to achieve auto increment in .NET Core / Standard projects of the new csproj format file.

[Patrick Hofman]

No, I am sorry. Please ask a new question @Shimmy

[jrh]

@Shimmy Did you end up asking that question? What did you find out?

[Dan Atkinson]

For me the problem was that my .csproj file contained <Deterministic>true</Deterministic> but I was targetting .Net 4.0 as well. I removed this and the compiler worked once more. Thanks for pointing me in the right direction.

[Jerrod Horton]

THIS is the real answer.

[m1m1k]

We need a "Best of both worlds" solution for Assembly DATE AND Assembly Semantic Versioning. 1.yyyy.mmdd.buidNum

[Jesse Chisholm]

Oddly, each field in AssemblyVersion is limited to 65534, but in AssemblyFileVersion the limit it 65535. Yeah for consistency!

[Jesse Chisholm]

One also has to wonder why there is Version.MajorRevision and Version.MinorRevision (the high and low 16 bits respectively) if the Revision field is only 16-bits total.