[dotnet] Fix the .NET 10 MSI minor-version computation for Xcode 27 and later - #25688
Conversation
…nd later
The .NET 10 custom MSI version scheme in generate-vs-workload bumped the minor
version using:
int.Parse (new Version (26 - xcodeMajor, xcodeMinor).ToString ().Replace (".", ""))
For Xcode 27 and later, (26 - xcodeMajor) is negative, and the System.Version
constructor rejects negative components, so this threw and broke VS workload
generation.
Compute the bump arithmetically instead:
minorVersionBump = (xcodeMajor - 26) * 10 + xcodeMinor
This is equivalent to the old expression for the Xcode 26.x series (single-digit
minor) and keeps the MSI minor monotonically increasing with the Xcode version
while staying above the 255.220.39248 baseline and below the 255 minor ceiling
across .NET 10's supported Xcode range. A detailed explanation of the scheme is
added as a comment.
Standalone backport of the generate-vs-workload.cs change from the Xcode 27
update (dotnet/macios #25665, commit 0dc3ce9), as suggested in code review;
it is independent of the Xcode 27 bump itself.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
There was a problem hiding this comment.
Pull request overview
Fixes VS workload generation for .NET 10 when building against Xcode 27+ by correcting the MSI minor-version bump computation (the previous implementation could throw due to negative System.Version components).
Changes:
- Replace the previous
System.Version-based bump computation with an arithmetic formula that works for Xcode 27 and later. - Add detailed in-code documentation explaining the MSI versioning scheme and constraints.
| // minor = minimumVersion.Minor + (26 - Major Xcode version) * 10 + (Minor Xcode version) | ||
| var minorVersionBump = int.Parse (new Version (26 - Version.Parse (xcodeVersion).Major, Version.Parse (xcodeVersion).Minor).ToString ().Replace (".", "")); | ||
| var minorVersionBump = (Version.Parse (xcodeVersion).Major - 26) * 10 + Version.Parse (xcodeVersion).Minor; | ||
| // just use the commit distance for the build version, our minor version will be higher than the minimum version, so we can use any build version. |
✅ [PR Build #4166391] Build passed (Detect API changes) ✅Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
✅ [PR Build #4166391] Build passed (Build packages) ✅Pipeline on Agent |
✅ API diff for current PR / commitNET (empty diffs)✅ API diff vs stableNET (empty diffs)ℹ️ Generator diffGenerator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes) Pipeline on Agent |
✅ [PR Build #4166391] Build passed (Build macOS tests) ✅Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
🔥 [CI Build #4166391] Test results 🔥Test results❌ Tests failed on VSTS: test results 0 tests crashed, 1 tests failed, 192 tests passed. Failures❌ introspection tests [attempt 3]1 tests failed, 5 tests passed.Failed tests
Html Report (VSDrops) Download Successes✅ cecil: All 1 tests passed. Html Report (VSDrops) Download macOS tests✅ Tests on macOS Monterey (12): All 5 tests passed. [attempt 3] Html Report (VSDrops) Download Linux Build VerificationPipeline on Agent |
|
Unrelated test failure |
The .NET 10 custom MSI version scheme in generate-vs-workload bumped the minor version using:
For Xcode 27 and later, (26 - xcodeMajor) is negative, and the System.Version constructor rejects negative components, so this threw and broke VS workload generation.
Compute the bump arithmetically instead:
This is equivalent to the old expression for the Xcode 26.x series (single-digit minor) and keeps the MSI minor monotonically increasing with the Xcode version while staying above the 255.220.39248 baseline and below the 255 minor ceiling across .NET 10's supported Xcode range. A detailed explanation of the scheme is added as a comment.
Standalone backport of the generate-vs-workload.cs change from the Xcode 27 update (dotnet/macios #25665, commit 0dc3ce9), as suggested in code review; it is independent of the Xcode 27 bump itself.