[.NET10RC2] `dotnet watch run --no-hot-reload` fails

[TheArcaneBrony]

Describe the bug

Running dotnet watch run --no-hot-reload does not work correctly, at least for blazor-wasm projects.
When a rebuild is triggered, it does not shut down the old dev server, causing the new one to fail with a bind error.

To Reproduce

• Create new blazor wasm app (ie. dotnet new blazorwasm -e -p --no-https)
• Run with watch: dotnet watch run -c Release --property WarningLevel=0 --no-hot-reload
• Open in browser
• Make a change to one of the .razor files (ie. Home.razor)
• Note that the server fails to start
• Reload the page, note that the browser console is spammed with integrity errors due to not being able to find files.

Exceptions (if any)

fail: Microsoft.Extensions.Hosting.Internal.Host[11]
      Hosting failed to start
      System.IO.IOException: Failed to bind to address http://[::]:5117: address already in use.
       ---> Microsoft.AspNetCore.Connections.AddressInUseException: Address already in use
       ---> System.Net.Sockets.SocketException (98): Address already in use
         at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, Boolean disconnectOnFailure, String callerName)
         at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
         at System.Net.Sockets.Socket.Bind(EndPoint localEP)
         at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportOptions.CreateDefaultBoundListenSocket(EndPoint endpoint)
         at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener.Bind()
         --- End of inner exception stack trace ---
         at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketConnectionListener.Bind()
         at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportFactory.BindAsync(EndPoint endpoint, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure.TransportManager.BindAsync(EndPoint endPoint, ConnectionDelegate connectionDelegate, EndpointConfig endpointConfig, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.<>c__DisplayClass28_0`1.<<StartAsync>g__OnBind|0>d.MoveNext()
      --- End of stack trace from previous location ---
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context, CancellationToken cancellationToken)
         --- End of inner exception stack trace ---
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Core.ListenOptions.BindAsync(AddressBindContext context, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Core.AnyIPListenOptions.BindAsync(AddressBindContext context, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.AddressesStrategy.BindAsync(AddressBindContext context, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.BindAsync(CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.StartAsync[TContext](IHttpApplication`1 application, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.Hosting.GenericWebHostService.StartAsync(CancellationToken cancellationToken)
         at Microsoft.Extensions.Hosting.Internal.Host.<StartAsync>b__14_1(IHostedService service, CancellationToken token)
         at Microsoft.Extensions.Hosting.Internal.Host.ForeachService[T](IEnumerable`1 services, CancellationToken token, Boolean concurrent, Boolean abortOnFirstException, List`1 exceptions, Func`3 operation)

Further technical details

details of dotnet --info

``` .NET SDK: Version: 10.0.100-rc.2.25502.107 Commit: 89c8f6a112 Workload version: 10.0.100-manifests.0cee6f9c MSBuild version: 18.0.0-preview-25502-107+89c8f6a11

Runtime Environment:
OS Name: nixos
OS Version: 25.11
OS Platform: Linux
RID: linux-x64
Base Path: /nix/store/aj7lxjjn3rl2bazsv9p0dfnv069j6rsq-dotnet-sdk-10.0.100-rc.2.25502.107/share/dotnet/sdk/10.0.100-rc.2.25502.107/

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
Version: 10.0.0-rc.2.25502.107
Architecture: x64
Commit: 89c8f6a112

.NET SDKs installed:
10.0.100-rc.2.25502.107 [/nix/store/aj7lxjjn3rl2bazsv9p0dfnv069j6rsq-dotnet-sdk-10.0.100-rc.2.25502.107/share/dotnet/sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 10.0.0-rc.2.25502.107 [/nix/store/aj7lxjjn3rl2bazsv9p0dfnv069j6rsq-dotnet-sdk-10.0.100-rc.2.25502.107/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 10.0.0-rc.2.25502.107 [/nix/store/aj7lxjjn3rl2bazsv9p0dfnv069j6rsq-dotnet-sdk-10.0.100-rc.2.25502.107/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
None

Environment variables:
DOTNET_CLI_TELEMETRY_OPTOUT [1]
DOTNET_WATCH_SUPPRESS_LAUNCH_BROWSER [1]

global.json file:
Invalid [/home/Rory/git/matrix/MatrixUtils-master/global.json]
Version '9.0.0' is not valid for the 'sdk/version' value. SDK feature bands start at 1 - for example, 9.0.100

</p>
</details>
- Rider 2025.2.4 on NixOS, though using dotnet CLI to run my project.

[Youssef1313]

cc @tmat

[tmat]

Likely fixed by #50983. Please let us know if it repros in the latest build.

[mispencer]

@tmat - this is still reproducible in the latest build.

This appears to be due to watch immediately sending a SIGKILL after sending SIGTERM and thus probably not giving the killed process enough time to respond to the SIGTERM.

You can see this in the source watch code that the time between SIGTERM and SIGKILL depends on the process cleanup timeout and that, in no-hot-reload case, the process cleanup timeout defaults to zero.

The process cleanup timeout is overridable by setting the DOTNET_WATCH_PROCESS_CLEANUP_TIMEOUT_MS environment variable and, indeed, if you set it to a reasonable number - 100 seems to be enough - then the issue no longer occurs. This is a valid workaround until this is fixed assuming you are willing to install the latest unstable build.

I assume setting a short, but not zero, process cleanup timeout default for the no-hot-reload case would be enough to resolve this.

Relevant logs with DOTNET_WATCH_PROCESS_CLEANUP_TIMEOUT_MS unset.

dotnet watch ⌚ Terminating process 70687 (SIGTERM).
dotnet watch ⌚ Terminating process 70687 (SIGKILL).
dotnet watch ⌚ Waiting for process 70687 to exit (1).

Relevant logs with DOTNET_WATCH_PROCESS_CLEANUP_TIMEOUT_MS set to 1000.

dotnet watch ⌚ Terminating process 71203 (SIGTERM).
dotnet watch ⌚ Waiting for process 71203 to exit within 1s.
info: Microsoft.Hosting.Lifetime[0]
      Application is shutting down...
dotnet watch ⌚ Terminating process 71203 (SIGKILL).
dotnet watch ⌚ Waiting for process 71203 to exit (1).

[tmat]

in no-hot-reload case, the process cleanup timeout defaults to zero.

That's certainly a bug. Thanks for the details.