dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.27k stars 4.73k forks source link

WebAssembly.DevServer (The SSL connection could not be established) #93016

Open dlemstra opened 1 year ago

dlemstra commented 1 year ago

Is there an existing issue for this?

Describe the bug

Starting with version 7.0.10 of Microsoft.AspNetCore.Components.WebAssembly.DevServer we are no longer able to debug Blazor code that is running inside an Angular application with a remote debugger. The file:// "folder" is no longer being shown in the Chrome sources tab and this seems to be happening because of the following error message:

info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:4201
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:\MyProject
[09:23:45] fail: DevToolsProxy[0]
      Failed to load https://localhost:4200/_framework/Microsoft.AspNetCore.Authorization.dll (The SSL
 connection could not be established, see inner exception.)

We are launching Chrome 117.0.5938.132 with the the following options: --remote-debugging-port=9222 --allow-insecure-localhost --incognito https://localhost:4200/. Our application uses an untrusted certificate and that is probably the message in the inner exception.

Changing the application to use http results in the following error message:

Failed to load http://localhost:4200/_framework/Microsoft.AspNetCore.Authorization.dll (Response status 
code does not indicate success: 404 (Not Found).)

This is happening because we start Blazor with the following options:

await Blazor.start({
    loadBootResource: function (type: string, name: string, defaultUri: string, integrity: string) {
        return `${defaultUri.replace("_framework", "assets/dotnet")}?${integrity}`;
    }
});

But the new version of the DevServer no longer seems to know about this and uses the wrong _framework url.

Downgrading both Microsoft.AspNetCore.Components.WebAssembly and Microsoft.AspNetCore.Components.WebAssembly.DevServer to version 7.0.9 resolves the issue and allows us to debug our application. I tried to check the changes between those two versions here and in the dotnet/runtime repository but I was unable to find a commit that was causing this.

.NET Version

7.0.401

Anything else?

.NET SDK: Version: 7.0.401 Commit: eb26aacfec

Runtime Environment: OS Name: Windows OS Version: 10.0.22621 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\7.0.401\

Host: Version: 7.0.11 Architecture: x64 Commit: ecb34f85ec

.NET SDKs installed: 7.0.401 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found: x86 [C:\Program Files (x86)\dotnet] registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables: Not set

global.json file: Not found

mkArtakMSFT commented 1 year ago

@thaystg should I move to the runtime repo? Looks like there was some regression in the 7.0.10 that needs to be reviewed.

thaystg commented 1 year ago

Yes, please.

ghost commented 1 year ago

Tagging subscribers to 'arch-wasm': @lewing See info in area-owners.md if you want to be subscribed.

Issue Details
### Is there an existing issue for this? - [X] I have searched the existing issues ### Describe the bug Starting with version `7.0.10` of `Microsoft.AspNetCore.Components.WebAssembly.DevServer` we are no longer able to debug Blazor code that is running inside an Angular application with a remote debugger. The `file://` "folder" is no longer being shown in the Chrome sources tab and this seems to be happening because of the following error message: ``` info: Microsoft.Hosting.Lifetime[14] Now listening on: http://localhost:4201 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:\MyProject [09:23:45] fail: DevToolsProxy[0] Failed to load https://localhost:4200/_framework/Microsoft.AspNetCore.Authorization.dll (The SSL connection could not be established, see inner exception.) ``` We are launching Chrome `117.0.5938.132` with the the following options: `--remote-debugging-port=9222 --allow-insecure-localhost --incognito https://localhost:4200/`. Our application uses an untrusted certificate and that is probably the message in the inner exception. Changing the application to use `http` results in the following error message: ``` Failed to load http://localhost:4200/_framework/Microsoft.AspNetCore.Authorization.dll (Response status code does not indicate success: 404 (Not Found).) ``` This is happening because we start Blazor with the following options: ```js await Blazor.start({ loadBootResource: function (type: string, name: string, defaultUri: string, integrity: string) { return `${defaultUri.replace("_framework", "assets/dotnet")}?${integrity}`; } }); ``` But the new version of the `DevServer` no longer seems to know about this and uses the wrong `_framework` url. Downgrading both `Microsoft.AspNetCore.Components.WebAssembly` and `Microsoft.AspNetCore.Components.WebAssembly.DevServer` to version `7.0.9` resolves the issue and allows us to debug our application. I tried to check the changes between those two versions here and in the `dotnet/runtime` repository but I was unable to find a commit that was causing this. ### .NET Version 7.0.401 ### Anything else? .NET SDK: Version: 7.0.401 Commit: eb26aacfec Runtime Environment: OS Name: Windows OS Version: 10.0.22621 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\7.0.401\ Host: Version: 7.0.11 Architecture: x64 Commit: ecb34f85ec .NET SDKs installed: 7.0.401 [C:\Program Files\dotnet\sdk] .NET runtimes installed: Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Other architectures found: x86 [C:\Program Files (x86)\dotnet] registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation] Environment variables: Not set global.json file: Not found
Author: dlemstra
Assignees: thaystg
Labels: `arch-wasm`, `untriaged`, `area-VM-meta-mono`, `in-pr`, `needs-area-label`
Milestone: -
SamMonoRT commented 1 year ago

removing untriaged field and setting milestone 7.0.x for tracking.

dotnet-policy-service[bot] commented 5 months ago

Tagging subscribers to this area: @thaystg See info in area-owners.md if you want to be subscribed.