BlazorWasmDebuggingExtension cannot find 'Microsoft.AspNetCore.App' version '5.0.0'

[JoeRobich]

Moved from dotnet/vscode-csharp#4489 (comment)

There seems to be problems with the new Microsoft.AspNetCore.Razor.VSCode.BlazorWasmDebuggingExtension. I have dotnet on the path, but it throws this error when trying to attach to a hosted Blazor Webassembly app.

Launching debugging proxy from /Users/nikolaiemildamm/.vscode/extensions/ms-dotnettools.blazorwasm-companion-1.0.0/BlazorDebugProxy/BrowserDebugHost.dll
ERROR: It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '5.0.0' was not found.
  - No frameworks were found.

You can resolve the problem by installing the specified framework and/or SDK.

Here is proof dotnet is on the path with the required framework:

This is my launch configuration:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch and Debug Hosted Blazor WebAssembly App",
            "type": "blazorwasm",
            "request": "launch",
            "hosted": true,
            "preLaunchTask": "npm run build:debug",
            "program": "${workspaceFolder}/src/Presentation/WebApp/Server/bin/Debug/net5.0/EcosystemMapGenerator.Presentation.WebApp.Server.dll",
            "cwd": "${workspaceFolder}/src/Presentation/WebApp/Server"
        }
    ]
}

[JoeRobich]

cc: @captainsafia

[captainsafia]

@niem94 So the Blazor WASM Debugging extension uses the .NET installer extension to ensure that there is a runtime installed before running.

Have you ensured that the extension is installed? It should be included automatically when you install the debugging extension but something might've happened there.

[devantler]

@captainsafia Yes, I did notice that ".NET Install Tool for Extension Authors" was installed automatically, and I have also tried removing ~/.vscode/extensions to see if that had any effect.

[ar0311]

I've got 5.0.5 SDK installed and get same error.

I just installed 5.0.0 SDK side by side and restarted VS Code, same error.

MacOS, C# 1.23.11, WASM Debug 1.0.0, .NET Install Tool 1.0.0

[devantler]

I've got 5.0.5 SDK installed and get same error.

I just installed 5.0.0 SDK side by side and restarted VS Code, same error.

MacOS, C# 1.23.11, WASM Debug 1.0.0, .NET Install Tool 1.0.0

Are your problem also with hosted blazor wasm or with normal wasm? :-)

[ar0311]

Normal WASM

[devantler]

The culprit might be related to our OS then. #MacOSLife.

@captainsafia I hope someone on the team is able to prioritize this — would love to be able to enjoy the new debugging experience :-)

[ar0311]

No, I get the same issue on Linux.

[captainsafia]

Hm -- I can repro this now.

Launching debugging proxy from /Users/captainsafia/.vscode/extensions/ms-dotnettools.blazorwasm-companion-1.0.0/BlazorDebugProxy/BrowserDebugHost.dll
ERROR: It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '5.0.0' was not found.
  - No frameworks were found.

You can resolve the problem by installing the specified framework and/or SDK.

So, the dotnet installed on your machine doesn't affect the problem here since it relies on the one installed by the installer.

.NET 5.0.5 executable path: /Users/captainsafia/Library/Application Support/Code/User/globalStorage/ms-dotnettools.vscode-dotnet-runtime/.dotnet/5.0.5/dotnet

The problem is that that the extension is only installing the M.N.A shared framework and not M.A.A as well now.

> /Users/captainsafia/Library/Application\ Support/Code/User/globalStorage/ms-dotnettools.vscode-dotnet-runtime/.dotnet/5.0.5/dotnet --list-runtimes
Microsoft.NETCore.App 5.0.5 [/Users/captainsafia/Library/Application Support/Code/User/globalStorage/ms-dotnettools.vscode-dotnet-runtime/.dotnet/5.0.5/shared/Microsoft.NETCore.App]

It appears that the .NET Installation extension recently added support for a new installRuntime flag. When this runtime flag is passed, it installs only the dotnet runtime, not the aspnetcore one (ref). This used to work previously because it would install all runtimes.

This is my hunch at the moment but it aligns with the behavior I'm seeing. There's still some ❓ since it doesn't look like the extension has been released for a while so not sure why those changes would be picked up (ref).

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[devantler]

@captainsafia thanks, this lets me move the missing runtime manually as a fix until someone at the team gets this sorted :-)

