Improve WebApplication debugging #48827
Conversation
JamesNK
requested review from
BrennanConroy,
Tratcher,
captainsafia,
halter73 and
mgravell
as code owners
JamesNK
force-pushed
the
jamesnk/webapplication-debugging
branch
from
dda2d17 to
4806128
Compare
JamesNK
force-pushed
the
jamesnk/webapplication-debugging
branch
from
ed8dd9d to
30ed8b3
Compare
Bad, they should at least show after build/run is called. |
There was a problem hiding this comment.
- Showing middleware would be nice
- This is a very hacky way to do it, and not very representative when there are pipeline forks involved.
- I think you're missing several other ways that middleware are defined like with the Map or Use extensions.
- I'm not sure there's a better way
- Is it worth it? Depends, what does the list look like for a real application? At least one of the more complex templates with auth and such.
Done. More hacking was required though to merge the app pipelines nicely 😬 Here you can see UseRouting/UseEndpoints/UseAuthN/UseAuthZ are automatically added because the app has an endpoint and authn/authz configured:
The delegate method name is added to the list. It's a bit ugly, but the information is there. One thing that is missing is middleware from branched pipelines (MapWhen, UseWhen). I think displaying that kind of complexity would be very tough, require some public API to build up the graph, and generally involve substantial changes This is what it looks like:
|
JamesNK
force-pushed
the
jamesnk/webapplication-debugging
branch
from
2fed5b6 to
8d5625a
Compare
|
@JamesNK make this a draft 😄 |
|
All the work-in-progress points identified at the top are done. Draft isn't necessary. It's ready for review. |
JamesNK
force-pushed
the
jamesnk/webapplication-debugging
branch
from
5b1131f to
56760c2
Compare
ghost
added this to the
| // IDebugger service can optionally be added by tests to simulate the debugger being attached. | ||
| _debugger = (IDebugger?)serviceProvider?.GetService(typeof(IDebugger)) ?? DebuggerWrapper.Instance; | ||
|
|
||
| if (_debugger.IsAttached) |
| return descriptions; | ||
| } | ||
|
|
||
| throw new NotSupportedException("Unable to get configured middleware."); |
|
This is really nice! Great work @JamesNK |
| // This type exists so the place where the source pipeline is wired into the destination pipeline can be identified. | ||
| private sealed class WireSourcePipeline(IApplicationBuilder builtApplication) | ||
| { | ||
| private readonly IApplicationBuilder _builtApplication = builtApplication; |
adityamandaleeka
added
the
blog-candidate
|
@JamesNK, this change will be considered for inclusion in the blog post for the release it'll ship in. Nice work! Please ensure that the original comment in this thread contains a clear explanation of what the change does, why it's important (what problem does it solve?), and, if relevant, include things like code samples and/or performance numbers. This content may not be exactly what goes into the blog post, but it will help the team putting together the announcement. Thanks! |
amcasey
added
area-networking
6 participants
This PR adds various debugging improvements around WebApplication.
Notable improvements:
IsRunningproperty calculated from lifetime events to quickly understand state of the appNote that the collection doesn't include middleware automatically added by WebApplication. Good or bad?Middleware automatically added when the web app starts is included.More testing is needed to ensure it hangs together when branching the app pipeline.DoneApplicationLifetime. It lives in dotnet/runtime.Will improve it later.Add DebuggerDisplay to some hosting types runtime#87599Before:
After:
App endpoints:
App middleware:
More complex example: