Michael Sync

AssemblyVersion - BuildNo Limitation

12 Jan, 2007 C#, Microsoft, Tips and Tricks

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: 0×0003000a and 0×0000003d, 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).

Solution

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 Microsoft.VersionNumber.target, 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 1.0.0.0 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: 2.0.0.071005 is bad, but 2.0.0.061005 is good
Why are build numbers limited to 65535?
Fixing invalid version number problems with the AssemblyInfoTask

6 Comments so far »

Alex Espinoza said

am January 12 2007 @ 10:17 pm

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.
Michael Sync said

am January 13 2007 @ 1:35 pm

Thanks so much. Alex.

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

AA.BB.CCDD.EEFF

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
Alex Espinoza said

am January 16 2007 @ 9:25 pm

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.
Ashish C. said

am January 17 2007 @ 11:18 am

Remember if you grow tired of programming you could of course freeze yourself anf go to 9999!
I’ll skip the post since it goes over my head!
mUnit : Mun talks technology » Assembly Version Numbers and .NET said

am February 17 2007 @ 10:02 pm

[...] I came across Michael Sync’s blog, where he also experienced this problem and wrote about his findings. In summary, he [...]
0205 said

am October 7 2007 @ 9:03 am

0205

Free Flash gamesz online Visit http://www.Flashgamesz.net