[C# Debugger] DAP variables request returns empty in ASP.NET Core HTTP request pipeline

[odinGitGmail]

Background

I'm developing a VSCode extension to enhance the debugging experience. The original motivation was that VSCode's built-in Debug Console has a limitation: when displaying exception stack traces, clicking on file paths only navigates to the first line of the file, not the specific line number mentioned in the stack trace. This forces developers to manually search for the error location, which is very inconvenient.

My Solution: Custom Debug Window Extension

I created an extension that provides:

1. Enhanced Stack Trace Navigation

   • Clickable file paths that jump directly to the specific line number
   • Not just to the first line of the file

2. Smart Variable Parsing

   • Automatic detection and rendering of DataTable, JSON, Array, List types
   • Table view with pagination and filtering capabilities
   • Better visualization than raw text output

3. Exception Object Parsing

   • Parse C# Exception objects
   • Display Message, StackTrace, InnerException, Source, HResult, Data
   • Make stack traces clickable for easy navigation

The Problem: Cannot Access Variables in ASP.NET Core WebAPI

When extending the Exception parsing feature, I discovered a critical limitation:

What Works ✅

• Console applications: All variables accessible via DAP API
• WebAPI startup code: Variables accessible (before HTTP pipeline)
• Built-in Debug Console: Always works perfectly

What Fails ❌

• ASP.NET Core WebAPI HTTP request handling: Cannot access ANY variables via DAP API
• Occurs in Controller methods, Service methods during HTTP request processing

Technical Details

Environment

• OS: macOS
• VSCode: Latest version
• C# Extension: OmniSharp
• .NET: 8.0
• Project Type: ASP.NET Core WebAPI

DAP API Behavior

In Console Applications (✅ Works):
// Scopes request
{ "scopes": [{ "name": "Locals", "variablesReference": 1008 }] }

// Variables request
{ "variables": [
{ "name": "ex", "type": "System.Exception", "value": "...", "variablesReference": 1009 },
{ "name": "result", "type": "bool", "value": "true" }
]}

// Evaluate request
{ "result": "{System.Exception: ...}", "type": "System.Exception", "variablesReference": 1009 }In WebAPI HTTP Request Handling (❌ Fails):
// Scopes request
{ "scopes": [{ "name": "Locals", "variablesReference": 1008 }] }

// Variables request (EMPTY despite non-zero reference!)
{ "variables": [] }

// Evaluate request (FAILS)
Error: "Evaluation failed."### What I've Tested

Through extensive testing, I confirmed this is NOT caused by:

• ❌ Code optimization (Debug vs Release mode)
• ❌ IoC containers (tested with Autofac, built-in DI, no DI)
• ❌ AOP dynamic proxies (tested with/without Castle.DynamicProxy)
• ❌ Async methods (tested both async and sync methods)
• ❌ Project configuration (launch.json, .csproj settings)

The Root Cause

The issue appears to be specific to ASP.NET Core's HTTP request processing pipeline:

• Requests are handled in Kestrel server's thread pool
• Involves HTTP Context and middleware pipeline
• C# debugger's DAP cannot enumerate variables in this environment

Comparison Test Results:

Environment	Variables Accessible via DAP
Console app - all scenarios	✅ Yes
WebAPI - startup time (before HTTP)	✅ Yes
WebAPI - HTTP request handling	❌ No

Questions for the Community

1. Is this a known limitation of the C# debugger in ASP.NET Core's HTTP pipeline?

2. Why does the Debug Console work while DAP API fails?

   • Does Debug Console use a different internal API?
   • Are there additional DAP parameters that extensions should use?

3. Is there a workaround to access variables via DAP in this scenario?

4. Should I file this as a bug in the C# debugger repository, or is this expected behavior?

Current Workaround

For now, I guide users to use the built-in Debug Console (Ctrl+Shift+Y / Cmd+Shift+Y) when debugging WebAPI projects, as it's not affected by this limitation. However, this means users lose the enhanced features my extension provides (smart variable parsing, table views, clickable stack traces with line numbers).

Repository

If helpful, I can provide a minimal reproduction repository demonstrating the issue.

---

Any insights or suggestions would be greatly appreciated! 🙏