[Enhancement] C# playground: Monaco debugger toolbar — WASM + PDB (Blazor-class), breakpoints, stepping, vars #33

Open
opened 2026-04-28 23:15:56 +00:00 by spikerj · 0 comments
Owner

Summary

Add a Monaco debugger toolbar to the C# playground, using the same class of .NET WebAssembly debugging stack Blazor WebAssembly relies on: IL execution in WASM with debugger hooks, Roslyn-compiled assemblies with symbols (PDB), mapper IL ↔ C# lines, UI-driven breakpoint / step-over / step-into / step-out / continue plus locals inspection.

Architectural outline (intent)

  1. Roslyn: compile user C# → IL + PDB (or equivalent symbol payload for WASM debugger consumption).
  2. Mono/.NET WASM runtime: execute IL inside the browser worker/runtime we already shell for grading/sandbox.
  3. Debugger bridge: debugger maps IL offsets → source locations → Monaco line/column; UI sends debugger commands (continue, single-step variants, breakpoints).

Toolbar — feature parity targets

  • Breakpoints (gutter bindings ↔ runtime).
  • Step over, step into, step out, Continue.
  • Variable inspection: locals / scoped names per paused frame.
  • Current line decoration in Monaco synchronized with paused IP.

Risks / notes

  • Bundle / load cost of PDB + WASM debugger components — document tradeoffs vs teaching-grade UX gains.
  • Align with app-language-runner / grading pipeline so debug mode does not weaken isolation or confuse “certified submit” semantics—clear mode separation (Debug vs Run/Grade).
  • Edge cases: partial programs, preprocessor-only files, deterministic project layout for PDB paths.

Acceptance criteria

  • User can set breakpoints and hit them in WASM execution path used by the playground.
  • Step commands wired to WASM debugger (not façade-only).
  • Monaco shows paused line + inspectable vars aligned with PDB mapping.
  • Document limitations (threads, unsupported constructs) for curriculum authors.

Related

  • #24 Monaco migration on app-language-runner; this ticket layers debugger on top for C# specifically.
## Summary Add a **Monaco debugger toolbar** to the **C# playground**, using the **same class of .NET WebAssembly debugging stack Blazor WebAssembly relies on**: IL execution in WASM with debugger hooks, **Roslyn-compiled** assemblies with **symbols (PDB)**, mapper **IL ↔ C# lines**, UI-driven **breakpoint / step-over / step-into / step-out / continue** plus **locals** inspection. ## Architectural outline (intent) 1. **Roslyn**: compile user C# → **IL + PDB** (or equivalent symbol payload for WASM debugger consumption). 2. **Mono/.NET WASM runtime**: execute IL inside the browser worker/runtime we already shell for grading/sandbox. 3. **Debugger bridge**: debugger maps **IL offsets → source locations** → Monaco **line/column**; UI sends debugger commands (**continue**, single-step variants, breakpoints). ## Toolbar — feature parity targets - **Breakpoints** (gutter bindings ↔ runtime). - **Step over**, **step into**, **step out**, **Continue**. - **Variable inspection**: locals / scoped names per paused frame. - **Current line decoration** in Monaco synchronized with paused IP. ## Risks / notes - Bundle / load cost of PDB + WASM debugger components — document tradeoffs vs teaching-grade UX gains. - Align with **`app-language-runner` / grading pipeline** so debug mode does not weaken isolation or confuse “certified submit” semantics—clear mode separation (**Debug vs Run/Grade**). - Edge cases: partial programs, preprocessor-only files, deterministic project layout for PDB paths. ## Acceptance criteria - [ ] User can **set breakpoints** and hit them in WASM execution path used by the playground. - [ ] **Step commands** wired to WASM debugger (not façade-only). - [ ] Monaco shows **paused line + inspectable vars** aligned with PDB mapping. - [ ] Document limitations (threads, unsupported constructs) for curriculum authors. ## Related - `#24` Monaco migration on `app-language-runner`; this ticket layers **debugger** on top for **C#** specifically.
Sign in to join this conversation.