I did this on MacOS by copying the Microsoft.AspNetCore.App runtime from: /usr/local/share/dotnet/shared/ to: /Users/{yourUserName}/Library/Application Support/Code/User/globalStorage/ms-dotnettools.vscode-dotnet-runtime/.dotnet/5.0.5/shared

Hope this helps others having the same issue.

Also, the debugging experience seems much more stable from my initial tries. Nice work!

[ar0311]

The problem is that that the extension is only installing the M.N.A shared framework and not M.A.A as well now.

But it works on Windows with 5.0.5 installed? Why is that?

[captainsafia]

@niem94 Glad the reasoning helping you get a workaround.

But it works on Windows with 5.0.5 installed? Why is that?

Not sure, ATM. Haven't gotten around to reproing on Windows (I dev mainly on macOS). I suspect that the install behavior is a little different between the two.

[ar0311]

Can you direct me to the source code for the extension?

[captainsafia]

https://github.com/dotnet/vscode-dotnet-runtime

[ar0311]

I've installed the 1.0.1 version with the above fix but still not working.

I notice the runtime extension is only downloading the MNA runtime not MAA one still. If I manually copy MAA to the extension .dotnet folder it works.

MacOS

[captainsafia]

The 1.0.1 fixes another bug where the installation failed at all and adds a workaround to use the debug proxy launched via the middleware as a fallback. This issue still needs to be resolved since the .NET tool installation extension doesn't support installing the M.A.A runtime yet.

[ar0311]

On Linux I'm getting this now when debugging in VS Code.

[bbuchanan]

@captainsafia thanks, this lets me move the missing runtime manually as a fix until someone at the team gets this sorted :-)

I did this on MacOS by copying the Microsoft.AspNetCore.App runtime from: /usr/local/share/dotnet/shared/ to: /Users/{yourUserName}/Library/Application Support/Code/User/globalStorage/ms-dotnettools.vscode-dotnet-runtime/.dotnet/5.0.5/shared

Hope this helps others having the same issue.

Also, the debugging experience seems much more stable from my initial tries. Nice work!

I had been using the debugger just fine until this week. Now I'm receiving the Invalid URL: undefined error. I'm on MacOS using .NET Core 5.0.5. I tried your workaround and it didn't change anything for me.

Are there any other ideas folks can throw at me to help track this down?

FWIW, the old debugging method "open /Applications/Google\ Chrome.app --args --remote-debugging-port=9222" still works. Not sure if that provides any clues.

Thanks.

[devantler]

@captainsafia thanks, this lets me move the missing runtime manually as a fix until someone at the team gets this sorted :-)
I did this on MacOS by copying the Microsoft.AspNetCore.App runtime from: /usr/local/share/dotnet/shared/ to: /Users/{yourUserName}/Library/Application Support/Code/User/globalStorage/ms-dotnettools.vscode-dotnet-runtime/.dotnet/5.0.5/shared
Hope this helps others having the same issue.
Also, the debugging experience seems much more stable from my initial tries. Nice work!

I had been using the debugger just fine until this week. Now I'm receiving the Invalid URL: undefined error. I'm on MacOS using .NET Core 5.0.5. I tried your workaround and it didn't change anything for me.

Are there any other ideas folks can throw at me to help track this down?

FWIW, the old debugging method "open /Applications/Google\ Chrome.app --args --remote-debugging-port=9222" still works. Not sure if that provides any clues.

Thanks.

Can you link your launch.json config? I remember i had to make some changes there as well, so i might be able to spot why if i can compare them :-)

Mine looks like this:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch and Debug Standalone Blazor WebAssembly App",
            "type": "blazorwasm",
            "request": "launch",
            "hosted": true,
            "cwd": "${workspaceFolder}/src/Presentation/Web/Server",
            "program": "${workspaceFolder}/src/Presentation/Web/Server/bin/Debug/net5.0/EcosystemMapGenerator.Presentation.Web.Server.dll"
        }
    ]
}

[bbuchanan]

I didn't change the launch.json file at all. Although my project/config is unchanged from dotnet new, I committed to a repo anyway just in case.

https://github.com/bbuchanan/vscode-blazor-debug

I tried your changes and receiving errors about launching. I'm not hosted though

[devantler]

@bbuchanan I just tested your repo locally. It works with no problems on my end. So I am really not sure why it doesn't on your end. Im not sure it is related to this issue at all.

