RouteConstraints aren't linker friendly

[davidfowl]

Today RouteConstraints are described by a RouteOptions.ConstraintMap. The issue with this approach is the linker doesn't have way to know that these types are activated elsewhere in the system. We need an API that lets us describe adding a constraint that is type safe and lets us describe that we want to preserve constructors:

public class RouteOptions
{
    public void AddParameterPolicy<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicConstructors)]T>(string text) where T : IParameterPolicy;
    public void AddParameterPolicy(string text, [DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicConstructors)]Type constraintType);
}

This would let the linker know that these constraint types should be kept around.

Here's the current warning:

C:\dev\git\aspnetcore\src\Http\Routing\src\ParameterPolicyActivator.cs(93,13): Trim analysis warning IL2006: Microsoft.AspNetCore.Routing.ParameterPolicyActivator.CreateParameterPolicy(IServiceProvider,Type,String): The parameter 'parameterPolicyType' of method 'Microsoft.AspNetCore.Routing.ParameterPolicyActivator.CreateParameterPolicy(IServiceProvider,Type,String)' with dynamically accessed member kinds 'None' is passed into the implicit 'this' parameter of method 'System.Type.GetConstructors()' which requires dynamically accessed member kinds 'PublicConstructors'. To fix this add DynamicallyAccessedMembersAttribute to it and specify at least these member kinds 'PublicConstructors'. [C:\Users\davifowl\source\repos\WebApplication60\WebApplication60\WebApplication60.csproj]

[ghost]

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.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mkArtakMSFT]

@davidfowl we don't plan to handle this in 6.0 If you neither, feel free to move to backlog.

[ghost]

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.

[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.

[pranavkm]

API review:

Approved API:

public class RouteOptions
{
+    public void SetParameterPolicy<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicConstructors)]T>(string text) where T : IParameterPolicy;
+    public void SetParameterPolicy(string text, [DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicConstructors)]Type constraintType);
}

The API is approved. We we want to prevent users from mutating Routeoptions.ConstraintMap since that could again introduce trimmer unfriendly behavior. We think the best way to do this is to annotate the property with RequiresUnreferencedCodeAttribute and make a note that says the warning can be suppressed if all they are doing is reading or deleting from the dictionary.

The API is named Setxxx since it will always replace an existing key.