Fixing invalid version number problems with the AssemblyInfoTask


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.


Questions or problems after doing the above? Contact us using the e-mail link at the top of this page.


[ Author: Neil Enns ]

Comments (23)

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

  2. UPDATE: For information on the "Y7K" or "2007" issue, see our new blog entry . One of our most frequently

  3. Buck Hodges says:

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

  4. Jonathan Reyes says:

    Great fix.

    I do have a suggestion. I think its better to use MMddyy than 01MMdd.

    But still thanks for the great fix.

  5. Greg says:

    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.

  6. Steve says:

    Greg – your julian dateformat string doesn’t work.  When I use yyddd it throws and exception trying to parse it, most likely because ddd means "short name of day" as in "Mon".  Is this solution actually working for you?  If so, what other mods did you make to get it going?

    Thanks.

  7. VIO says:

    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.

  8. JZ says:

    I followed VIO response of using YYWDDY using ISO date formats.  I get the error: "Input string was not in a correct format. Failed to increment Build Number!"  So, for example my value is 07133 which when converted to a long is 7133 for my build number.  Anyone know how to fix the error?

  9. RJS says:

    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).

  10. I guess I’m the only person that actually injects a serial build number from an integration server into my assembly versions.  Good thing my projects are only a year old and the build number is in the 4,000s.

  11. Steve says:

    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’ AssemblyInfoDebugAssemblyInfo.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>

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

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

    กรุงเทพๆ 10400

  14. Denis says:

    I have found another workaround-Versioning that could work in my eyes: Use the year as Build-Number and Month/Day as Revision.

    If you really publish something you won’t likely have more than one release each day, right?

  15. Jason says:

    @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.

  16. Randar Puust says:

    Since everyone seems to have a solution, we are going to try the following:

    Major.Minor.YYMM.DDBuildNumber

    So you would have:

    -5.0.0801.220 is Version 5, built on Jan 22nd, 2008.  

    -5.0.0801.2211 is Version 5, built on Jan 22nd, 2008, 11th build of the day.  

    -5.1.200801.010 is Version 5.1, built on Jan 1st, 2008.

    It’s a bit cryptic, but at least it fits within the bounds unless you have an insane number of builds.

  17. One common requirement with any decent sized multi-version product is to automatically update the version

  18. Replacing the assembly version with this.. solved the error for me…..

    [assembly: AssemblyVersion("1.0.*")]

  19. Christian says:

    Which is a right DateString Format?

    There is still the Error:

    The specified string is not a valid version number

    <PropertyGroup>

       <AssemblyMajorVersion>0</AssemblyMajorVersion>

       <AssemblyMinorVersion>2</AssemblyMinorVersion>

       <AssemblyBuildNumber></AssemblyBuildNumber>

       <AssemblyRevision></AssemblyRevision>

       <AssemblyBuildNumberType>DateString</AssemblyBuildNumberType>

       <AssemblyBuildNumberFormat>yyDDmm</AssemblyBuildNumberFormat>

       <AssemblyRevisionType>AutoIncrement</AssemblyRevisionType>

       <AssemblyRevisionFormat></AssemblyRevisionFormat>

     </PropertyGroup>

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

     <PropertyGroup>

       <AssemblyFileMajorVersion>0</AssemblyFileMajorVersion>

       <AssemblyFileMinorVersion>2</AssemblyFileMinorVersion>

       <AssemblyFileBuildNumber></AssemblyFileBuildNumber>

       <AssemblyFileRevision></AssemblyFileRevision>

       <AssemblyFileBuildNumberType>DateString</AssemblyFileBuildNumberType>

       <AssemblyFileBuildNumberFormat>yyDDmm</AssemblyFileBuildNumberFormat>

       <AssemblyFileRevisionType>AutoIncrement</AssemblyFileRevisionType>

       <AssemblyFileRevisionFormat></AssemblyFileRevisionFormat>

     </PropertyGroup>

  20. Ken Smith says:

    Has this been tested with MSBuild 4.0?

    I used AssemblyInfoTask in the TFSBuild project file to update the version numbers in a Visual Studio 2008 solution. It worked perfectly. Recently we changed the solution into a Visual Studio 2010 solution. Since we are still using TFS 2008, I modified TFSBuildService.exe.config on the build agent to set the MSBuildPath to the directory containing MSBuild.exe 4.0. It built successfully, however, AssemblyInfoTask did not work anymore.

    Checking the build log, I saw:

    Target "UpdateAssemblyInfoFiles" in file "C:Program FilesMSBuildMicrosoftAssemblyInfoTaskMicrosoft.VersionNumber.targets" from project "C:UsersjhuangAppDataLocalTempFooFoo2010BuildTypeTFSBuild.proj" (target "CallCompile" depends on it):

    Skipping target "UpdateAssemblyInfoFiles" because all output files are up-to-date with respect to the input files.

    Any clues on why it happens? Thanks!

  21. Greg Bradburn says:

    I am having this exact same problem. any help would be greatly appreciated.

  22. Ken Smith says:

    I have resolved the issue by using the AssemblyInfoTask in 4.0 version of MSbuild Extension Pack.

    msbuildextensionpack.codeplex.com