AssemblyVersion – BuildNo Limitation

I was trying to compile a new build of our project today morning. We used to give the build no of our project’s assembly in YYMMDD format. (Build No “70112” for 12th January,2007). So, I changed the version no of assembly to “2.2.70112.2” [<major version>.<minor version>.<build number>.<revision>] (More Info) before compiling the project.

When I tried to compile, I got the following error.

Error emitting ‘System.Reflection.AssemblyVersionAttribute’ attribute — ‘The version specified ‘2.2.70112.2’ is invalid’

I was so surprised about it. I thought, we can give any number as we like for the version of our assemblies. Then, I googled it and I came to know that there are a lot of people who are facing the same problem. and I also found the reason why this error occur and how we should fix this problem.

Why this problem?

This article said,

Binary version number for the file. The version consists of two 32-bit integers, defined by four 16-bit integers. For example, “FILEVERSION 3,10,0,61” is translated into two doublewords: 0x0003000a and 0x0000003d, in that order. Therefore, if version is defined by the DWORD values dw1 and dw2, they need to appear in the FILEVERSION statement as follows: HIWORD(dw1), LOWORD(dw1), HIWORD(dw2), LOWORD(dw2).


This article “Fixing invalid version number problems with the AssemblyInfoTask” said,

The arrival of 2007 bought a flurry of e-mails to the MSBuild team from people having trouble with the AssemblyInfoTask. The symptom is simple to describe – the builds start to fail with the following error:

Error emitting ‘System.Reflection.AssemblyVersionAttribute’ attribute — ‘The version specified ‘1.0.70102.1’ is invalid

The fix to get builds going again is to change the date format used to generate the build number to something other than the default “yyMMdd”. The date formats are in, located in %program files%\MSBuild\Microsoft\AssemblyInfoTask, and there are two of them (one for file version and one for assembly version). You can use any format you want. Within Visual Studio we’re now using 01MMdd.

Note that you may have to go in and hand-edit your assemblyinfo.* files to change their version number back to a default starting point of to get your builds going again.

However, I don’t think it’s a solution since we are not able to use the way that we already used to it.
So, Be careful when you are assigning the version of your build. “[assembly: AssemblyVersion(“65534.65534.65534.65534”)]” is maximum.

References ~
AssemblyFileVersions: is bad, but is good
Why are build numbers limited to 65535?
Fixing invalid version number problems with the AssemblyInfoTask

7 thoughts on “AssemblyVersion – BuildNo Limitation

  1. This is really interesting. I also thought you could use whatever numbers you would like.

    I’m currently using VCB add-in to manage my build versions. I’m actually using the Microsoft scheme which uses the date and hour. For today I got: 1.1.2568.40048

    It is some kind of Date&Time scheme. You should try this tool. It rocks.

  2. Thanks so much. Alex.

    This article “Build Number Automation for Visual Studio .NET Projects By Darrel Liu”


    AA is the major version
    BB is the minor version
    CC will be used to represent the number of months elapsed since the starting of the project,
    DD the number of days after those months.
    EE and FF will be the hours and minutes the build was created in that day.

    for example,
    if the project started on Jan 10, 2003 with version 1.0 and you run this macro on Mar 15, 2003 at 14:00, this is the build number that comes out of the calculation: 1.0.0205.1400.

    Is it the way that you are using??
    If so, I’m not sure why you got this no “1.1.2568.40048” for today??

    AA = 1
    BB = 1
    CC = 25
    DD = 68
    EE = 400
    FF = 48

  3. The thing is the actual add-in doesn’t follow the rules it says it does.

    The first thing is that this plug in uses the reference date 1/1/2000 00:00:00.

    AA & BB are used my project. So it is Major version 1, and minor version 1.

    CC=25 & DD=68 are seen as 2568 days since the reference date (1/1/2000).

    EE=400 & FF=48 are seen as 40048 seconds. But this is interesting, remeber the 65534 limit for build numbers? well 40048 seconds is actually 80096, but since that number is too big, the developer of the add-in cuts the seconds in half.

    revisionVersion = (int)(currentDateTime.TimeOfDay.TotalSeconds / 2);

    Another really interesting thing, is that the plug in uses Utc time.

  4. Pingback: 0205

Leave a Reply

Your email address will not be published. Required fields are marked *