[ci-fix-net11] Remove obsolete UseWebAssemblyDebugging from Blazor solution template (refs #36846)

[github-actions]

Workflow artifact: ci-fix
Artifact kind: fix
Refs: #36846
Target branch: net11.0
Attempt: 1/10

Attempt 1 of 10

Remove the obsolete app.UseWebAssemblyDebugging() call (and its companion inspectUri debug config) from the Blazor Web solution template so the generated project builds clean on .NET 11.

Root cause

The maui-blazor-solution template's MauiApp.1.Web/Program.cs and Program.Main.cs emitted app.UseWebAssemblyDebugging(); inside the #if (UseWebAssembly) development block, and Properties/launchSettings.json set the matching inspectUri. UseWebAssemblyDebugging() is obsolete as of .NET 11 and surfaces as build diagnostic ASPDEPR011, breaking dotnet new template builds for WebAssembly configurations (repro builds 1528586 / 1528665).

Fix

Removed the UseWebAssemblyDebugging() call from both Program.cs and Program.Main.cs. Because WebAssembly no longer contributes any development-only pipeline step, the guard is narrowed from #if (UseWebAssembly || IndividualLocalAuth) to #if (IndividualLocalAuth), preserving the existing UseMigrationsEndPoint() behavior for the Individual Local Auth configuration and the else/non-development branch for all others. The obsolete inspectUri entries were removed from both http and https launch profiles. This mirrors the equivalent change in the ASP.NET Core .NET 11 Blazor Web templates.

What is unverified / where I need help

• Full dotnet new template instantiation + build across every parameter permutation (UseWebAssembly x IndividualLocalAuth x http/https/LocalhostTld) was not run in this environment; CI template integration tests should exercise these.
• Please confirm no remaining WebAssembly debugging affordance is expected in the generated project for .NET 11.

Validation

• Command: not run because template instantiation/build is exercised by CI integration tests, not locally available here
• Result: not run

Evidence

• Original failing builds (from tracking issue): https://dev.azure.com/dnceng-public/public/_build/results?buildId=1528586 and https://dev.azure.com/dnceng-public/public/_build/results?buildId=1528665

---

Filed by ci-status-fix-net11. This is the single PR for #36846: the workflow watches its own CI and pushes up to 10 attempts on this same PR (it never opens a second PR). It advances only when the fix's own build settles red and that red is caused by the fix. In round 1 a maintainer still needs to comment /azp run maui-pr to exercise the new commit.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by CI Failure Fixer (net11.0) · 440.2 AIC · ⌖ 19.6 AIC · ⊞ 3.7K · ◷

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

[github-actions]

♻️ Attempt 1/10: the red on this PR is unrelated flake, not caused by this fix, on 06dc002103fc0faff40d3eb18bf1fcbd5199615f (buildId 1529150):

• Build macOS (Debug) / Build Windows (Release) — SDK-resolver/provisioning failures (MSB4276: ... Microsoft.Build.NoTargets ... sdk/10.0.100 ... did not exist), an environment/setup issue.
• Samples macOS / Samples windows — MAUIG2045 source-generator binding errors in Controls.Sample (ListViewPage.xaml, CompatibilityPage.xaml), pre-existing and unrelated to Blazor templates.
• Windows Helix Unit Tests (Debug/Release) — unrelated unit-test legs.

The original ASPDEPR011 / UseWebAssemblyDebugging signature is absent from every failing leg, and the Blazor template legs (Blazor macOS, Blazor windows) both succeeded. A maintainer re-run (/azp run maui-pr) should clear the unrelated red.

_{Automated CI-fix note.}

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by CI Failure Fixer (net11.0) · 422.2 AIC · ⌖ 9.95 AIC · ⊞ 3.7K · ◷

[github-actions]

🎯 Target test validated green on 06dc002103fc0faff40d3eb18bf1fcbd5199615f — the BlazorTemplateTest.BuildMauiBlazorWebSolution variants passed on ALL platforms they run on (Blazor macOS, Blazor windows legs, buildId 1529150). The remaining red is unrelated flake on the Build/Samples/Helix legs (SDK-resolver provisioning + pre-existing MAUIG2045 source-gen errors in Controls.Sample) — not caused by this fix. Transitioning this PR from draft to ready for review and adding p/0; a maintainer still reviews and merges.

_{Automated CI-fix readiness gate.}

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by CI Failure Fixer (net11.0) · 422.2 AIC · ⌖ 9.95 AIC · ⊞ 3.7K · ◷

[github-actions]

BlazorTemplateTest.BuildMauiBlazorWebSolution variants validated green on all platforms they run (Blazor macOS + Blazor windows legs) on head 06dc002 (buildId 1529150); remaining red is unrelated flake.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by CI Failure Fixer (net11.0) · 422.2 AIC · ⌖ 9.95 AIC · ⊞ 3.7K

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

[MauiBot]

AI Review Summary

@github-actions[bot] — new AI review results are available based on this last commit: 06dc002.

---

🗂️ Review Sessions — click to expand

🚦 Gate — Test Before & After Fix

Gate Result: ⚠️ SKIPPED

No tests were detected in this PR.

Recommendation: Add tests to verify the fix using the write-tests-agent.

---

📋 Pre-Flight — Context & Validation

Issue: #36846 - [ci-scan-net11] [CI] Blazor solution template tests fail with ASPDEPR011 for obsolete UseWebAssemblyDebugging
PR: #36855 - [ci-fix-net11] Remove obsolete UseWebAssemblyDebugging from Blazor solution template (refs #36846)
Platforms Affected: windows, macOS template integration legs; testing platform requested: windows
Files Changed: 3 implementation/template files, 0 test files

Key Findings

• Issue [ci-scan-net11] [CI] Blazor solution template tests fail with ASPDEPR011 for obsolete UseWebAssemblyDebugging #36846 reports .NET 11 Blazor solution template integration failures (BlazorTemplateTest.BuildMauiBlazorWebSolution) caused by ASPDEPR011 from generated UseWebAssemblyDebugging() calls and matching inspectUri launch profile entries.
• PR [ci-fix-net11] Remove obsolete UseWebAssemblyDebugging from Blazor solution template (refs #36846) #36855 changes only src/Templates/src/templates/maui-blazor-solution/MauiApp.1.Web/Program.cs, Program.Main.cs, and Properties/launchSettings.json.
• The PR's fix removes UseWebAssemblyDebugging() from both generated program variants, removes inspectUri from both launch profiles, and narrows the development exception/migration branch from UseWebAssembly || IndividualLocalAuth to IndividualLocalAuth.
• No tests were added in the PR. Prior readiness comments state the Blazor template target passed in CI on Windows and macOS while remaining red was unrelated.

Code Review Summary

Verdict: LGTM
Confidence: low
Errors: 0 | Warnings: 0 | Suggestions: 0

Key code review findings:

• ℹ No ❌ Errors, ⚠️ Warnings, or 💡 Suggestions found by the independent code-review pass.
• ℹ Failure-mode probes: WebAssembly without auth intentionally has no dev-only middleware; Individual Local Auth keeps UseMigrationsEndPoint(); launch profile inspectUri removal matches .NET 11 migration guidance.
• ℹ CI evidence is partially unavailable through authenticated gh, but prior PR comments report target Blazor template legs passed and remaining red was unrelated.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #36855	Remove obsolete UseWebAssemblyDebugging() and inspectUri; narrow development branch to IndividualLocalAuth only.	⚠️ SKIPPED (Gate: no tests detected in PR)	Program.cs, Program.Main.cs, launchSettings.json	Original PR; targeted CI comments report Blazor template tests green.

---

🔬 Code Review — Deep Analysis

Code Review — PR #36855

Independent Assessment

What this changes: Removes obsolete Blazor WASM debugging middleware and inspectUri from MAUI Blazor solution templates.
Inferred motivation: Avoid .NET 11 ASPDEPR011 build failures.

Reconciliation with PR Narrative

Author claims: UseWebAssemblyDebugging() and inspectUri are obsolete/removed in .NET 11; IDEs now launch debugging directly.
Agreement/disagreement: Agrees. Initial expert concern about losing debugging support is resolved by .NET 11 guidance requiring both removals.

Prior Review Reconciliation

No prior ❌ Error findings found.

CI Status

• Required-check result: gh pr checks unavailable (gh auth login required)
• AzDO: maui-pr build 1529150 failed, but Blazor template legs passed; remaining failures reported/classified as unrelated infra/sample/Helix issues.
• Classification: confirmed PR-unrelated red, with tool gap
• Action taken: invoked azdo-build-investigator; confidence capped low

Findings

No ❌ Errors, ⚠️ Warnings, or 💡 Suggestions.

Failure-Mode Probing

• WebAssembly without auth: no dev-only middleware remains; per .NET 11 this is expected.
• Individual auth: UseMigrationsEndPoint() path preserved.
• launch profiles: removing inspectUri matches required .NET 11 migration.

Verdict: LGTM

Confidence: low
Summary: The code change matches the documented .NET 11 breaking change and targeted Blazor template CI passed. Confidence is low only because gh pr checks --required could not run authenticated and overall AzDO remains red from unrelated failures.

---

🛠️ Fix — Analysis & Comparison

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix-1	Add UseLegacyWebAssemblyDebugging computed symbol and gate obsolete artifacts false for net11.	⚠️ Blocked	4 files	Integration blocked by local workload provisioning; not better due stale deny-list/template complexity.
2	try-fix-2	Add net11-only file-level template variants selected by source modifiers.	⚠️ Blocked / not applied	0 files	Rejected at expert self-review as duplicate-file drift risk and not viable for a net11-only branch.
3	try-fix-3	Inline allow-list obsolete artifacts for UseWebAssembly && Framework == "net10.0".	⚠️ Blocked	3 files	Deterministic syntax checks passed; integration blocked; not better because it preserves dead legacy code.
PR	PR #36855	Delete obsolete UseWebAssemblyDebugging() and inspectUri; narrow dev branch to IndividualLocalAuth.	⚠️ Gate skipped; prior CI target green	3 files	Simpler, aligns with .NET 11 guidance, and avoids dead template branches.

Cross-Pollination

Model	Round	New Ideas?	Details
maui-expert-reviewer	1	Yes	Candidate 1: target-framework-gated legacy debugging emission.
maui-expert-reviewer	2	Yes	Candidate 2: net11 file-level template fork. Rejected before implementation due drift/complexity.
maui-expert-reviewer	3	Yes	Candidate 3: inline legacy TFM allow-list.
maui-expert-reviewer	4	No	Remaining variants are either warning suppression, dead-code preservation, duplicate-file forks, or trivial rewrites of the PR's direct removal.

Exhausted: Yes
Selected Fix: PR #36855 — The PR's direct removal is the simplest and most robust option for a net11 template branch. No alternative candidate passed integration locally, and the alternatives that can be reasoned about are more complex or retain obsolete/dead template code.

---

🏁 Report — Final Recommendation

Comparative Fix Report — PR #36855

Candidates Compared

Candidate	Approach	Regression/Test Result	Ranking Notes
pr	Remove UseWebAssemblyDebugging() and inspectUri; narrow the development branch to IndividualLocalAuth.	Gate skipped because no tests were detected; prior PR-state context reports the target Blazor template CI legs passed and remaining red was unrelated.	Best: simplest direct .NET 11 fix, no obsolete/dead template artifacts retained.
pr-plus-reviewer	Same as pr; expert reviewer found no actionable inline findings to apply.	Same as pr.	Tied technically with pr, but not a distinct improvement because no review changes were applied.
try-fix-1	Add UseLegacyWebAssemblyDebugging = UseWebAssembly && Framework != "net11.0" and keep legacy debugging artifacts for non-net11 output.	Blocked: integration could not run because local workload installation failed (Workload ID maui is not recognized).	Lower than PR: adds template complexity and future-staleness risk by enabling obsolete debugging for later TFMs unless updated.
try-fix-2	Add net11-only file-level template variants selected by source modifiers.	Not run; abandoned before implementation.	Lower than PR: duplicate template files increase drift risk and source-modifier matrix fragility.
try-fix-3	Inline allow-list obsolete debugging artifacts for UseWebAssembly && Framework == "net10.0".	Blocked: integration could not run because local MAUI SDK packs were unavailable; deterministic checks passed.	Lower than PR: safer than try-fix-1, but still preserves dead legacy debugging code in a net11 branch.

Winner

Winning candidate: pr

The raw PR fix wins because it directly removes the obsolete API and matching launch profile debugging affordance from the .NET 11 template. pr-plus-reviewer is equivalent but has no applied reviewer delta, while every try-fix candidate is either unimplemented, blocked, more complex, or preserves obsolete/dead template branches. No candidate had passing locally executed regression tests, so the ranking is based on the available PR-state CI evidence, deterministic review, and implementation risk.

Rationale

The issue is specific to .NET 11 template output producing ASPDEPR011 for UseWebAssemblyDebugging(). Keeping the obsolete debugging path behind additional template conditions does not improve the net11 branch and creates future maintenance risk. Removing both the middleware call and inspectUri is consistent across the two program variants and launch profiles, and narrowing the development branch preserves the only remaining development-only middleware (UseMigrationsEndPoint()) for Individual Local Auth.

---

🧭 Next Steps — review latest findings

No alternative fix was selected for this run. Review the session findings and CI results before merging.