The browser refresh mechansim used by dotnet-watch and VS modifies HTML content. The modified content includes
a script block that has a WebSocket url that changes for each new execution of dotnet watch run (not rebuilds, but watch itself).
HTML content can come from views or static html files on disk. For the latter, ASP.NET Core participates in browser caching by sending (and invalidating) etag headers.
One way to fix this problem is remove or modify the etag headers. The risk here is that might cause differences in behavior in development users may come to rely on that are unavailable in production. This change instead modifies the HTML content so the output is always consistent and consequently safe to cache. The dynamic content is served separately by the injected middleware.
This change fixes the issue of multiple instances of dotnet-watch. While this issue may crop up if you alternate between dotnet run and dotnet watch run but we haven't seen this being an issue as yet.
Fixes#27548
Summary
Running dotnet watch run multiple times in Blazor WASM apps (or any app that serves static html files) can produce console errors and prevent the browser refresh feature from working. Given that we've been telling our users to use dotnet watch run as their primary way to work outside of VS, it's likely more users would run in this.
Customer impact
A hard browser refresh (Ctrl + R) is needed to get the refresh behavior to work.
Regression
No. This has existed since the feature was introduced we did not get reports of it
Risk
Low. The fix is isolated to dotnet-watch and VS's browser refresh mechanism which is in preview. The change was tested locally, but if there's a regression or if the change interferes with user's workflow, users have the ability to disable this feature.
b34c5ddd5f