Why are build numbers limited to 65535?

In my previous post I explained how to fix the issue with the default date format provided in the AssemblyVersionTask. Several people encountered the problem with the arrival of 2007, and all of them sent me mail about it 🙂 After providing them with the fix, a few people wrote back and commented (with variying degrees of politeness) that my code was bad and that I should change it to support a larger build number.

That’s a mighty fine suggestion, but unfortunately the limitation isn’t in my code, it’s imposed by the operating system:

Binary version number for the file. The version consists of two 32-bit integers, defined by four 16-bit integers. For example, “FILEVERSION 3,10,0,61” is translated into two doublewords: 0x0003000a and 0x0000003d, in that order. Therefore, if version is defined by the DWORD values dw1 and dw2, they need to appear in the FILEVERSION statement as follows: HIWORD(dw1), LOWORD(dw1), HIWORD(dw2), LOWORD(dw2).

So, I’m sad to say, we will be stuck with 16-bit build numbers forever.

[ Author: Neil Enns ]

Comments (9)

  1. Buck Hodges says:

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

  2. Sie erzeugen tägliche Builds in VSTS und nutzen den AssemblyInfoTask , um die File und Assembly Build

  3. Eric Lee says:

    Great explanation, thanks for the details!

  4. Mark says:

    I made a patch for the zip task to canonicalize the working directory path, but I can’t seem to get a hold of you guys. Recommendations?

  5. Mark says:

    er… is this the community tasks blog, or the msbuild blog?

  6. Mike Fourie says:

    Mark, this is the msbuild team blog, not the community tasks blog.


  7. Dan Trietsch says:

    Could use YY + ordinal days (days since 1/1) ; such that, March 26, 2007 build would be: 1.0.07084.00

  8. chha says:

    I am terribly sorry guys, but you are all wrong: The highest valid build number is not 65535 (but you were pretty close: it’s 65534. But don’t ask why, 65535 throws an exception, 65534 does not…)

  9. Bryan Garcia says:


    As per the Practices (How to Modify the Build Number) in the TFSGuide we should override BuildNumberOverrideTarget to synchronize the TFSBuild number with the Actual Assembly version. This cant be done with your current method since the Assembly info task has 2 steps or tasks merged in one. I should be able to generate the Assembly Version and Information and then before compiling, copy it to the file. This is as I said before is done in one single step inside the Execute for the task. I’m modifying the source code to create two diferent tasks one that will generate the Version and Assembly info, and the other that will write to the corresponding assembly files. I will generate the Assembly version and information on BuildNumberOverrideTarget and then on UpdateAssemblyInfoFiles only will copy the previously generated Assembly Version and info to the files (no increment will be done in this step) this will require of course modifications to the VersionNumber.targets file. My question is, are you guys planning to do this? I have seen various posts asking for this, and in the TFSGuide they explicitly talk about it, but they dont actually provide the implementations for the tasks, its like it assumes that the reader knows that he has to implement that task.