Hidden Difficulties of Debugger Implementation for .NET WASM Apps
summary
Rider implements Blazor WASM debugging by running a Debug Proxy that mediates between the Chromium tab and the Mono-based runtime using the Chrome DevTools Protocol over a WebSocket; breakpoints are queued and sent before the runtime loads to avoid race conditions, a placeholder page delays user code execution, and CDP payloads use ordered request IDs and sessions. A small codegen SDK generates CDP domain bindings from JSON. Hot-reload is limited to tiny deltas (line-level method edits) under the Edit-and-Continue flow; full restarts remain necessary for larger changes.
AI-written summary · about
chapters (10)
- 0:00Debugging .NET WASM apps
- 4:42Anatomy of .NET WASM apps
- 13:39Debugging architecture for WASM
- 17:51Handshake and protocol setup
- 24:35Chrome DevTools Protocol
- 28:32CDP client and SDK
- 33:31Breakpoints and messages
- 36:22Hot reload and edit-continue
- 45:38Challenging debugging problems
- 55:00Q&A
related talks
51mHidden Difficulties Implementing a Debugger for .NET WASM Apps
01h 09mBlazor Wasm Hot Reload Explained: Real-Time Dev with Rider
01h 01mBlazor: Modern Web development with .NET and WebAssembly
29mBringing WebAssembly to the .NET Mainstream
09mBlazor with WebAssembly
51m.NET and WebAssembly: Back to the browser?
01h 04mA fistful of Blazor; Its .NET in the browser
36mBlazor - Full Stack Web Development in C# Only