Revisit hot reload browser refresh script injection

[MackinnonBuck]

Our hot reload mechanism relies on the aspnetcore-browser-refresh.js script being injected into the webpage so the browser can automatically refresh with hot reload changes.

We currently do this with a special middleware that searches for the last closing </body> tag in HTML responses and injects a <script src="/_framework/aspnetcore-browser-refresh.js"></script> element just before it. However, this mechanism is very fragile because it fails when the response can't be easily parsed (e.g., response compression is enabled, the closing </body> tag is split between response stream writes, etc.).

We should consider an approach where we somehow reference the browser refresh script directly rather than using this script injection middleware.

Additional considerations

Make sure we also address the following issues:

• Refused to load _framework/aspnetcore-browser-refresh.js due to CSP #33068
• HotReload is not working in ASP.NET Core in VS2022 or dotnet watch run when ServiceWorkers are installed/running #39715

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 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.

[ghost]

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.

[ghost]

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.

[javiercn]

One thought I'm leaving here so we don't forget.

We should make these scripts ES6 modules and rely on import.meta.url as that will decouple us from the base and allow us to always refer to endpoints, etc. in a way that is relative to the location of the hot-reload script.

[daiplusplus]

After experiencing numerous difficulties with disabling VS's (and ASP.NET Core's) script injection feature, I'd like to request that all injected HTML should include a HTML comment with instructions on how to disable HTML injection.

So instead of this (which is what we have right now):

<script src="/_framework/aspnetcore-browser-refresh.js"></script></body>
</html>

...it should be something like this:

<!-- BEGIN Visual Studio 2022 Hot Reload script (for CSS Hot Reload / Blazor Hot Reload / BrowserLink / Etc).
This can be disabled under Tools > Options > Projects and Solutions > ASP.NET Core, and by adding "hotReloadEnabled": false to your launchSettings.json profile. -->
<script src="/_framework/aspnetcore-browser-refresh.js"></script>
<!-- END  Visual Studio 2022 Hot Reload.
</body>
</html>

...because right now the Hot Reload script will be injected if any of 4 entirely different VS or Project options are configured a certain way, and there's no obvious way to disable it. I would also like to have a single "Disable all code-injections" option so I won't have code unexpectedly injected for something-else-other-than-Hot-Reload in future.

[javiercn]

Note that this was changed as part of dotnet/sdk#44539

[javiercn]

https://github.com/dotnet/sdk/blob/71b8c10912d5f2a480c1548968bec243a139ec61/src/BuiltInTools/BrowserRefresh/HostingStartup.cs#L46-L47

https://github.com/dotnet/sdk/blob/71b8c10912d5f2a480c1548968bec243a139ec61/src/BuiltInTools/BrowserRefresh/HostingStartup.cs#L44

https://github.com/dotnet/sdk/blob/71b8c10912d5f2a480c1548968bec243a139ec61/src/BuiltInTools/BrowserRefresh/BrowserRefreshMiddleware.cs#L42-L44
https://github.com/dotnet/sdk/blob/main/src/BuiltInTools/BrowserRefresh/ResponseStreamWrapper.cs#L99-L111

We shouldn't wrap the response to rewrite it on the fly, instead, we should leverage Static Web Assets ability to define build time only assets to inject any script we need as a JS initializer.

For MVC and Razor pages, a BodyTagHelper can be used to perform the injection by looking at the ResourceCollection. That offers a much more solid approach as we don't have to detect the <body> tag and inject into a hardcoded path so early in the pipeline, which causes other sort of problems when users use things like a custom path base.

Using a body tag helper and/or initializer ensures that the correct path is injected at the right time taking the right context into account and removes a significant amount of this plumbing code.