Condividi tramite

Fixing invalid version number problems with the AssemblyInfoTask

  • Articolo

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

  • Anonymous
    January 03, 2007
    In my previous post I explained how to fix the issue with the default date format provided in the AssemblyVersionTask.

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

  • Anonymous
    January 06, 2007
    If you use the AssemblyInfoTask to stamp the version numbers for your assemblies that you build with

  • Anonymous
    January 11, 2007
    Great fix. I do have a suggestion. I think its better to use MMddyy than 01MMdd. But still thanks for the great fix.

  • Anonymous
    January 12, 2007
    The comment has been removed

  • Anonymous
    January 17, 2007
    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.

  • Anonymous
    February 22, 2007
    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.

  • Anonymous
    March 28, 2007
    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?

  • Anonymous
    March 29, 2007
    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).

  • Anonymous
    September 19, 2007
    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.

  • Anonymous
    December 10, 2007
    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>

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

  • Anonymous
    January 28, 2008
    99/28 ม.บ้านอยู่สบาย ถ.กรุงเทพกรีฑา ข.สะพานสูง กรุงเทพๆ 10400

  • Anonymous
    March 17, 2008
    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?

  • Anonymous
    March 20, 2008
    @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.

  • Anonymous
    April 11, 2008
    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.

  • Anonymous
    June 12, 2008
    One common requirement with any decent sized multi-version product is to automatically update the version

  • Anonymous
    July 11, 2008
    The comment has been removed

  • Anonymous
    September 29, 2008
    Replacing the assembly version with this.. solved the error for me..... [assembly: AssemblyVersion("1.0.*")]

  • Anonymous
    July 29, 2009
    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>

  • Anonymous
    April 19, 2010
    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!

  • Anonymous
    May 05, 2010
    I am having this exact same problem. any help would be greatly appreciated.

  • Anonymous
    June 18, 2010
    I have resolved the issue by using the AssemblyInfoTask in 4.0 version of MSbuild Extension Pack. msbuildextensionpack.codeplex.com