Open captainsafia opened 1 year ago
Why?
Why?
We were discussing the fact that the WebApplicationBuilder
is opinionated about the order in which middlesware are inserted. This suggestion came up as a way to provide users with a refactoring that would explicitly register the middlesware that we auto-register so that users could re-adjust the ordering when needed.
Ah, hopefully thus preventing WebApplicationBuilder from adding duplicates?
Ah, hopefully thus preventing WebApplicationBuilder from adding duplicates?
Yes. The WebApplicationBuilder actually already avoids adding duplicates so when the user does the registration in their app code in whatever order they desire we won't register the same middlewares.
Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:
API Review Notes:
dotnet_diagnostic.ASP####.severity = info
to see it?@amcasey Do you have any preference based on what other analyzers/refactorings do.
There's a fine line between sub-warning diagnostics and refactorings. The key functional differences are that code-fixes can be applied in multiple places at once (i.e. fix-all) and refactorings can take user-specified spans as inputs (e.g. for extract method).
There's probably also a (relatively minor) perf consideration - analyzers everywhere even though most hidden diagnostics will never be "fixed" and refactoring run every time the cursor is moved.
Either is probably fine in this case (unless this is the sort of thing you'd want to apply to multiple locations in the same project).
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
Background and Motivation
Proposed Analyzer
For middlesware that are registered automatically by the WebApplication, consider a refactoring to manually add them back to the application.
Analyzer Behavior and Message
Category
Severity Level
Usage Scenarios
Result:
Risks
We will not be able to place the auto-injected middleware correctly in all situations, that should be fine since this refactor is to help users be explicit about their middleware order.
Another risk is if we add more implicit middleware we'll want to keep the refactoring up to date.