Fix wrong ORT version in Windows DLL VersionInfo for pipeline builds#29545
Open
Sammy-Dabbas wants to merge 2 commits into
Open
Fix wrong ORT version in Windows DLL VersionInfo for pipeline builds#29545Sammy-Dabbas wants to merge 2 commits into
Sammy-Dabbas wants to merge 2 commits into
Conversation
The ADO pipeline branch in generate_build_tree stamps VERSION_BUILD_PART from the build year's last two digits and drops the patch version, so official Windows DLLs report versions like 1.27.26.615 instead of 1.27.0. Stamp the real major.minor.patch from VERSION_NUMBER, keep MMDD as the fourth numeric part for build traceability, and include the patch in the version string. Fixes microsoft#29536.
Author
|
@microsoft-github-policy-service agree |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes incorrect Windows DLL VersionInfo stamping for official Azure DevOps pipeline builds by deriving the correct major.minor.patch from VERSION_NUMBER and including the patch in the version string, instead of deriving the numeric “build” part from the build-year digits.
Changes:
- Parse
major.minor.patchfromVERSION_NUMBERwhenBuild_BuildNumber/Build_SourceVersionare present. - Stamp
VERSION_BUILD_PARTwith the ORT patch version and include patch inVERSION_STRING(while keepingMMDDinVERSION_PRIVATE_PART).
Author
|
Good catch on the error message, it referenced VERSION_FILE while the code reads VERSION_NUMBER. Fixed in the latest commit. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Official Windows DLLs embed the wrong version in their VersionInfo resource, for example File version 1.27.26.615 for the 1.27.0 release. The cmake fix from #24606 is intact but only covers local builds; official packages are produced by the ADO pipelines, which take a different path in tools/ci_build/build.py. When Build_BuildNumber and Build_SourceVersion are set, that branch stamps VERSION_BUILD_PART from the last two digits of the build year and drops the patch version from the version string entirely. I checked the shipped 1.22.0, 1.23.0, 1.26.0, and 1.27.0 Windows packages and all four carry the wrong version, so this path was never fixed.
This change parses major.minor.patch from VERSION_NUMBER, stamps the real ORT version in the numeric FILEVERSION (keeping MMDD as the fourth part for build traceability; it fits a 16-bit WORD), and includes the patch in the version string, which becomes for example 1.27.0.20260615.4.8f0278c. Local builds are unaffected. One open question for reviewers: whether you would rather have the fourth numeric part be the pipeline revision or zero instead of MMDD.
Motivation and Context
Fixes #29536. Anyone inspecting DLL properties, or tooling that reads VersionInfo to identify the installed ONNX Runtime version, currently sees a build-date artifact instead of the actual release version.
Verified by executing the pristine and patched stamping logic with the real 1.27.0 release inputs (the pristine output reproduces the issue exactly), and by compiling onnxruntime.rc with the Windows SDK rc.exe under both define sets and decoding VS_FIXEDFILEINFO from the .res: 1.27.26.615 before, 1.27.0.615 after. A full pipeline build was not run; confirming end to end means building with Build_BuildNumber and Build_SourceVersion set and checking the DLL's FileVersionRaw.