Build Fails from Jan 01 2007. Versioning issue!! :-(

Build Fails from Jan 01 2007. Versioning issue!! :-(

• Dale17677

  The build veriosn is of form major.minor.YYMMDD.revision

  & not as specified above.. & the issue still exists!! :-( :-(

  
  

• Kings Indian

  Just in case nobody has noticed this yet - this option will not work. The only reason yymmdd worked in the first place was that the first digit of the "yy" part was always zero, and therefore the full number was always sixty thousand something in 2006. With the ddmmyy format, you'd be in trouble any time the day became two digits (e.g. January 10th, 2007 would be 100107, which is greater than 65,535). You could get by for a few more years using ddmmy, of course (which would give 10017 for the same example).

  -Aaron

  
  
  

• rcopley2

  I'm using the "ddMMy" date format with only one digit for the year, it continues to be legible for about 10 years, and you only have to change the date format strings in the targets file.

  It works fine for me.

  RGranada.

  
  
  

• Rajesh batchu

  I'm sure I'm missing something obvious here, but what format string are you using to get the day of the year
  

• DavidThi808

  Agree, there is a flaw in the default of AssembyInfoTask - but the flaw is the fact that the AssemblyVersion is changed by default! So you should always set the properties to fix the AssemblyVersion by doing one of the following:

  1. Prepare your AssemblyInfo.cs

  In AssemblyInfo.cs FIX the AssemblyVersion, e.g

  [assembly: AssemblyVersion("1.0.2.0")] // this is your current release version you are working on

  but leave the AssemblyFileVersion open to changes by AssemblyInfoTask:

  [assembly: AssemblyFileVersion("1.0.070102.02")] // this is the actual build of the release and should be updated automatically

  2.a. Either change each individual project using AssemblyInfoTask:

  Then, in your csproj-file use the following values to control the numbering of AssemblyVersion and AssemblyFileVersion:

  <PropertyGroup>

  <AssemblyBuildNumberType></AssemblyBuildNumberType>

  <AssemblyRevisionType>NoIncrement</AssemblyRevisionType>

  <AssemblyFileBuildNumberType>DateString</AssemblyFileBuildNumberType>

  <AssemblyFileBuildNumberFormat>yyMMdd</AssemblyFileBuildNumberFormat>

  </PropertyGroup>

  2.b ....or change the defaults of AssemblyInfoTask by putting the above mentioned values in the PropertyGroup inside the targets-file for AssemblyInfoTask, located at

  "c:\Program Files\MSBuild\Microsoft\AssemblyInfoTask\Microsoft.VersionNumber.targets"

  (done easiest by deleting this block from the file:

  <-- put these 4 lines in a comment or delete them from the file
  <AssemblyBuildNumberType>DateString</AssemblyBuildNumberType>
  <AssemblyBuildNumberFormat>yyMMdd</AssemblyBuildNumberFormat>
  <AssemblyRevisionType>AutoIncrement</AssemblyRevisionType>
  <AssemblyRevisionFormat>00</AssemblyRevisionFormat>
  -->

  3. Result:

  This will force the AssemblyVersion numbers being fixed and only the AssemblyFileVersion numbers getting updated. In VS this will lead to a warning as the fileversion will be e.g. 070101 (and thus >65535) but it will compile and you will find the correct version info in the resulting assembly. For some strange reason buildnumbers >65535 ARE actually allowed for a file-version while NOT allowed being used in assembly-version.

  Keeping the AssemblyVersion fixed is best pratice at Microsoft, see e.g.http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=356081&SiteID=1

  regards,

  Martin Born.

  
  

• intrepid

  It's not a format string... I just added one more item to the enum IncrementMethod in the AssemblyInfoTask.cs to use the DayOfYear, and then added a case statement for this along with the others. Then you are probably aware of the DateTime method in the framework DateTime.Today.DayOfYear.ToString(). Then I rebuilt the task.
  

• Indirani

  We have many applications deployed with click once. If we da a fallback back to 1, we will have a lower version number in the manifest(generated from the assemblyinfo file). ClickOnce should handle downgrade, but the requiret version number will be lower so the user will have the option to ship the upgrade..(but we have own version check also, but now they are not used to any prompt when upgrading)

  Is there any way to avoid this or another solution that is working

  
  

• Edward1

  Good point. That's an attractive option that I had never thought of. On the other hand, I don't like the fact that later builds would have smaller version numbers as you moved from the 31st of the month to the 1st of the next month -- which is a bit against the spirit of version numbers. Way to think out of the box though.
  

• qrli

  I too was excited about meaningful version numbers, but it seems like we should put a big caveat on this limitation before everybody starts building in this scheme to their automated build scripts and everybody's build breaks in a month. We debated putting the year in the minor version, but that seems to go against the spirity of minor version since it is common to have more that one minor release per year. In order to stay with the meaningfulness and not have to hack the code too much, we are using the year -- 7 -- followed by the day of the year, e.g. 1-365. Around the year 6500 let's have this conversation again.
  

• GoDaddy

  Take a look at dzimmy's post below. You can postpone the problem by using the last two digits of the year followed by the day of the year (range 1-366). The largest possible unsigned short you can support with this method is 65366. But that gets you to the year 2065. Which is pretty good

  Thanks, Jason

  
  

• Muzaffar_Ali99

  You are correct. We face this same problem internally. I do not have the background on why the version numbers are shorts, but my guess is it saves space. The problem is that Team Build (and Microsoft internally) prefer build numbers that have some meaning when you look at them, like the date it was built.

  Unfortunately, as you have pointed out, at the end of this year we lose the ability of putting the correct year at the front of that string. Internally, we are falling back to 1 instead of 7. The TeamBuild code however will still use the correct year to generate the build number unless you create custom build numbers.

  If you have any further information about how you worked around these problems, please post a reply so that other forum users can learn from your experiences.

  Thanks, Jason

  
  

• &amp;#42;Rick&amp;#42;

  It is possible that you can post the amended DLL and/or MSI anywhere
  

• Gagand

  All our nightly builds have been faliling as of Jan 01 2007

  we get the following error Error emitting 'System.Reflection.AssemblyVersionAttribute' attribute -- 'The version specified '8.1.70102.1' is invalid

  It is due to the versioning issue build.major.minor.revision. The minor is of form yyMMdd

  The revision is an unsigned int & so the max value is 65534!!!!! & so it fails from the 1st of the 2007 as 70101 > 65534 :-( :-(

  Has there been a solution found for this I saw a thread that says this issue was identified in 2005 dec..:( :(..

  Somone pls do let me know how i can fix this

  Thanks in advance

  Ramya

  
  

• Tulongbaodao

  Isn't it just possible to use the format string 'ddmmyy' instead of 'yymmdd'. While this might not be as easily readable as the old string, this one does not have the limitations of the integer-overflow and still offers all the information.
  
  
• Build Fails from Jan 01 2007. Versioning issue!! :-(