While preparing a hotfix this afternoon, I decided to take this a step further, and set the defect number as the 4th item in the version tuple (leaving the first three tuple values as the version of the product being hotfixed), instead of just selecting and choosing an arbitrary value for the 4th value.
The defect number in this case was 96375. In Visual C++ 6, in the project with the COM component I was building, I set the FILEVERSION value in the VS_VERSION_INFO section of the project's generated .rc file to 96375.
However, when I built the .dll and looked at the File Version value, it was set to 30839. I guessed that the value I used might have exceeded the maximum allowed value and either been set to a constant max value of 30839 (although that number didn't immediately have any meaning to me), or else "wrapped" after hitting the maximum value.
A Google search didn't reveal any information about a maximum value for FILEVERSION, so I did some brief experimentation. It didn't take long to determine that the field is apparently a 16-bit integer, with a maximum value of 65535. Assigned values of 65536 or greater just "wrap" back around to 0. So a value of 65537 yields 1, a value of 65538 yields 2... and my value of 96375 yielded the value of 96375 - 65536 = 30839.
I settled for assigning a value of 9999 to the 4th item in the FILEVERSION tuple, figuring that would be a suitable "red flag" for anyone inspecting the version number later. I also appended the text "HOTFIX 96375" to the FileDescription field's value, so that the defect number would still appear on the .dll file's Properties dialog.
Thanks, I got the same problem trying to stamp an exe with a huge number and now I know why I got an other number stamped :)
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDelete