Simplify WebAssembly hot reload capabilities detection

[MackinnonBuck]

Background

Upon initialization, the dotnet watch tool needs to know the set of available WebAssembly hot reload capabilities before the hot reload session starts. The current mechanism for this relies on the WebAssembly runtime having started up so it can be asked which capabilities it supports. However, in Blazor Web scenarios, WebAssembly runtime startup might be delayed indefinitely, which causes the mechanism to read hot reload capabilities to fail.

We worked around this problem in dotnet/sdk#36195 by having a fallback, default set of capabilities to use if reading capabilities from the WebAssembly runtime fails.

Proposed solution

We could go one of two directions in the future to fully address this issue:

• Expand the capabilities of dotnet watch to dynamically update the set of available capabilities if a new runtime becomes available (relatively high complexity)
• Remove WebAssembly capabilities detection completely and rely on the fallback capabilities only (simpler)

To simplify the Blazor WebAssembly hot reload infrastructure and make the overall hot reload experience less error prone, I propose we go with the 2nd option that simplifies WebAssembly hot reload capabilities detection by having the full set of capabilities be known by the dotnet watch tool without having to dynamically fetch those capabilities from the WebAssembly runtime.

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[SteveSandersonMS]

@lewing @danroth27 We'd like to discuss whether this could be changed in the runtime.

[lewing]

cc @thaystg