search

dotnet / runtime

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

[.NET8 + WebAssembly] Debugging experience still is far from being 'OK' #97097

Open javiercn opened 10 months ago

javiercn commented 10 months ago

Discussed in https://github.com/dotnet/aspnetcore/discussions/52289

Originally posted by **DierkDroth** November 22, 2023 Since the first days of .NET + WebAssembly many years back I'm looking forward to finally get a debugging experience which would make it possible to do 'native' development in .NET and WebAssembly. Unfortunately the debugging experience even got worse with .NET 8 - as just experienced (again): - starting the debugging sessions takes > 5 times longer than starting the WASM app from VisualStudio without debugging - as a breakpoint it hit it takes ~30 seconds until VisualStudio finally broke - removing a breakpoint while debugging just is not effective: although VS no longer would show the breakpoint, it's still triggered - terminating the debugging sesison could freeze VisualStudio for several minutes until it finally becomes responsive again - and so on and so on... Do we 'have to live' with that bad debugging experience going forward - implying in my case that I keep doing the actual development work in WindowsAppSDK - or is there any significant improvement in sight? My setup: latest VisualStudio, latest Windows 11, latest .NET 8. latest Chrome, state-of-the-art development machine. I'm working on a Platform UNO project. I activate debugging by enabling this line in my launchSettings.json: ` "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}"`
ghost commented 10 months ago

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

Issue Details
### Discussed in https://github.com/dotnet/aspnetcore/discussions/52289
Originally posted by **DierkDroth** November 22, 2023 Since the first days of .NET + WebAssembly many years back I'm looking forward to finally get a debugging experience which would make it possible to do 'native' development in .NET and WebAssembly. Unfortunately the debugging experience even got worse with .NET 8 - as just experienced (again): - starting the debugging sessions takes > 5 times longer than starting the WASM app from VisualStudio without debugging - as a breakpoint it hit it takes ~30 seconds until VisualStudio finally broke - removing a breakpoint while debugging just is not effective: although VS no longer would show the breakpoint, it's still triggered - terminating the debugging sesison could freeze VisualStudio for several minutes until it finally becomes responsive again - and so on and so on... Do we 'have to live' with that bad debugging experience going forward - implying in my case that I keep doing the actual development work in WindowsAppSDK - or is there any significant improvement in sight? My setup: latest VisualStudio, latest Windows 11, latest .NET 8. latest Chrome, state-of-the-art development machine. I'm working on a Platform UNO project. I activate debugging by enabling this line in my launchSettings.json: ` "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}"`
Author: javiercn
Assignees: -
Labels: `area-Diagnostics-coreclr`
Milestone: -
ghost commented 10 months ago

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

Issue Details
### Discussed in https://github.com/dotnet/aspnetcore/discussions/52289
Originally posted by **DierkDroth** November 22, 2023 Since the first days of .NET + WebAssembly many years back I'm looking forward to finally get a debugging experience which would make it possible to do 'native' development in .NET and WebAssembly. Unfortunately the debugging experience even got worse with .NET 8 - as just experienced (again): - starting the debugging sessions takes > 5 times longer than starting the WASM app from VisualStudio without debugging - as a breakpoint it hit it takes ~30 seconds until VisualStudio finally broke - removing a breakpoint while debugging just is not effective: although VS no longer would show the breakpoint, it's still triggered - terminating the debugging sesison could freeze VisualStudio for several minutes until it finally becomes responsive again - and so on and so on... Do we 'have to live' with that bad debugging experience going forward - implying in my case that I keep doing the actual development work in WindowsAppSDK - or is there any significant improvement in sight? My setup: latest VisualStudio, latest Windows 11, latest .NET 8. latest Chrome, state-of-the-art development machine. I'm working on a Platform UNO project. I activate debugging by enabling this line in my launchSettings.json: ` "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}"`
Author: javiercn
Assignees: -
Labels: `arch-wasm`, `untriaged`
Milestone: -
javiercn commented 10 months ago

/cc @thaystg