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