Feature request: Support static WebSockets `wss://` and `ws://` port(s) via env var `DOTNET_WATCH_AUTO_RELOAD_WS_ENDPOINT` in `dotnet watch`
See original GitHub issueDisclaimer: 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:
- The WebSockets connection(s) cannot be automatically resumed (reconnected to the existing browser tabs) by
aspnetcore-browser-refresh.js
, as the ports have changed. - Practically, this means that you need to
F5
the browser window, to reload the page, so thataspnetcore-browser-refresh.js
will pick up the new WS ports. - Thus, no more āhotā or even āliveā reload for you, until you F5.
This issue has been raised twice before:
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
)
Issue Analytics
- State:
- Created 5 months ago
- Comments:9 (5 by maintainers)
Appreciate that mate. I canāt really say for sure that
dotnet watch
is restarting, only that when a ārude editā happens, anddotnet watch
chooses to rebootdotnet 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.
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.