Attaching webassembly debugger causes a second copy of the app to start

[SteveSandersonMS]

Scenario:

• SDK: 5.0.100-rtm.20515.8
• Packages versions: 5.0.0-rtm.20512.8
• Sample app: https://github.com/captainsafia/blazoract/tree/stevesa/rtm-packages
• VS Code version: 1.50.1 with C# tools version 1.23.5

Repro steps:

• cd Client
• dotnet run
• Note from terminal output that only one copy of the client app is running, and it's listening on ports 5000 and 5001. For example, you see the following (and nothing else!):

> dotnet run
Building...
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: C:\git\captainsafia\blazoract\Client

• Now in VS Code, start the debugger with a launch profile like this:

    {
        "name": "Attach to Blazor WebAssembly App",
        "type": "blazorwasm",
        "request": "attach",
        "cwd": "${workspaceFolder}/Client",
        "url": "https://localhost:5001",
        "browser": "edge"
    },

• Expected: debugger attaches to the existing running app, and no further copy of the app is started. After finishing debugging, you should be able to click the "disconnect" button, then immediately start debugging again with the same settings successfully.
• Actual: It does launch a browser that connects to the existing running app on port 5001, but:
  • In the terminal output you can see that a second copy of the app was started, because it now logs the following:

Hosting environment: Production
Content root path: C:\git\captainsafia\blazoract\Client
Now listening on: http://127.0.0.1:64363
Application started. Press Ctrl+C to shut down.

Also, when you're done with debugging, if you stop it with Shift+F5 and then right after try to restart debugging with F5 again, you'll get this:

... and in the terminal you'll see:

got exception System.Net.WebSockets.WebSocketException (0x80004005): Unable to connect to the remote server
 ---> System.Net.Http.HttpRequestException: No connection could be made because the target machine actively refused it. (127.0.0.1:64356)
 ---> System.Net.Sockets.SocketException (10061): No connection could be made because the target machine actively refused it.
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)

... and from this state, the only way to get the debugger to work again is to force-quit the app in your terminal via ctrl+c, which exits both the unwanted extra copy of the app and the original copy that you didn't want to close.

[captainsafia]

In the terminal output you can see that a second copy of the app was started, because it now logs the following:

This bit is expected. The output is the piped output from the debugging proxy.

Also, when you're done with debugging, if you stop it with Shift+F5 and then right after try to restart debugging with F5 again, you'll get this:

This bit is not expected. It looks like the debugging proxy might've been killed during Shift + F5 and failed to launch when debugging was initialized a second time.

EDIT: I've been doing some work on the VS Code blazorwasm debugger and will look at this issue with that.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.