Skip to content
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

Open
9 of 11 tasks
JamesNK opened this issue May 12, 2023 · 4 comments
Open
9 of 11 tasks

[Epic] ASP.NET Core ❤️ Debugging #48205

JamesNK opened this issue May 12, 2023 · 4 comments
Labels
area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions

Comments

@JamesNK
Copy link
Member

JamesNK commented May 12, 2023

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.

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

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.

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:

image

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

@JamesNK
Copy link
Member Author

JamesNK commented May 12, 2023

Example: #48207

@egil
Copy link
Contributor

egil commented May 18, 2023

Excellent idea. Please do HttpClient and related types too!

@Tratcher Tratcher removed their assignment May 19, 2023
@JamesNK JamesNK changed the title ASP.NET Core ❤️ Debugging [Epic] ASP.NET Core ❤️ Debugging May 21, 2023
@danmoseley
Copy link
Member

is this something community folks could help with?

@JamesNK
Copy link
Member Author

JamesNK commented Jun 15, 2023

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.

@amcasey amcasey added area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions and removed area-runtime labels Aug 24, 2023
@dotnet-policy-service dotnet-policy-service bot added the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@wtgodbe wtgodbe removed the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@dotnet-policy-service dotnet-policy-service bot added the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 6, 2024
@wtgodbe wtgodbe removed the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Feb 13, 2024
@dotnet dotnet deleted a comment from dotnet-policy-service bot Feb 13, 2024
@dotnet dotnet deleted a comment from dotnet-policy-service bot Feb 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
Projects
None yet
Development

No branches or pull requests

7 participants
@egil @JamesNK @Tratcher @danmoseley @amcasey @wtgodbe and others