The problem is well-known - all four parts of the version number are limited to 16-bit numbers. So, when you used versioning like this: x.y.z.ymmdd, thus when the 2007.01.01 arrived, you were in trouble and got the infamous csc error:

[csc] error CS0647: Error emitting 'System.Reflection.AssemblyVersionAttribute' attribute -- 'The version specified '1.0.1.70102' is invalid'

The users of the AssemblyInfoTask for msbuild had to do something when they got back to work just after the new-year's party ;). Actually I use NAnt instead of msbuild, but I really loved this way of 'stamping' my assemblies, so I used the pattern too. For example, in DotNetNuke modules, the version number consists of three numbers, so the last one (revision) is a very good place to store the build date.

  <tstamp property="build.date" pattern="yMMdd"/>
  <property name="build.version" value="${build.major}.${build.minor}.${build.build}.${build.date}" />

(other numbers coming from other place)
I didn't want to jump to the 'BuildDay' pattern, so I decided to cut the number % 50000.

  <property name="build.version" value="${build.major}.${build.minor}.${build.build}.${int::parse(build.date)%50000}" />

That way I've got now 5 years to change other numbers to not to get in trouble with 'previous version'... :) After all, I'm not fully satisfied with this solution and here comes the question: how do you play (if you do ;)) with the build-date in your assemblies?

---

Posted 03-04-2007 3:50 PM by Michal Grzegorzewski