[Analyzer] Unused route parameter detection and fixer

[JamesNK]

Background and Motivation

When adding a route parameter to a minimal API or action:

1. The route parameter needs to be added to the route
2. .NET parameter needs to be added to the lambda/method.

An analyzer and fixer can automate step 2.

Proposed API

An analyzer inspects the route for route parameters and the lambda/action parameters. If the route has a parameter that isn't present in the lambda/action then the analyzer will suggest a fix.

• Suggestion level (it's valid to have a route parameter that's not used so this isn't a warning)
• Optional route parameter = nullable argument
• Route parameter constraint is used to infer the .NET type. e.g. int constraint = int method parameter. Same with guid, int, long, double, float, datetime, decimal, etc. No route parameter means the new parameter type is string.
• Put the new parameter in the method based on its position in the route.

Usage Examples

Alternative Designs

Risks

[ghost]

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:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[ghost]

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:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[JamesNK]

Double check it works with RequestDelegate overload.

[halter73]

API Review Notes:

• It does seem unusual to define a route value and not take it as a parameter to your delegate.
• This will file a lot on older code using the RequestDelegate overload, but maybe that's okay.
• This will recommend changing to an API that is less trim safe in some cases.

Category: Usage
Severity: Info