[oroztocil]

Possible fix for dotnet/aspnetcore#69718.

Problem

After #56118, .NET 11 SDK generates Blazor browser-tools initializers when Hot Reload build outputs are enabled (by default in Debug builds). This also happens for ordinary dotnet run launches and projects targeting older frameworks, since SDK selection is independent of the target framework.

When an initializer probes /_framework/dotnet-browser-tools/hot-reload-settings.json, older hosts lack the disabled-settings endpoint supplied by .NET 11 ASP.NET Core hosts. The initializer correctly treats the failed request as Hot Reload being disabled, but the browser still reports a 404.

Change

For pre-.NET 11 targets, generate a constant {"hotReload": false} static asset at the existing settings URL. Generation uses the existing browser-tools gate, including EnableHotReloadInRuntimeConfigDevFile. The asset is build-only, excluded from publish output, and reused without rewriting on incremental builds.

Net11+ targets continue using their existing host fallback. Their non-Development behavior is unchanged.

Behavior preservation

• Active watch providers retain precedence. ASP.NET Core and legacy DevServer forwarding runs before static assets. Gateway’s provider proxy uses order -1000, ahead of static asset endpoints at -100.
• No activation state is written into build output. The generated file always contains false. The provider supplies true dynamically, preserving the same build output across ordinary and watch launches.
• Default Release and publish behavior remain unchanged. The fallback follows the existing Hot Reload generation gate and never reaches published applications.

Validation

All Web/WASM regression cases covering net8 and net10 fail without the fix and pass with it. All 32 focused integration tests and 12 real-browser run/watch scenarios pass, including state-preserving live edits.

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).
1 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

🟡 Changes recommended

Multiple older-framework WebAssembly clients export conflicting root-scoped fallback assets, causing their host’s Debug build to fail.

1 open issue

• Duplicate hot-reload settings assets break multi-client builds · New

What changed in this PR

Adds a build-only disabled Hot Reload settings fallback for pre-.NET 11 applications, avoiding missing-endpoint responses during ordinary launches.

Changes:

• Generates a constant fallback using existing Hot Reload gates, excluding publish output.
• Adds integration coverage for generation, cleanup, publishing, and hosted WebAssembly.
• Updates architecture and contributor guidance.

File	Description
test/​Microsoft.NET.Sdk.StaticWebAssets.Tests/​HotReloadBrowserToolsIntegrationTest.cs	Adds fallback lifecycle and configuration tests.
src/​StaticWebAssetsSdk/​Targets/​Microsoft.NET.Sdk.StaticWebAssets.HotReload.targets	Generates and registers the fallback asset.
src/​StaticWebAssetsSdk/​AGENTS.md	Documents fallback generation and ownership.
src/​Dotnet.Watch/​AGENTS.md	Clarifies provider precedence over the fallback.
.github/​memory/​ARCHITECTURE.md	Updates the settings endpoint architecture.

_{Review effort: Balanced}