[wasm] General HotReload agent for WebAssembly in browser

[maraf]

Extract HotReload agent from Blazor to a general purpose HotReload for WebAssembly in browser scenarios.

The goal is to enable HotReload in non-Blazor scenarios.

The package is implicitly referenced by WasmSDK and can be turned off with WasmEnableHotReload=false. We are always referencing "current" version and for downlevel we need to multitarget.

The package contains a module that is recognized by WasmSDK and automatically loaded. The module then instructs Mono runtime that HotReload is enabled and provides callbacks migrated from Blazor internal JS API that are used by aspnetcore-browser-refresh.js. Before the built-in HotReload in Blazor gets removed, the module also disables it.

Migration from Blazor

• WebAssemblyHotReload.cs -> aspnetcore/WebAssemblyHotReload.cs
  • Instead of just Blazor specific JavaScript interop we have migrated to the source generated one from runtime that is usable in all .NET on WASM apps. We need to do JSON serialization manually, because the interop layer doesn't do it automatically.
• Microsoft.DotNet.HotReload.WebAssembly.Browser.lib.module.js -> aspnetcore/Boot.WebAssembly.Common.ts
  • Standard esmodule supported by WasmSDK, the other part of JS interop changes and check for browser refresh script

Contributes to dotnet/aspnetcore#61272
Related to dotnet/aspnetcore#62735

[dotnet-policy-service]

Thanks for your PR, @@maraf.
To learn about the PR process and branching schedule of this repo, please take a look at the SDK PR Guide.

[Copilot]

Pull Request Overview

This PR extracts the HotReload agent from Blazor to create a general-purpose HotReload capability for WebAssembly browser scenarios. The goal is to enable HotReload functionality in non-Blazor WebAssembly applications.

Key changes include:

• Adding implicit HotReload package reference in WasmSDK for .NET 10+ projects
• Creating a new WebAssembly-specific HotReload agent that can work independently of Blazor
• Implementing JavaScript interop for runtime configuration and delta application

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/WasmSdk/Sdk/Sdk.targets	Adds implicit package reference for HotReload with conditional enablement logic
src/BuiltInTools/dotnet-watch.slnf	Includes new HotReload WebAssembly project in solution filter
wwwroot/Microsoft.DotNet.HotReload.WebAssembly.Browser.lib.module.js	JavaScript module for runtime configuration and Blazor API compatibility
WebAssemblyHotReload.cs	Core C# implementation handling delta application and HTTP communication
Microsoft.DotNet.HotReload.WebAssembly.Browser.csproj	Project file for new HotReload package
sdk.slnx	Adds new project to main solution

Comments suppressed due to low confidence (2)

src/BuiltInTools/HotReloadAgent.WebAssembly.Browser/WebAssemblyHotReload.cs:109

• [nitpick] The variable name 'i' is not descriptive. Consider renaming it to 'updateIndex' or 'currentUpdate' to improve code readability.

                var i = 1;

src/BuiltInTools/HotReloadAgent.WebAssembly.Browser/WebAssemblyHotReload.cs:147

• The variable name 'jsonContext' does not follow C# naming conventions for private static readonly fields. It should be 's_jsonContext' to match the pattern used elsewhere in this class.

    private static readonly WebAssemblyHotReloadJsonSerializerContext jsonContext = new(new(JsonSerializerDefaults.Web));

[tmat]

LGTM. Someone should review the WasmSdk change. Looks reasonable but I can't tell if there are any undesirable side effects.

[javiercn]

Consider making the initializer apply only at build time. (There's no need to bring that initializer into the published payload) (AssetKind=Build)

[maraf]

We won't win that much. The assembly will still get loaded and we can't make it lazy, because JSExport doesn't work if we load the assembly lazily.

[javiercn]

Will this get trimmed away?

An alternative would be not having a package at all and instead inject the dll and the initializer in a target as part of the build. AFAIK, it doesn't even need to be part of the compilation, does it?

As long as we tell the wasm runtime to load the dll when we are bootstrapping the framework we should be good, shouldn't we?

[maraf]

The challenge is how to know that there is a .NET somewhere in the browser.

We would have to read something from global namespace in the runtime to check if hot reload is attached. The other challenge would be to correctly select the assembly from multi-targeting.
It's possible..

The package is referenced only in non-Release Debug builds, that's how it gets trimmed.

[javiercn]

Some small suggestions, but overall looks good