Updating build agent image to use VS2026#14299
Merged
Shyam-Gupta merged 9 commits intomainfrom Feb 18, 2026
Merged
Conversation
VS2022 images have been deprecated this week and we need to move to VS2026. This change will need to be backported to servicing branches also.
…p layout panel interaction was broken. The test used Win+Z to open the snap layout panel, then navigated with arrow keys to select the right-half snap position. However, each SendAsync(Form, params object[]) call invoked SetForegroundWindow on the form, which dismissed the snap layout panel before the arrow keys could navigate it. For maximized windows, the window remained maximized and the snap never occurred. Root Cause 1. SetForegroundWindow in SendAsync(Form, params object[]) dismissed the Win+Z snap layout panel before arrow keys could navigate it. 2. Win+Z snap panel keyboard navigation is fragile and varies across Windows versions, making it unreliable for automated testing. Fix: Replaced Win+Z + keyboard navigation with Win+Left/Win+Right shortcuts in both Form_SnapsLeftAsync(FormWindowState) and Form_SnapsRightAsync(FormWindowState). These shortcuts directly snap windows without requiring interaction with the snap layout panel, making the tests more reliable across Windows versions.
…"French" became "French (Legacy, AZERTY)" in Windows 11.0. Due to this reason we are using StartsWith instead of equality check for layout name.
merriemcgaw
previously approved these changes
Feb 13, 2026
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #14299 +/- ##
===================================================
+ Coverage 77.18299% 77.23602% +0.05302%
===================================================
Files 3279 3279
Lines 645137 645107 -30
Branches 47730 47731 +1
===================================================
+ Hits 497936 498255 +319
+ Misses 143518 143149 -369
- Partials 3683 3703 +20
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
…h_AddRoundedRectangle_Float failure on x86. Issue: Old and new GDI+ are producing different number of points: 19 and 25 respectively for rounded rectangles' arcs. Fix Updated both tests to validate shape correctness rather than exact point sequences: 1. Point count: Assert that the count is one of the two valid values (19 or 25) 2. Bounding box: Verify the path bounds match the expected (10, 10, 20, 20) rectangle 3. Key coordinates: Verify the first point (top-right corner start at ~27.5, 10) and last point (top-left corner end at ~12.5, 10) are correct This makes the tests robust across different GDI+ implementations while still validating that AddRoundedRectangle(Rectangle, Size) produces a geometrically correct rounded rectangle.
…otate() tests were failing on x86 Windows due to floating-point precision differences after RotateTransform(90). There are tiny epsilon differences (e.g., 1.9E-06 instead of exactly 0). The tests used exact Assert.Equal(0, rotclip.X) for values computed through rotation matrix transforms, which broke on x86. The same issue already existed on ARM (covered by IsArmOrArm64Process skip guards). Fix For all three tests: 1. Replaced exact equality (Assert.Equal(0, value)) with tolerance-based equality (Assert.Equal(0.0, value, 4)) for values computed after RotateTransform() — specifically the .X properties that should be 0 but may have tiny epsilon drift. Note that similar change was already done for verifying other points/lengths. 2. Removed the ARM skip guards (IsArmOrArm64Process + Skip(uint)) since the tolerance-based assertions now handle precision differences on all architectures (ARM, x86, x64).
…ses the value to change to Infinity instead of float.MaxValue.
…imilar issue as Translation Matrix test.
KlausLoeffelmann
approved these changes
Feb 18, 2026
Member
KlausLoeffelmann
left a comment
There was a problem hiding this comment.
Looks good to me.
We should make a mental note about the different floating point "variations", but I think a) it's the underlying API anyway and b) it's fraction variations.
Shyam-Gupta
added a commit
that referenced
this pull request
Feb 18, 2026
* Updating build agent image to use VS2026 VS2022 images have been deprecated this week and we need to move to VS2026. This change will need to be backported to servicing branches also. * Using scout images * The Form_SnapsRightAsync(Maximized) test failed because the Win+Z snap layout panel interaction was broken. The test used Win+Z to open the snap layout panel, then navigated with arrow keys to select the right-half snap position. However, each SendAsync(Form, params object[]) call invoked SetForegroundWindow on the form, which dismissed the snap layout panel before the arrow keys could navigate it. For maximized windows, the window remained maximized and the snap never occurred. Root Cause 1. SetForegroundWindow in SendAsync(Form, params object[]) dismissed the Win+Z snap layout panel before arrow keys could navigate it. 2. Win+Z snap panel keyboard navigation is fragile and varies across Windows versions, making it unreliable for automated testing. Fix: Replaced Win+Z + keyboard navigation with Win+Left/Win+Right shortcuts in both Form_SnapsLeftAsync(FormWindowState) and Form_SnapsRightAsync(FormWindowState). These shortcuts directly snap windows without requiring interaction with the snap layout panel, making the tests more reliable across Windows versions. * Test fix: Layout display names may include OS-specific suffixes e.g. "French" became "French (Legacy, AZERTY)" in Windows 11.0. Due to this reason we are using StartsWith instead of equality check for layout name. * Test fix for GraphicsPath_AddRoundedRectangle_Integer and GraphicsPath_AddRoundedRectangle_Float failure on x86. Issue: Old and new GDI+ are producing different number of points: 19 and 25 respectively for rounded rectangles' arcs. Fix Updated both tests to validate shape correctness rather than exact point sequences: 1. Point count: Assert that the count is one of the two valid values (19 or 25) 2. Bounding box: Verify the path bounds match the expected (10, 10, 20, 20) rectangle 3. Key coordinates: Verify the first point (top-right corner start at ~27.5, 10) and last point (top-left corner end at ~12.5, 10) are correct This makes the tests robust across different GDI+ implementations while still validating that AddRoundedRectangle(Rectangle, Size) produces a geometrically correct rounded rectangle. * Test issue: The VisibleClipBound(), VisibleClipBound_BigClip(), and Rotate() tests were failing on x86 Windows due to floating-point precision differences after RotateTransform(90). There are tiny epsilon differences (e.g., 1.9E-06 instead of exactly 0). The tests used exact Assert.Equal(0, rotclip.X) for values computed through rotation matrix transforms, which broke on x86. The same issue already existed on ARM (covered by IsArmOrArm64Process skip guards). Fix For all three tests: 1. Replaced exact equality (Assert.Equal(0, value)) with tolerance-based equality (Assert.Equal(0.0, value, 4)) for values computed after RotateTransform() — specifically the .X properties that should be 0 but may have tiny epsilon drift. Note that similar change was already done for verifying other points/lengths. 2. Removed the ARM skip guards (IsArmOrArm64Process + Skip(uint)) since the tolerance-based assertions now handle precision differences on all architectures (ARM, x86, x64). * Due to GDI+ changes in Windows 11 on x86, floating point overflow causes the value to change to Infinity instead of float.MaxValue. * Trigger PR update * Fix for remaining matrix tests which are also failing on x86 due to similar issue as Translation Matrix test.
Shyam-Gupta
added a commit
that referenced
this pull request
Feb 19, 2026
* Updating build agent image to use VS2026 VS2022 images have been deprecated this week and we need to move to VS2026. This change will need to be backported to servicing branches also. * Using scout images * The Form_SnapsRightAsync(Maximized) test failed because the Win+Z snap layout panel interaction was broken. The test used Win+Z to open the snap layout panel, then navigated with arrow keys to select the right-half snap position. However, each SendAsync(Form, params object[]) call invoked SetForegroundWindow on the form, which dismissed the snap layout panel before the arrow keys could navigate it. For maximized windows, the window remained maximized and the snap never occurred. Root Cause 1. SetForegroundWindow in SendAsync(Form, params object[]) dismissed the Win+Z snap layout panel before arrow keys could navigate it. 2. Win+Z snap panel keyboard navigation is fragile and varies across Windows versions, making it unreliable for automated testing. Fix: Replaced Win+Z + keyboard navigation with Win+Left/Win+Right shortcuts in both Form_SnapsLeftAsync(FormWindowState) and Form_SnapsRightAsync(FormWindowState). These shortcuts directly snap windows without requiring interaction with the snap layout panel, making the tests more reliable across Windows versions. * Test fix: Layout display names may include OS-specific suffixes e.g. "French" became "French (Legacy, AZERTY)" in Windows 11.0. Due to this reason we are using StartsWith instead of equality check for layout name. * Test fix for GraphicsPath_AddRoundedRectangle_Integer and GraphicsPath_AddRoundedRectangle_Float failure on x86. Issue: Old and new GDI+ are producing different number of points: 19 and 25 respectively for rounded rectangles' arcs. Fix Updated both tests to validate shape correctness rather than exact point sequences: 1. Point count: Assert that the count is one of the two valid values (19 or 25) 2. Bounding box: Verify the path bounds match the expected (10, 10, 20, 20) rectangle 3. Key coordinates: Verify the first point (top-right corner start at ~27.5, 10) and last point (top-left corner end at ~12.5, 10) are correct This makes the tests robust across different GDI+ implementations while still validating that AddRoundedRectangle(Rectangle, Size) produces a geometrically correct rounded rectangle. * Test issue: The VisibleClipBound(), VisibleClipBound_BigClip(), and Rotate() tests were failing on x86 Windows due to floating-point precision differences after RotateTransform(90). There are tiny epsilon differences (e.g., 1.9E-06 instead of exactly 0). The tests used exact Assert.Equal(0, rotclip.X) for values computed through rotation matrix transforms, which broke on x86. The same issue already existed on ARM (covered by IsArmOrArm64Process skip guards). Fix For all three tests: 1. Replaced exact equality (Assert.Equal(0, value)) with tolerance-based equality (Assert.Equal(0.0, value, 4)) for values computed after RotateTransform() — specifically the .X properties that should be 0 but may have tiny epsilon drift. Note that similar change was already done for verifying other points/lengths. 2. Removed the ARM skip guards (IsArmOrArm64Process + Skip(uint)) since the tolerance-based assertions now handle precision differences on all architectures (ARM, x86, x64). * Due to GDI+ changes in Windows 11 on x86, floating point overflow causes the value to change to Infinity instead of float.MaxValue. * Trigger PR update * Fix for remaining matrix tests which are also failing on x86 due to similar issue as Translation Matrix test.
Shyam-Gupta
added a commit
that referenced
this pull request
Feb 19, 2026
…e VS2026 (#14312) Backport from #14299 * Updating build agent image to use VS2026 VS2022 images have been deprecated this week and we need to move to VS2026. This change will need to be backported to servicing branches also. * Using scout images * The Form_SnapsRightAsync(Maximized) test failed because the Win+Z snap layout panel interaction was broken. The test used Win+Z to open the snap layout panel, then navigated with arrow keys to select the right-half snap position. However, each SendAsync(Form, params object[]) call invoked SetForegroundWindow on the form, which dismissed the snap layout panel before the arrow keys could navigate it. For maximized windows, the window remained maximized and the snap never occurred. Root Cause 1. SetForegroundWindow in SendAsync(Form, params object[]) dismissed the Win+Z snap layout panel before arrow keys could navigate it. 2. Win+Z snap panel keyboard navigation is fragile and varies across Windows versions, making it unreliable for automated testing. Fix: Replaced Win+Z + keyboard navigation with Win+Left/Win+Right shortcuts in both Form_SnapsLeftAsync(FormWindowState) and Form_SnapsRightAsync(FormWindowState). These shortcuts directly snap windows without requiring interaction with the snap layout panel, making the tests more reliable across Windows versions. * Test fix: Layout display names may include OS-specific suffixes e.g. "French" became "French (Legacy, AZERTY)" in Windows 11.0. Due to this reason we are using StartsWith instead of equality check for layout name. * Test fix for GraphicsPath_AddRoundedRectangle_Integer and GraphicsPath_AddRoundedRectangle_Float failure on x86. Issue: Old and new GDI+ are producing different number of points: 19 and 25 respectively for rounded rectangles' arcs. Fix Updated both tests to validate shape correctness rather than exact point sequences: 1. Point count: Assert that the count is one of the two valid values (19 or 25) 2. Bounding box: Verify the path bounds match the expected (10, 10, 20, 20) rectangle 3. Key coordinates: Verify the first point (top-right corner start at ~27.5, 10) and last point (top-left corner end at ~12.5, 10) are correct This makes the tests robust across different GDI+ implementations while still validating that AddRoundedRectangle(Rectangle, Size) produces a geometrically correct rounded rectangle. * Test issue: The VisibleClipBound(), VisibleClipBound_BigClip(), and Rotate() tests were failing on x86 Windows due to floating-point precision differences after RotateTransform(90). There are tiny epsilon differences (e.g., 1.9E-06 instead of exactly 0). The tests used exact Assert.Equal(0, rotclip.X) for values computed through rotation matrix transforms, which broke on x86. The same issue already existed on ARM (covered by IsArmOrArm64Process skip guards). Fix For all three tests: 1. Replaced exact equality (Assert.Equal(0, value)) with tolerance-based equality (Assert.Equal(0.0, value, 4)) for values computed after RotateTransform() — specifically the .X properties that should be 0 but may have tiny epsilon drift. Note that similar change was already done for verifying other points/lengths. 2. Removed the ARM skip guards (IsArmOrArm64Process + Skip(uint)) since the tolerance-based assertions now handle precision differences on all architectures (ARM, x86, x64). * Due to GDI+ changes in Windows 11 on x86, floating point overflow causes the value to change to Infinity instead of float.MaxValue. * Trigger PR update * Fix for remaining matrix tests which are also failing on x86 due to similar issue as Translation Matrix test.
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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.
VS2022 images have been deprecated this week, and we need to move to VS2026. This change will need to be backported to servicing branches also.
The new images are deployed on Win11 OS, which was causing some test failures due to OS changes. There are no product issues. Details:
The Form_SnapsRightAsync test failed because the Win+Z snap layout panel interaction was broken. The test used Win+Z to open the snap layout panel, then navigated with arrow keys to select the right-half snap position. However, each SendAsync(Form, params object[]) call invoked SetForegroundWindow on the form, which dismissed the snap layout panel before the arrow keys could navigate it. For maximized windows, the window remained maximized and the snap never occurred.
Root Cause
SetForegroundWindow in SendAsync(Form, params object[]) dismissed the Win+Z snap layout panel before arrow keys could navigate it.
Win+Z snap panel keyboard navigation is fragile and varies across Windows versions, making it unreliable for automated testing.
Fix: Replaced Win+Z + keyboard navigation with Win+Left/Win+Right shortcuts in both Form_SnapsLeftAsync(FormWindowState) and Form_SnapsRightAsync(FormWindowState). These shortcuts directly snap windows without requiring interaction with the snap layout panel, making the tests more reliable across Windows versions.
InputLanguage_InputLanguageLayoutId_Expected test for French:
Layout display names may include OS-specific suffixes e.g. "French" became "French (Legacy, AZERTY)" in Windows 11.0. Due to this reason we are using StartsWith instead of equality check for layout name.
Matrix manipulation tests
A bunch of Matrix manipulation tests were failing on x86 platform due to underlying GDI+ changes. Reason was that on floating point overflow, the value now becomes Float.PositiveInfinity instead of Float.MaxValue.
Microsoft Reviewers: Open in CodeFlow