See: AssemblyFileVersions: 2.0.0.071005 is bad, but 2.0.0.061005 is good

Apparently some bozo at Microsoft decided it would be great to just have 16 bits for revision and all the other numbers as well. This version number is specified as a string, but you can't have a number that doesn't fit in 16bits.

As you're probably aware of, we use revision numbers on some assemblies using the AssemblyFileVersion and use the revision part with a number using the format YYMMDD, e.g. 061201.

As the year is now 07, it makes a number > 65535 and it won't fit in 16 bit.

Lovely, isn't it, when crap from 1839 or older is still kept around because there MIGHT be someone outthere who still uses WfW 3.11 software on Windows XP.

Anyway, as there's no solution other than to use a different versioning numbering, we'll be changing the numbering as follows:

New format, starting with all new builds in 2007 2.0.YY.MMDD

This is with new builds. So code which didn't change since some day in 2006 doesn't get a new build number and will keep its old number 2.0.0.YYMMDD till it gets a new build.

We appologize for this inconvenience.

I ran into exactly the same problem.

Interestingly, although AssemblyVersion doesn't support numbers > 65536 (throws a compile error), AssemblyFileVersion only gives a warning.

I ended up modifying my build script to increment AssemblyFileVersion rather than AssemblyVersion and now at least the build compiles.

It seems that it's windows' own limitation, so changing it to 32bit values is IMHO impossible (read: they won't do it).

Ironically, .NET is also versioned this way: YYMMDD, at least that's what some suggest (2.0.50727)