Closed vsfeedback closed 1 year ago
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
@lewing FYI
Tagging subscribers to 'arch-wasm': @lewing See info in area-owners.md if you want to be subscribed.
Author: | vsfeedback |
---|---|
Assignees: | - |
Labels: | `arch-wasm`, `untriaged`, `area-VM-meta-mono`, `blazor-wasm`, `Author: Migration Bot :robot:` |
Milestone: | - |
Tagging subscribers to this area: @thaystg See info in area-owners.md if you want to be subscribed.
Author: | vsfeedback |
---|---|
Assignees: | - |
Labels: | `arch-wasm`, `untriaged`, `area-Debugger-mono`, `area-VM-meta-mono`, `blazor-wasm`, `Author: Migration Bot :robot:` |
Milestone: | - |
Which version of dotnet are you using?
@thaystg fyi:
fail: Microsoft.WebAssembly.Diagnostics.DevToolsProxy[0] DevToolsProxy::Run: Exception System.ArgumentException: The tasks argument included a null value. (Parameter 'tasks') at System.Threading.Tasks.Task.WhenAny(Task[] tasks) at Microsoft.WebAssembly.Diagnostics.DevToolsProxy.Run(Uri browserUri, WebSocket ideSocket)
Probably is using dotnet version 7.x and the .nuget package where is BrowserDebugProxy 6.x. This combination would cause this error.
Can we add something to match the versions, so we can fail with a descriptive error?
We could for sure change the debugger protocol version and throw an error if the versions doesn't match. I really don't like the idea of changing the SDB protocol version, because it's not a change on SDB, it's the change from javascript to typescript that removed the MONO variable, as we decided. So if you and Larry think that makes sense, I think we could add another version for javascript and BrowserDebugProxy compatibility. Also we could ship BrowserDebugProxy as part of the runtime, so we wouldn't see this kind of incompatibility?
Also we could ship BrowserDebugProxy as part of the runtime, so we wouldn't see this kind of incompatibility?
Yeah, we are looking at that now.
I have an idea, will take a closer look this week
This is difficult to fix without tying the proxy to the proxy to the runtime version which will mean shipping it from runtime instead of aspnetcore.
@thaystg assuming we don't want to stick it in the runtime pack we'll need to change the proxy from a transport package to a shipping one and pull the package version from the runtime version in the workload logic
@thaystg assuming we don't want to stick it in the runtime pack we'll need to change the proxy from a transport package to a shipping one and pull the package version from the runtime version in the workload logic
This will be useful for WasmAppHost too, which currently does include the proxy.
I gave it some more thought and the only way they could end up with a 7 dev server and a net-6.0 runtime is if they had mismatched versions in the csproj as in an a TargetFramwork of net6 plus the a net7 dev server package reference which is impossible to entirely prevent. We could add a version check just to make the problem clearer if they setup an invalid config by hand.
I am getting the same error as Op. Seems like this happens periodically with my Blazor WASM app. Running .Net 6. Any solution to this?
@enantiomer2000 you should not see this if you are using the .net6 runtime and also the devserver package from .net6. Is this your case?
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="6.0.8" PrivateAssets="all" />
@thaystg Yes Microsoft.AspNetCore.Components.WebAssembly.DevServer is installed on the WASM client project. Debugging does work except for when it just stops working and I get the same message as Op. I tried making sure that the relevant projects were at the latest 6.0.9 versions which didn't help. It happens every few days it seems. It happened yesterday and I poked at it for a while futilely until I just rebooted my machine upon which time it started working again. I would be happy to help get more info for you if you want it.
@enantiomer2000 when it happens again please share with me this file:
C:\Users\[USER_NAME]\AppData\Local\Temp\visualstudio-js-debugger.txt
@enantiomer2000 when it happens again please share with me this file:
C:\Users\[USER_NAME]\AppData\Local\Temp\visualstudio-js-debugger.txt
I'm experiencing this same issue with .NET 6 Blazor WASM I've confirmed we have Microsoft.AspNetCore.Components.WebAssembly.DevServer v6.0.7 installed on the advice above. Here is the visualstudio-js-debugger.txt file
@Glitched94 , are you creating a new app? It happens always when you start debugging or after some navigation in the app?
@Glitched94 , are you creating a new app? It happens always when you start debugging or after some navigation in the app?
It's an existing app that we originally wrote in .NET 5 Blazor WASM and upgraded to .NET 6 about 5 months ago. The issue happens after some page navigations. Where it happens is seemingly random, but once it starts happening, it can be repeated at the same spot multiple times. Eventually the builds stop crashing and we can navigate past that spot, but eventually it'll pop up again in another, or occasionally the same spot as well.
Do you have any redirection to a non-wasm page, like a login page or something like this in your app?
Our app only has client-sided wasm pages, the server is only for serving up the data. The only .cshtml we have is the error page from the app template that we just never removed or modified.
@Glitched94 , the error message that you see in the console is exactly the same that is in the issue description? Can you paste yours here?
Also, can you help me to reproduce it with some code sample or more information that may be helpful?
Does the debugger always crash after an error like this: Uncaught Error Error: JWT token expired
?
@thaystg The error message is not identical to the one at the very top, but one lower on the page:
fail: Microsoft.WebAssembly.Diagnostics.DevToolsProxy[0] DevToolsProxy::Run: Exception System.ArgumentException: The tasks argument included a null value. (Parameter 'tasks') at System.Threading.Tasks.Task.WhenAny(Task[] tasks) at Microsoft.WebAssembly.Diagnostics.DevToolsProxy.Run(Uri browserUri, WebSocket ideSocket)
There's no other error message accompanying this message.
The debugging bug happened again just now. Attached is the content from visualstudio-js-debugger.txt file.
From Console output:
Error on mono_wasm_get_loaded_files [Result: IsOk: False, IsErr: True, Value: , Error: {
"result": {
"type": "object",
"subtype": "error",
"className": "ReferenceError",
"description": "ReferenceError: MONO is not defined\n at
Blazor_WASM_LogFileContent.txt
The debugging bug happened again just now. Attached is the content from visualstudio-js-debugger.txt file.
From Console output: Error on mono_wasm_get_loaded_files [Result: IsOk: False, IsErr: True, Value: , Error: { "result": { "type": "object", "subtype": "error", "className": "ReferenceError", "description": "ReferenceError: MONO is not defined\n at :1:1", "objectId": "2790414281955586462.7.11" }, "exceptionDetails": { "exceptionId": 7, "text": "Uncaught", "lineNumber": 0, "columnNumber": 0, "scriptId": "129", "stackTrace": { "callFrames": [ { "functionName": "", "scriptId": "129", "url": "", "lineNumber": 0, "columnNumber": 0 } ] }, "exception": { "type": "object", "subtype": "error", "className": "ReferenceError", "description": "ReferenceError: MONO is not defined\n at :1:1", "objectId": "2790414281955586462.7.12" } } } ] Failed to get the list of loaded files. Managed code debugging won't work due to this.
@thaystg, any feedback on my log file? It would be nice not to have to reboot my machine periodically because of this.
I have been experiencing the same thing since upgrading to .NET 6 from .NET 5.
Same thing here
If anyone can share with us the source code and steps to reproduce it would be great. I'm still trying to reproduce.
I cannot share the source code but I would be willing to have someone remote in to my workstation.
I'm seeing the same issue using Identity Server with a CSHTML login page. The debugger detaches when the app reloads after successfully logging in. I've found deleting the bin and obj folders, restoring my nuget packages and doing a rebuild can resolve the issue for a little while. Sometimes I have to combine the aforementioned steps with closing down Visual Studio and deleting the .vs folder for the solution to be able to get the debugger to remain attached.
@thaystg I spoke with my client and they are willing to give your team access the github repo for the project I'm working on so your team can try to repro the issue.
@gerfen , perfect, as soon as I have access I can work on fixing it. Thanks a lot.
@thaystg Excellent!
I'll need an email address so I can have an invite sent to you. I'll also need to create some documentation for you to get the project setup. FWIW, I'm using the latest Blazor preview bits so you'll need VS 2002 Version 17.4.0 Preview 4.0 as well.
My github email is: thaystg@gmail.com
@thaystg Excellent!
I'll need an email address so I can have an invite sent to you. I'll also need to create some documentation for you to get the project setup. FWIW, I'm using the latest Blazor preview bits so you'll need VS 2002 Version 17.4.0 Preview 4.0 as well.
I'll pass your email along to my customer so they can send you an invite. I'll be in touch soon. Thanks!
@thaystg Any idea when this fix will get pushed to GA?
@gerfen this wil be available in the first servicing release.
@thaystg Great! Thanks for the update.
@thaystg It appears that this issue was fixed with the release of VS 17.4.3 via #77501? Just wanted to confirm. Thanks!
@gerfen My team is still having the issue. I'm using 17.4.3
I'm still getting:
fail: Microsoft.WebAssembly.Diagnostics.DevToolsProxy[0] DevToolsProxy::Run: Exception System.ArgumentException: The tasks argument included a null value. (Parameter 'tasks') at System.Threading.Tasks.Task.WhenAny(Task[] tasks) at Microsoft.WebAssembly.Diagnostics.DevToolsProxy.Run(Uri browserUri, WebSocket ideSocket)
and
fail: Microsoft.WebAssembly.Diagnostics.DevToolsProxy[0] sending error response for id: msg-47D4B7EFFBFFB45013F58C6C76170FFC:::1017 -> [Result: IsOk: False, IsErr: True, Value: , Error: { "code": -32601, "message": "'DotnetDebugger.setDebuggerProperty' wasn't found" } ]
@54696d20 which version of this package are you using?
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="7.0.1" PrivateAssets="all" />
@thaystg We didn't upgrade to 7.0 because we are still on 6
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="6.0.3" PrivateAssets="all" />
Can you upgrade to 6.0.12?
@thaystg We didn't upgrade to 7.0 because we are still on 6
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="6.0.3" PrivateAssets="all" />
Yes, but still received the same errors. Looked like the same error. Upgrading to it now and will get back with you
fail: Microsoft.WebAssembly.Diagnostics.DevToolsProxy[0] DevToolsProxy::Run: Exception System.ArgumentException: The tasks argument included a null value. (Parameter 'tasks') at System.Threading.Tasks.Task.WhenAny(Task[] tasks) at Microsoft.WebAssembly.Diagnostics.DevToolsProxy.Run(Uri browserUri, WebSocket ideSocket)
Is the error I receive when I upgraded it to 6.0.12. I worked for a bit without issue. I received the error when I stopped and started it again.
Can you share with us a sample project where I can reproduce it?
I knew you'd say that lol. I'd ask the same thing. Let me see what I can do by recreating it in a new project. Unfortunately, the project I'm working on cannot be shared.
I think I don't need it, we have a fix for it in .net7, I'll try to backport it to 6.
This issue has been moved from a ticket on Developer Community.
[severity:It's more difficult to complete my work] About 8 out of the 10 times I run my Blazor UI project, Visual Studio crashes and gives me this error:
Original Comments
Feedback Bot on 4/22/2022, 02:17 AM:
(private comment, text removed)
Original Solutions
(no solutions)