MSBuild Team Blog

In my previous post I explained how to fix the issue with the default date format provided in the AssemblyVersionTask.

If you use the AssemblyInfoTask to stamp the version numbers for your assemblies that you build with

Are none of you old enough to remember the old days, where storage was expensive enough that cutting one byte out of each record in a file could be a huge savings?

I changed my version to use yyddd, where the first two digits are the year, and the last three digits are the day of the year, 1-365(366).  You can guess at the number -- 32 is February 1st, July 1st is just over 180, etc. -- or you can figure it out easily enough if you need to know what day of the year 246 is.

And yes, some people have pointed out that I've just replaced the Y2K7 problem with the Y2K66 problem, but I hope I'll be retired by then.

What if, we use the following format - "YYWKDY" where WK represents the week of year (max 2 digits) and DY represents the day of week (max 1 digit).

E.g. for 02/23/2007 will have 07086 which is year 2007, week 08 and day 6 of week.

seems to me that the best way around this one is allowing a value to exceed UInt16 - maybe a 32 would have been more appropriate.

The person that decided to use the date for their buildnumber is going "doh!" about now....

Of course the one that decided the version numbers should be limited to an UInt16 never dreamed of a date value being used.

granted, the yyddd idea isn't bad- but the year is still the clincher-

so- put the day first... 36599 - would keep you below 65535 (until you tried to squeeze a 4 digit year in).

What am I missing? I am still getting the error: Error 11 Error emitting 'System.Reflection.AssemblyVersionAttribute' attribute -- 'The version specified '1.0.71210.8' is invalid' AssemblyInfo\Debug\AssemblyInfo.cs

I made the following mod:

 <PropertyGroup>

   <AssemblyMajorVersion>1</AssemblyMajorVersion>

   <AssemblyMinorVersion>0</AssemblyMinorVersion>

   <AssemblyBuildNumber></AssemblyBuildNumber>

   <AssemblyRevision></AssemblyRevision>

   <AssemblyBuildNumberType>DateString</AssemblyBuildNumberType>

   <AssemblyBuildNumberFormat>MMddyy</AssemblyBuildNumberFormat>

   <AssemblyRevisionType>AutoIncrement</AssemblyRevisionType>

   <AssemblyRevisionFormat>00</AssemblyRevisionFormat>

 </PropertyGroup>

 <!-- Properties for controlling the Assembly File Version -->

 <PropertyGroup>

   <AssemblyFileMajorVersion>1</AssemblyFileMajorVersion>

   <AssemblyFileMinorVersion>0</AssemblyFileMinorVersion>

   <AssemblyFileBuildNumber></AssemblyFileBuildNumber>

   <AssemblyFileRevision></AssemblyFileRevision>

   <AssemblyFileBuildNumberType>DateString</AssemblyFileBuildNumberType>

   <AssemblyFileBuildNumberFormat>MMddyy</AssemblyFileBuildNumberFormat>

   <AssemblyFileRevisionType>AutoIncrement</AssemblyFileRevisionType>

   <AssemblyFileRevisionFormat>00</AssemblyFileRevisionFormat>

 </PropertyGroup>

99/28 ม.บ้านอยู่สบาย ถ.กรุงเทพกรีฑา ข.สะพานสูง

กรุงเทพๆ 10400

@Denis

If you have an automated build process and you check in each change into source control and go on to add a new change, a build would be generated after each check in. So yes, you could likely have more than one "release" in a day.