My only suggestion would be to remove ~/.vscode/extensions and restoring extensions a new? This has sometimes fixed mystical problems for me.

[bbuchanan]

I suspect it's definitely something on my machine. I was redirected here from another site because they thought this might be related, but you're probably right, it's different.

I'm getting the same error as @ar0311 only on Mac. I suppose I'm just looking for ideas to help track down what in the hell happened. I'm stuck!

I completely removed VS Code and all extensions, destructively. I even went so far as to create a brand new user account on my machine. Nothing has given me satisfaction and I don't really know where things are going wrong. Any suggestions to help me track this down?

[captainsafia]

@bbuchanan The issue @ar0311 ran into is an actual bug. I'm working on investigating it and following up with a fix.

I had supposed that the workaround provided above might resolve the issue.

In the absence of that, moving back to the two-step debugging process will always do the trick.

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": ".NET Core Launch (Blazor Standalone)",
            "type": "coreclr",
            "request": "launch",
            "program": "dotnet",
            "args": [
                "run"
            ],
            "cwd": "${workspaceFolder}/src/Project.UI",
            "env": {
                "ASPNETCORE_ENVIRONMENT": "Development"
            }
        },
        {
            "name": ".NET Core Debug Blazor Web Assembly in Chrome",
            "type": "pwa-chrome",
            "request": "launch",
            "timeout": 30000,
            "url": "https://localhost:5001",
            "webRoot": "${workspaceFolder}/src/Project.UI",
            "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}"
        }
    ]
}

[bbuchanan]

Thank you @captainsafia. That seems to get me working for now. I'm still absolutely perplexed as to what could have changed to make it stop working. Do you have any insight on how I might gather where in the process this is breaking down? I'd still like to figure it out, just not sure where to begin.

Thank you again, this workaround does help immensely!

[dtremblay]

Getting this on Windows 10 20H2

Even though I'm specifying the URL in my launch.json, the browser opens at about:blank.

{
   // Use IntelliSense to find out which attributes exist for C# debugging
   // Use hover for the description of the existing attributes
   // For further information visit https://github.com/OmniSharp/omnisharp-vscode/blob/master/debugger-launchjson.md
   "version": "0.2.0",
   "configurations": [
        {
            "name": "Launch and Debug Standalone Blazor WebAssembly App",
            "type": "blazorwasm",
            "request": "launch",
            "cwd": "${workspaceFolder}",
            "url": "https://localhost:5001"
        }
    ]
}

The debug console repeats messages like these for each DLL: Loaded 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\3.1.14\System.Net.NameResolution.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.

This was working a few weeks ago. I'll try to revert to a prior version of .net core.

[captainsafia]

That seems to get me working for now. I'm still absolutely perplexed as to what could have changed to make it stop working. Do you have any insight on how I might gather where in the process this is breaking down? I'd still like to figure it out, just not sure where to begin

Yes, so about two months ago, we shipped an update to the debugging experience in Blazor. It introduced a new extension that was responsible for launching the debugging proxy on the user's local machine and returning the host the debug proxy is running on.

This extension depended on another extension that would download the .NET runtime onto the users machine (since the debugging proxy needs it to run). Recently, there was a behavior change in the extension and it no longer installs the correct runtime, the launching of the debug proxy fails, and the extension returns back undefined as the host the extension is running on.

I pushed a fallback for this but it will be fully shipped in the next release of the C# extension.

[lucaswalter]

I pushed a fallback for this but it will be fully shipped in the next release of the C# extension.

Great to hear, I've been hitting this issue as well. Is there an estimate at all for the next release?

[captainsafia]

Great to hear, I've been hitting this issue as well. Is there an estimate at all for the next release?

AFAIK, the releases happen on an as-needed basis so I'll have to follow-up to see how things are rolling there.

[lucaswalter]

Great to hear, I've been hitting this issue as well. Is there an estimate at all for the next release?

AFAIK, the releases happen on an as-needed basis so I'll have to follow-up to see how things are rolling there.

Thank you very much! Our team (and I'm sure many others) would appreciate an update.

[lucaswalter]

@captainsafia Wanted to check back in if there's an ETA for this release?

[captainsafia]

@lucaswalter We're working on inserting a couple more changes before making a release. Conservatively, I'd say before the EoM.

[captainsafia]

This issue should be resolved now with the latest version of the C# extension (v.1.23.12).