[Epic] ASP.NET Core ❤️ Debugging · Issue #48205 · dotnet/aspnetcore (original) (raw)

This issue has evolved into an epic for making debugging better across ASP.NET Core

There are two primary areas we want to hit:

Debugging HTTP requests. This means HttpContext and friends are easily debuggable.

• HttpContext and friends (this issue)
• Endpoint/endpoint metadata Improve endpoint metadata debugging by overriding ToString #39792
• ClaimsPrincipal Improve debugging experience of ClaimsPrincipal runtime#86421

Debugging hosting. Give feedback about whether a host is running, its name, and its environment (i.e. Production vs Development).

• IHost and related types Improve Hosting debugging runtime#88308

Debugging application startup. I think there is a lot that could be done here. ASP.NET Core has a lot of configuration settings, and we should figure out where to focus energy to provide the best value.

• WebApplicationBuilder and friends
• WebApplication and friends Improve WebApplication debugging #48827
• Microsoft.Extensions.Configuration Improve debugging experience of Microsoft.Extensions.Configuration runtime#86550
• Microsoft.Extensions.DependencyInjection Improve debugging experience of Microsoft.Extensions.DependencyInjection runtime#86553
• Microsoft.Extensions.Logging Improve LoggerFactory and Logger debugging runtime#88313 Add DebuggerDisplay to Logger and Logger runtime#87754

Debugging connections. This would be the ConnectionContext that is available in connection middleware and Kestrel transports. Lesser used area.

• ConnectionContext, MultiplexConnectionContext

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

It's very common to debug HTTP requests in an ASP.NET Core app. For example, you want to check the client has sent the request you expect. What are the request headers? Query string? Form values? Cookies? Or you want to check the response. Has the response started? What is the status code? etc.

This is what HttpContext looks like today when debugging in VS:

It's not horrible. But it's not great.

In this result you can see that CancellationToken uses debugger display attribute to display at a glance whether the token is canceled or not. That's a great use of customizing .NET debugging.

Wouldn't it be useful if the other properties on HttpContext were just as informative? For example, the collections here and on request and response told you their counts: Cookies Count = 1. Or the connection property displayed the connection's local and remote addresses. Or the request property displayed the request method and URL.

We have the tools and technology to make it better:

• DebuggerDisplayAttribute
• DebuggerTypeProxyAttribute

Describe the solution you'd like

Let's make a concerted effort to improve debugging HttpContext with debugging attributes.

Collections:

• Debugger display attributes that shows item count: [DebuggerDisplay("Count = {Count}")]
• Debugger type proxy to make viewing collection contents easier

Objects:

• Debugger display attributes that shows a summary of the object. For example:
  • HttpRequest: Method and URL.
  • HttpResponse: HasStarted and StatusCode
  • Connection: Local and remote addresses

Additional context

No response