Feature request: Support static WebSockets `wss://` and `ws://` port(s) via env var `DOTNET_WATCH_AUTO_RELOAD_WS_ENDPOINT` in `dotnet watch`

Disclaimer: I’m new here, so please let me know if I’m doing anything at all wrong and I’ll fix it. 😄

Is your feature request related to a problem? Please describe.

Each time dotnet watch restarts (manually, or in response to a rude edit, etc) random free ports (via port :0) are chosen for the ws:// and wss:// WebSockets connection,

I can appreciate why this feature defaults to “a random free port” (i.e. you want to make the feature “just work”, rather than trying to bind to a user-defined static port), but this has some negative effects of the developer experience, i.e. that:

1. The WebSockets connection(s) cannot be automatically resumed (reconnected to the existing browser tabs) by aspnetcore-browser-refresh.js, as the ports have changed.
2. Practically, this means that you need to F5 the browser window, to reload the page, so that aspnetcore-browser-refresh.js will pick up the new WS ports.
3. Thus, no more “hot” or even “live” reload for you, until you F5.

This issue has been raised twice before:

1. https://github.com/dotnet/aspnetcore/issues/39608
2. https://github.com/dotnet/aspnetcore/issues/33823

Describe the solution you’d like

Setting the environment variable as follows would allow developers to opt-in to static wss:// and ws:// WebSockets ports to be specified, e.g. like:

DOTNET_WATCH_AUTO_RELOAD_WS_ENDPOINT=https://localhost:43399,http://localhost:8099

I’d like to propose this as a minor change to .NET SDK 7.x (as this can be shipped as an additive non-breaking change).

I have a PR here which shows an example implementation.

See: https://github.com/dotnet/sdk/pull/31575/files for the code.

Additional context

The original (implemented and closed) browser live reload feature (as envisaged by @DamianEdwards) even covered the scenario we’re talking about here, but it doesn’t work because of the random port selection on restart.

The JS block should treat any disconnection of the WebSocket as indication it needs to perform the browser refresh. In the case of dotnet watch, this should only occur after it has been determined that the application server has successfully restarted after the project has been rebuilt and restarted. – Damian Edwards

See: https://github.com/dotnet/aspnetcore/issues/23412#issuecomment-655205989 for more details.

Challenges I am having

I’m currently struggling to work out how to build .NET SDK 7.x from source. I have it building from source as a patch to .NET SDK 8, but my example app doesn’t work currently when ported to .NET 8, so it’s making it hard to test the patch locally. Please point me to the correct branch and build “how to” and I’m happy to rebase this from the 7.x branch.

Update: I’ve found branches release/7.0.2xx, release/7.0.3xx, and release/7.0.4xx, which all compile to produce v7 of the SDK fine, but apologies, I’m not sure if I’m supposed to raise PRs against one/many of those, or some other upstream 7.x branch?

We’d also need to adjust the behaviour of aspnetcore-browser-refresh.js slightly so that it will e.g. window.location.reload() when it detects a subsequent drop and reconnection of the WebSocket(s), but at this stage, I’m just focussed on seeing if this change to static ports is one that’s amenable to the team.

Thanks, and I appreciate you taking the time to consider my proposal. 🥰

Cheers,

Tod.

cc: @tmat @arkalyanms (as code owners of Area-Watch)

[todthomson]

Yep those are totally fair concerns. One of the hardest part of these kinds of tooling experiences is coordinating all the moving pieces to avoid those dreaded browser error screens. I admit I’m surprised dotnet watch is restarting the websocket server after each app restart, as ultimately that’s what causing the browser to lose the connection and thus not get the signal to refresh. I’m trying to cast my mind back but I can’t remember why that would be the case. Perhaps that can be revisited.

Appreciate that mate. I can’t really say for sure that dotnet watch is restarting, only that when a “rude edit” happens, and dotnet watch chooses to reboot dotnet run, then WebSockets connections end up with new ports, which as you say means the connection is (sadly) lost for good (until the F5 grabs the new port configuration from the server).

I’ll experiment and report back asap. Thanks.

[todthomson]

Presuming it doesn’t result in a 404 because the web server is restarting, and it doesn’t leave everyone else’s browsers with blank tabs, I am all for it. 😃

I’ll experiment and report back asap.