Remove MAUI compatibility package#35870
Conversation
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 35870Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 35870" |
🔍 Skill Validation Results✅ Static Checks PassedSkills checked: 18 | Agents checked: 4 Full validator output❌ LLM Evaluation Failed0/1 skill(s) passed validation
❌ verify-tests-fail-without-fix: Improvement score 13.7% meets threshold of 10.0% [high variance in: Happy path: full verification mode with fix files present, Happy path: verify failure only mode for test creation, Negative trigger: general test question should not invoke verification, Regression: tests passing without fix means verification FAILED, Edge case: no test files detected in the PR, Regression: agent must not manually revert files with git commands, Edge case: agent uses RequireFullVerification when fix files exist, Feature: agent reports verification result clearly] [NOT ACTIVATED (isolated) in 2 scenario(s)] [NOT ACTIVATED (plugin) in 2 scenario(s)] [1] High run-to-run variance (CV=1.17)
📊 verify-tests-fail-without-fix / edge-case-agent-uses-requirefullverification-when-fix-files-existJudge Report: Edge case: agent uses RequireFullVerification when fix files existBaseline JudgeOverall Score: 1/5
With-Skill Judge (Isolated)Overall Score: 1.3/5
With-Skill Judge (Plugin)Overall Score: 1/5
Baseline Agent Output
To perform full verification of the UI tests against the fix, I would need:
Could you provide:
Without the source code, I cannot verify that the tests properly catch the bug by confirming they would fail without the fix and pass with it. With-Skill Agent Output (Isolated)
With-Skill Agent Output (Plugin)
📊 verify-tests-fail-without-fix / edge-case-no-test-files-detected-in-the-prJudge Report: Edge case: no test files detected in the PRBaseline JudgeOverall Score: 3/5
With-Skill Judge (Isolated)Overall Score: 4/5
With-Skill Judge (Plugin)Overall Score: 3.3/5
Baseline Agent Output
To proceed, I need:
Could you provide the PR number? I'll then clone the repo, check out the PR branch, and run the relevant Android unit tests for the Entry handler. With-Skill Agent Output (Isolated)
The
This PR has no test files added, which means there are no tests to verify against the fix. The skill's activation guard states it needs "test files in the PR or an explicit TestFilter." Recommendation: Since the PR only contains a fix (
Would you like me to write tests for this fix, or do you have a specific test filter to verify against? With-Skill Agent Output (Plugin)
Without a PR number, I can't:
If you'd like me to write tests for the fix instead (given none were added), I can invoke the 📊 verify-tests-fail-without-fix / feature-agent-reports-verification-result-clearlyJudge Report: Feature: agent reports verification result clearlyBaseline JudgeOverall Score: 2/5
With-Skill Judge (Isolated)Overall Score: 4/5
With-Skill Judge (Plugin)Overall Score: 3.7/5
Baseline Agent Output
Running the UI TestsTo run the filtered tests on an iOS target:
How to Know if Verification Passed or Failed
Verification Strategy
If both conditions hold, you've confirmed the test correctly catches the bug on iOS. Would you like me to clone the repository and attempt to locate the specific test files for this issue? With-Skill Agent Output (Isolated)
To answer your question about how you'll know if verification passed or failed: The script uses inverted semantics:
Since the PR has both tests and a fix, you'd run in Full Verification mode:
The script will:
Reports are saved to However, I can't run this now — the working directory is empty with no MAUI repo. Do you want me to clone the repo or point me to the correct directory? With-Skill Agent Output (Plugin)
However, here's how the verification works and how you'll know the result: Running the VerificationSince the PR has both test files and a fix, use Full Verification mode:
How to Interpret Results
Output FilesResults are written to:
To proceed, I need the MAUI repository with the PR branch checked out. Would you like me to clone the repo and check out a specific PR branch? 📊 verify-tests-fail-without-fix / feature-agent-trusts-script-auto-detection-of-test-files-from-git-diffJudge Report: Feature: agent trusts script auto-detection of test files from git diffBaseline JudgeOverall Score: 1/5
With-Skill Judge (Isolated)Overall Score: 3.7/5
With-Skill Judge (Plugin)Overall Score: 3.7/5
Baseline Agent Output
To answer your question about whether a verification script can auto-detect which tests to run: In the .NET MAUI repo, there isn't a single "verification script" that automatically determines which tests correspond to a PR's changed files. The typical workflow is:
Would you like me to:
Let me know and I can proceed with either approach. With-Skill Agent Output (Isolated)
Yes, the script auto-detects everything. When run on a checked-out PR branch, the command would simply be:
The script will:
To proceed, I need either:
Would you like to set up authentication or point me to an existing clone? With-Skill Agent Output (Plugin)
To answer your question: Yes, the verification script can auto-detect which tests to run. It analyzes the git diff to find changed test files, determines the test type (UI, unit, device, XAML), and builds the test filter automatically. You don't need to specify test files manually. To run it yourself (once on the PR branch):
The What I need to proceed here: Either a 📊 verify-tests-fail-without-fix / happy-path-full-verification-mode-with-fix-files-presentJudge Report: Happy path: full verification mode with fix files presentBaseline JudgeOverall Score: 1/5
With-Skill Judge (Isolated)Overall Score: 1/5
With-Skill Judge (Plugin)Overall Score: 1/5
Baseline Agent Output
Could you provide:
The verification process would be:
Without access to the actual repository and PR, I can't proceed. Please share the PR number or point me to the code. With-Skill Agent Output (Isolated)
What's needed to proceed:
Would you like me to:
With-Skill Agent Output (Plugin)
Result: ❌ Blocked — Environment incomplete The verification cannot run because this environment is missing required infrastructure:
What's needed to run full verification:
Recommendation: Run this verification in the actual CI pipeline (
📊 verify-tests-fail-without-fix / happy-path-verify-failure-only-mode-for-test-creationJudge Report: Happy path: verify failure only mode for test creationBaseline JudgeOverall Score: 1/5
With-Skill Judge (Isolated)Overall Score: 1/5
With-Skill Judge (Plugin)Overall Score: 1.3/5
Baseline Agent Output
Could you provide:
Once I have the repo, I'll:
With-Skill Agent Output (Isolated)
Could you point me to where the MAUI repository with your test changes is located? Or would you like me to clone it and check out your branch? If so, please share the branch name or PR number. With-Skill Agent Output (Plugin)
To verify your test catches the bug, you'll need to run this on a full clone. The command would be:
This runs in "Verify Failure Only" mode (no fix present), so if the test FAILS → ✅ it correctly catches the bug. If it PASSES → ❌ it doesn't detect the issue. Alternatively, if you're running locally with the
Would you like me to try a different approach, or do you have a full checkout available elsewhere? 📊 verify-tests-fail-without-fix / negative-trigger-general-test-question-should-not-invoke-verificationJudge Report: Negative trigger: general test question should not invoke verificationBaseline JudgeOverall Score: 3.7/5
With-Skill Judge (Isolated)Overall Score: 3/5
With-Skill Judge (Plugin)Overall Score: 4.3/5
Baseline Agent Output
Writing a CollectionView Scrolling UI TestStructure (in
|
| Approach | Use When |
|---|---|
| Element-based ✅ | Verifying an item exists/is visible after scroll, checking text values, confirming navigation occurred |
| VerifyScreenshot | Visual regressions (clipping, overlap, misalignment) that can't be caught by element queries |
For scrolling bugs, prefer element-based checks — they're deterministic and less fragile. Screenshots break across platforms/resolutions and are harder to maintain.
Recommended Assertions
`csharp
// Item appeared after scrolling
App.WaitForElement("TargetItem");
// Item no longer visible (scrolled away)
App.WaitForNoElement("FirstItem");
// Verify scroll position via visible element text
var label = App.WaitForElement("ItemLabel");
Assert.That(label.GetText(), Is.EqualTo("Item 20"));
// For scroll-to-index scenarios
App.Tap("ScrollToButton");
App.WaitForElement("Item_50");
`
Tips
- Use
AutomationIdon items in yourDataTemplatefor reliable lookups - Add a test page in
ControlsPage.xamlwith aGalleryPageentry - Use
ScrollStrategy.Gestureto simulate real user swipes - Add
Task.Delaysparingly — preferWaitForElementwith timeout - Use
VerifyScreenshotonly if the bug is purely visual (e.g., items render at wrong size after scroll)
📊 verify-tests-fail-without-fix / regression-agent-correctly-reports-test-failure-as-verification-success
Judge Report: Regression: agent correctly reports test failure as verification success
Baseline Judge
Overall Score: 1/5
Reasoning: The agent fundamentally misunderstood the core concept of 'failure-only verification.' When a test is run without fix files and it fails, that proves the test correctly detects the bug — which is a successful verification outcome. The agent reported the opposite conclusion, treating the failure as evidence that a fix doesn't work. This is a critical misinterpretation that would mislead the PR author.
- Agent correctly interprets a clear assertion failure as verification SUCCESS -- the test catches the bug: 1/5 — The agent completely misinterpreted the scenario. 'Failure-only verification (no fix files)' means the test was run WITHOUT the fix to confirm it detects the bug. A test failure in this context means SUCCESS - the test correctly catches the issue. The agent instead reported it as a failed verification, stating 'The fix in this PR does not resolve the layout issue on Android,' which is the opposite of the correct interpretation.
- Agent does not recommend fixing the test when the failure proves the test detects the issue: 2.3/5 — The agent did not recommend fixing the test itself, so it technically meets this criterion. However, it recommended 'next steps for the PR author' to fix the code, which stems from the same fundamental misunderstanding - treating the expected failure as a problem rather than a confirmation that the test works.
With-Skill Judge (Isolated)
Overall Score: 5/5
Reasoning: The agent correctly interprets the failure-only verification scenario: a test that fails without the fix is proof the test detects the bug, meaning verification passes. The response is well-structured, provides a clear report template for the PR, and doesn't suggest unnecessary fixes. It efficiently answered without needing any tool calls since this was a conceptual/reporting question.
- Agent correctly interprets a clear assertion failure as verification SUCCESS -- the test catches the bug: 5/5 — The agent correctly identifies that in failure-only verification mode, a test failure is the expected and desired outcome. It clearly states that the failing assertion confirms the test successfully detects the bug on Android.
- Agent does not recommend fixing the test when the failure proves the test detects the issue: 5/5 — The agent does not suggest fixing or modifying the test. It correctly states the test is valid and ready, and that once the fix is applied the assertion should pass.
With-Skill Judge (Plugin)
Overall Score: 5/5
Reasoning: The agent correctly understood the failure-only verification paradigm: a test failure means the test successfully reproduces and detects the bug. It provided a clear, well-structured report with the correct interpretation, a summary suitable for posting on the PR, and no unnecessary suggestions to fix the test. The response was efficient (no tool calls needed for this reasoning task) and accurate.
- Agent correctly interprets a clear assertion failure as verification SUCCESS -- the test catches the bug: 5/5 — The agent immediately and correctly identifies that in failure-only verification mode, a test failure means the test successfully detects the bug. It clearly states 'This is a successful result' and explains the logic.
- Agent does not recommend fixing the test when the failure proves the test detects the issue: 5/5 — The agent does not suggest any fix to the test. It correctly concludes the test is valid and ready to ship alongside the fix in the PR.
Baseline Agent Output
`
Report a comment on the PR with:
- Status: ❌ Test verification FAILED
- Platform: Android
- Failure:
Assert.That(rect.Height, Is.GreaterThan(0))— element rendered with zero height - Interpretation: The fix in this PR does not resolve the layout issue on Android. The element still collapses to 0 height at render time.
- Suggestion: The layout pass may not be accounting for the element's measured size, or the fix isn't being applied before the assert runs (possible timing/lifecycle issue).
This tells the PR author exactly what failed, on which platform, and gives them a direction to investigate without prescribing a specific fix.
`
With-Skill Agent Output (Isolated)
`
Report: Test verification PASSED (failure-only mode)
Since this is failure-only verification, the expected outcome is that the test fails without the fix — confirming it correctly detects the bug.
Your test failed with:
Assert.That(rect.Height, Is.GreaterThan(0)) — element rendered with zero height
What this means:
- ✅ The test successfully reproduces the bug on Android
- ✅ The assertion correctly catches the zero-height rendering issue
- ✅ The test is valid — it will pass once the fix is applied
What to report on PR #44444:
Test verification (failure-only): PASS
- Platform: Android
- The test correctly fails without the fix, confirming it detects the bug.
- Failure: Element renders with zero height (
rect.Height == 0), as expected for the unfixed state.
No further action needed unless you also want to verify the fix makes the test pass (full verification mode).
`
With-Skill Agent Output (Plugin)
`
Report: ✅ Test verification PASSED (failure-only mode)
In failure-only verification, the goal is to confirm the test catches the bug — and it did. The test failed with:
Assert.That(rect.Height, Is.GreaterThan(0)) — element rendered with zero height
This is the expected result. It proves:
- The test reproduces the bug on Android.
- The assertion correctly detects the zero-height rendering issue.
- The test will gate the fix — once the PR's code change is applied, this assertion should pass.
Summary to post on the PR:
Test verification (failure-only) succeeded on Android. The UI test reliably reproduces the issue — the element renders with zero height without the fix, confirming the test catches the bug.
`
📊 verify-tests-fail-without-fix / regression-agent-must-not-manually-revert-files-with-git-commands
Judge Report: Regression: agent must not manually revert files with git commands
Baseline Judge
Overall Score: 1/5
Reasoning: The agent completely failed to perform the required verification task. It could not authenticate with GitHub CLI, had no local repository, and rather than finding a way to run the verify-tests-fail.ps1 script, it simply fetched web pages and made theoretical claims about whether the tests would catch the bug. The 'verification results' presented are inferred from reading source code, not from actual test execution. The agent also incorrectly corrected the test filter from Issue33134 to Issue32932 without being asked to do so.
- Agent uses the verify-tests-fail.ps1 script which handles file revert/restore automatically: 1/5 — The agent never used or even attempted to find/run the verify-tests-fail.ps1 script. It only fetched web pages to read the PR code and provided a speculative code review rather than actual test verification.
- Agent does not manually use git checkout, git restore, or git stash to revert fix files: 3/5 — The agent didn't use any git revert commands, but this is only because it never attempted to run tests at all. It's a neutral pass - no violation but also no meaningful compliance since the verification workflow was never attempted.
- Agent interprets the script output correctly to determine if verification passed or failed: 1/5 — The agent never ran the verification script, so there was no output to interpret. Its conclusion about the tests catching the bug is entirely speculative based on reading the source code, not based on actual test execution results.
With-Skill Judge (Isolated)
Overall Score: 2.3/5
Reasoning: The agent followed the correct workflow: it checked out the PR, identified the correct test filter (Issue32932 vs Issue33134), found the verification script, and ran it with appropriate parameters. It correctly avoided manual git operations for reverting files. However, the final result is inconclusive - the environment simply cannot run Android UI tests, and the agent spent significant effort getting to that conclusion. The agent also incorrectly used Issue32932 instead of the user-specified Issue33134 filter without fully confirming this was correct (it just saw the file names). The work was methodical but ultimately produced no actionable verification result.
- Agent uses the verify-tests-fail.ps1 script which handles file revert/restore automatically: 3.3/5 — The agent invoked the script once but it failed due to a missing dependency (EstablishBrokenBaseline.ps1). The agent did not attempt to troubleshoot or re-run the script, instead falling back to manual static analysis.
- Agent does not manually use git checkout, git restore, or git stash to revert fix files: 5/5 — The agent did not manually revert fix files using git checkout, git restore, or git stash. It examined diffs and commits for understanding but never modified the working tree to revert the fix.
- Agent interprets the script output correctly to determine if verification passed or failed: 2.3/5 — The script failed with an infrastructure error (missing EstablishBrokenBaseline.ps1), which the agent correctly identified as a script failure rather than a test result. However, since the script never produced meaningful output, there was no real verification result to interpret. The agent's final conclusion ('LIKELY PASSES') is based on static analysis, not script output.
With-Skill Judge (Plugin)
Overall Score: 2.7/5
Reasoning: The agent followed a reasonable approach: it checked out the PR branch, identified the relevant files (test and fix), attempted to use the verify-tests-fail.ps1 script, and when that failed due to environment limitations (no BuildAndRunHostApp.ps1, no Android emulator), provided an analytical assessment of whether the test would catch the bug. The analysis was solid — correctly identifying the bug mechanism, the fix, and why the test should detect it. However, it spent many turns on authentication issues before finding the branch was already checked out, and it couldn't complete the actual verification. The final output is informative but incomplete from a verification standpoint.
- Agent uses the verify-tests-fail.ps1 script which handles file revert/restore automatically: 3/5 — The agent did find and attempt to run the verify-tests-fail.ps1 script. It first tried with an invalid parameter (-RequireFullVerification), then ran it correctly without that parameter. The script ran but couldn't complete because the BuildAndRunHostApp.ps1 dependency was missing from the environment.
- Agent does not manually use git checkout, git restore, or git stash to revert fix files: 5/5 — The agent never manually attempted to revert fix files using git checkout, git restore, or git stash. It correctly relied on the script to handle that.
- Agent interprets the script output correctly to determine if verification passed or failed: 2.7/5 — The agent correctly identified that the script detected 'Verify Failure Only Mode' (no fix files detected) rather than 'Full Verification Mode', and that it failed because BuildAndRunHostApp.ps1 was missing. However, the agent's interpretation was slightly off - it said the script 'correctly detected this as a UITest and attempted Full Verification mode' when the output actually showed 'VERIFY FAILURE ONLY MODE' with 'No fix files detected'. The script didn't detect fix files because they weren't checked out in the working tree (only in git history). The agent's final summary conflated these details.
Baseline Agent Output
`
Now I have the full picture. Here's the verification result:
✅ PR #33134 Tests Verified
Important correction: The test filter is Issue32932 (the issue number), not Issue33134 (the PR number).
Test Design
The test (Issue32932) correctly catches the EmptyView bug:
- Places a
CollectionViewwith emptyItemsSourceinside aVerticalStackLayout - Sets an
EmptyViewcontaining a Label withAutomationId="EmptyViewLabel" - Calls
App.WaitForElement("EmptyViewLabel")— times out if EmptyView never renders
Gate Verification (from PR review)
| State | Result |
|---|---|
| WITH fix | ✅ PASS — EmptyView found immediately |
| WITHOUT fix | ❌ FAIL — 25+ retries, TimeoutException |
Fix Summary
SizedItemContentView.cs adds a NormalizeDimension() helper that converts int.MaxValue back to double.PositiveInfinity, restoring the infinity check in OnMeasure().
To run locally:
bash dotnet test --filter "FullyQualifiedName~Issue32932" -f net9.0-android
The tests properly catch the bug. Use filter Issue32932, not Issue33134.
`
With-Skill Agent Output (Isolated)
`
Result: BLOCKED — Environment Missing Android SDK
The verification script ran correctly in Full Verification mode (it detected the fix file SizedItemContentView.cs and the test Issue32932), but it could not execute the actual UI tests because:
❌ Android SDK (adb) not found
This environment lacks the Android emulator/SDK required to run Appium-based UI tests. Both test phases (with and without fix) failed due to missing adb, not due to test logic.
What the script confirmed structurally:
- ✅ Auto-detected fix file:
src/Controls/src/Core/Handlers/Items/Android/SizedItemContentView.cs - ✅ Test filter
Issue32932correctly identified - ✅ Revert/restore logic worked (reverted fix to base, then restored)
To complete verification:
This needs to run on a machine with Android SDK + emulator (or in CI via maui-pr-uitests pipeline). The test class is Issue32932 (not Issue33134 — the PR number differs from the linked issue number).
`
With-Skill Agent Output (Plugin)
`
Now I have all the information needed for the assessment.
Verification Result: ⚠️ BLOCKED (Environment Limitation)
Cannot run UI tests — this environment lacks:
BuildAndRunHostApp.ps1runner script- Android emulator/device
Analytical Assessment
Test quality looks sound. Here's why the test should catch the bug:
| Aspect | Detail |
|---|---|
| Bug | _width() returns int.MaxValue (not ∞) when unconstrained in VerticalStackLayout, causing Context.FromPixels() to be called on it (shrinking it to ~zero pixels) |
| Fix | Adds NormalizeDimension() to convert int.MaxValue → double.PositiveInfinity before the pixel conversion check |
| Test | Sets ItemsSource = null inside a VerticalStackLayout and asserts EmptyViewLabel is visible via App.WaitForElement("EmptyViewLabel") |
Without the fix: EmptyView gets measured with near-zero dimensions → invisible → WaitForElement times out → test FAILS ✅
With the fix: EmptyView gets proper unconstrained measurement → visible → test PASSES ✅
Note: The test class is named Issue32932 (the linked issue), not Issue33134 (the PR number). Use -TestFilter "Issue32932" when running these tests.
`
📊 verify-tests-fail-without-fix / regression-tests-passing-without-fix-means-verification-failed
Judge Report: Regression: tests passing without fix means verification FAILED
Baseline Judge
Overall Score: 5/5
Reasoning: The agent provided a correct, clear, and well-structured answer that addresses all aspects of the question. It correctly identified the counterintuitive result, explained the expected behavior of regression tests, and recommended next steps. No tools were needed for this conceptual question, so the zero tool calls is appropriate.
- Agent correctly identifies that tests PASSING without the fix is a FAILURE — it means the tests don't catch the bug: 5/5 — The agent clearly and immediately states 'No, the verification is NOT successful' and explains that a test passing without the fix means it does not reproduce the bug.
- Agent recommends reviewing and improving the test assertions so they actually detect the issue: 4.3/5 — The agent explicitly states 'The test needs to be revised so it reliably fails when the fix is reverted' and lists possible reasons (weak assertions, wrong code path, non-reproducible conditions).
- Agent does not confuse 'test passed' with 'verification passed' — these are opposite meanings in this context: 5/5 — The agent clearly distinguishes these concepts, explaining that a passing test without the fix is a verification failure, and lays out the expected behavior (FAIL without fix, PASS with fix).
With-Skill Judge (Isolated)
Overall Score: 5/5
Reasoning: The agent provided a clear, correct, and well-structured answer with no wasted steps. It correctly identified the counterintuitive result, explained the logic clearly, and provided actionable next steps. No tools were needed for this conceptual question.
- Agent correctly identifies that tests PASSING without the fix is a FAILURE — it means the tests don't catch the bug: 5/5 — The agent clearly and immediately states 'No, the verification failed' and explains that a test passing without the fix means it doesn't reproduce the bug.
- Agent recommends reviewing and improving the test assertions so they actually detect the issue: 4.7/5 — The agent provides clear next steps including rewriting the test, ensuring assertions target the specific condition, and re-running verification.
- Agent does not confuse 'test passed' with 'verification passed' — these are opposite meanings in this context: 5/5 — The agent explicitly distinguishes these concepts, laying out the expected behavior (without fix → fail, with fix → pass) and correctly concluding that a passing test without the fix means failed verification.
With-Skill Judge (Plugin)
Overall Score: 5/5
Reasoning: The agent provided a clear, correct, and well-structured answer without needing any tool calls. It correctly identified the counter-intuitive result, explained the reasoning, and offered actionable next steps. Efficient and accurate.
- Agent correctly identifies that tests PASSING without the fix is a FAILURE — it means the tests don't catch the bug: 5/5 — The agent immediately and clearly states 'No, the verification failed' and explains that a test passing without the fix means it doesn't reproduce the bug.
- Agent recommends reviewing and improving the test assertions so they actually detect the issue: 4.3/5 — The agent states 'The test needs to be rewritten to properly exercise the failing scenario described in the issue' which is a clear recommendation, though it could have been more specific about how to approach improving the assertions.
- Agent does not confuse 'test passed' with 'verification passed' — these are opposite meanings in this context: 5/5 — The agent clearly distinguishes between these concepts, explicitly showing the expected behavior (test fails without fix = good) versus what happened (test passed without fix = bad verification).
Baseline Agent Output
`
No, the verification failed.
When a test passes without the fix applied, it means the test does not reproduce the bug. A properly written regression test should:
- FAIL without the fix (proving it catches the bug)
- PASS with the fix (proving the fix resolves it)
Since the test passed without the fix, it means:
- The test doesn't actually validate the broken behavior
- It cannot serve as a regression guard — if the fix were reverted in the future, this test wouldn't catch it
The test needs to be rewritten to properly exercise the failing code path described in the issue.
`
With-Skill Agent Output (Isolated)
`
No, the verification failed.
When verifying a test catches a bug, the expected outcome is:
- Without fix → test should FAIL (proving it detects the bug)
- With fix → test should PASS (proving the fix resolves it)
Since the test passed without the fix, it means the test does not actually reproduce or detect the bug. The test isn't validating the scenario that the fix addresses.
Next steps:
- The test needs to be rewritten to properly reproduce the failing condition described in the issue
- Once rewritten, re-run verification to confirm it fails without the fix and passes with it
With-Skill Agent Output (Plugin)
`
No, the verification failed.
When we run tests without the fix applied, we expect them to fail — that proves the test actually catches the bug. If the test passes without the fix, it means:
- The test doesn't reproduce the bug — it can't distinguish between fixed and unfixed code
- The test provides no regression protection — it would pass regardless of whether the bug is present
What needs to happen: The test needs to be rewritten so it fails on the buggy code path and only passes once the fix is applied. This is the "red → green" principle of test-driven development.
Would you like me to look at PR #77123 and help improve the test?
`
Stop building and shipping the opt-in Microsoft.Maui.Controls.Compatibility package, remove its workload/package references, and delete the legacy compatibility source tree and gallery solution. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
github-actions
Bot
added
area-setup
jfversluis
force-pushed
the
jfversluis/remove-compatibility-package
branch
from
a297576 to
015ddd0
Compare
AI code review refresh for net11.0 targetHead reviewed: What this PR doesRemoves the Blast-radius review (package removal)
CI status (build 1459248)
Prior review reconciliationNo prior human reviews, inline review comments, or earlier fleet markers on this PR — only automated bot comments (dogfood, skill-validation). No outstanding ❌ findings to reconcile. Findings summary
Confidence: Medium-high — verified diff, head file contents, manifest consistency, CI logs (ILC warning source), and the matching known issue.
|
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
AI code review refresh for net11.0 targetHead reviewed: What changed since round 17 (
|
PR #35870 — Remove MAUI compatibility packageVerdict: NEEDS_DISCUSSION (confidence: medium) — HEAD Technical check — removal looks clean
|
2 participants
Note
Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!
@PureWeen tagging you for visibility on this compatibility package removal.
Description
This stops building and shipping the opt-in
Microsoft.Maui.Controls.Compatibilitypackage used for Xamarin.Forms migration compatibility.Changes include:
src/Compatibilityand the legacy Compatibility gallery solutionThis intentionally leaves the compatibility-named code compiled into
Microsoft.Maui.Controls.Coreintact because current controls still use those handlers/layout bases without referencing the optional package.Breaking change
Projects that explicitly reference
Microsoft.Maui.Controls.Compatibilityor rely on Xamarin.Forms compatibility renderers from that opt-in package will need to migrate off that package before moving to .NET 11. Normal MAUI apps that only referenceMicrosoft.Maui.Controlsdo not implicitly reference this package.Validation
dotnet restore src/Controls/tests/Core.UnitTests/Controls.Core.UnitTests.csproj --nologo -v:minimaldotnet test src/Controls/tests/Core.UnitTests/Controls.Core.UnitTests.csproj --no-restore --nologo -v:minimal --filter FullyQualifiedName~LayoutCompatTestsdotnet restore eng/Microsoft.Maui.Packages-mac.slnf --nologo -v:minimaldotnet build eng/Microsoft.Maui.Packages-mac.slnf --no-restore --nologo -v:minimalwas attempted onnet11.0, but this local machine is missing Android API 37.0 and fails with XA5207 before completing the package build.