New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Epic] ASP.NET Core ❤️ Debugging #48205
Comments
Example: #48207 |
Excellent idea. Please do |
is this something community folks could help with? |
IMO no. I think it's too vague. There is experimentation and exploration in this. For example, I know debugging of Microsoft.Extensions.Hosting could be better, but I don't know how it would be better until try out debugging in that area. What do I want to know from hosting, what is available, what is the best way to present that info, etc. I think the main thing we'd want is community feedback on pain points. |
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 #39792ClaimsPrincipal
Improve debugging experience of ClaimsPrincipal runtime#86421Debugging 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#88308Debugging 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 friendsWebApplication
and friends Improve WebApplication debugging #48827Debugging 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?
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:
[DebuggerDisplay("Count = {Count}")]
Objects:
Additional context
No response
The text was updated successfully, but these errors were encountered: