Exclude regex and alpha constraints when SlimBuilder is used.

[mitchdenny]

Background and Motivation

Modify RouteOptions to not automatically add the RegexRouteConstraint. Instead AddRouting(...) is modified to call a new method called AddRoutingCore(...) which does everything that AddRouting(...) does, but then adds the RegexRouteConstraint back in to RouteOptions.

Proposed API

namespace Microsoft.Extensions.DependencyInjection;

public static class RoutingServiceCollectionExtensions
{
+    public static IServiceCollection AddRoutingCore(this IServiceCollection services);
}

Usage Examples

We will use CreateSlimBuilder(...) to call AddRoutingOptions(...). See PR contents for an example.

Alternative Designs

This PR currently includes an AddRegexConstraint(...) method on the PR, this will likely be removed in favor of just adding the RegexRouteConstraint via the expose dictionary.

Risks

Could be somewhat confusing as to why we are excluding just the reg-ex constraint.

[mitchdenny]

Bunch of changes to make unit tests pass. Still need to do some more testing to see if this breaks any typical usage scenarios. I'm feeling great about this change at the moment - I think it carries some risk.

[davidfowl]

We shouldn't change what AddRouting does. The Slim builder should call a different API that removes these constraints. None of the tests should require updating and a new test that uses the new API should be added.

[JamesNK]

What's the error message presented to the user if someone uses the "slim" set of constraints but references regex or alpha in a route? I'm guessing it is something like "No constraint registered for 'regex'."

Here is a crazy idea: The slim set of constraints register a custom IRouteConstraint implementation for regex and alpha. The implementation does nothing but throw an exception in the constructor. The constructor error message provides information about which API someone needs to call to include the real regex and alpha implementations. When real regex and alpha implementations are included, they overwrite the error-throwing one.

The error message could be something like

Unable to create a route that uses the 'regex' constraint. The slim builder does not register this constraint by default. To use this constraint, configure routing and call AddDefaultConstraints().

A custom error can make it very obvious to users what is going on and how to fix their app.

[davidfowl]

What's the error message presented to the user if someone uses the "slim" set of constraints but references regex or alpha in a route? I'm guessing it is something like "No constraint registered for 'regex'."

See this

Here is a crazy idea: The slim set of constraints register a custom IRouteConstraint implementation for regex and alpha. The implementation does nothing but throw an exception in the constructor. The constructor error message provides information about which API someone needs to call to include the real regex and alpha implementations. When real regex and alpha implementations are included, they overwrite the error-throwing one.

This isn't crazy, it's good 😄. What would be crazy is if we could just make it work.

[davidfowl]

We're already calling UseRouting here:

aspnetcore/src/DefaultBuilder/src/WebHost.cs

Line 260 in 15d5f0c

services.AddRouting();

BTW @eerhardt this method name is very confusing:

aspnetcore/src/DefaultBuilder/src/WebHost.cs

Line 233 in 15d5f0c

internal static void UseKestrel(IWebHostBuilder builder)

It does more than adding Kestrel, we should rename it.

[mitchdenny]

Aside from some renames and perhaps alternative placement of AddRouting(...) for the non-slim builder scenario I think this does a pretty good job of avoiding breaking changes except for when someone goes and creates RouteOptions themselves and avoids using either of the two builders.

[JamesNK]

Needs unit tests of what happens when a regex constraint is used in a slim builder app - both with and without registering the regex constraint.

Also, did what are your thoughts on providing a friendly error message like I described here - #46227 (comment)