RDG does not support generic types from outer scope

[halter73]

Given the code:

public static void TestGenericParam<TUser>(IEndpointRouteBuilder app) where TUser : class
{
    app.MapPost("/test-param", ([FromServices] UserManager<TUser> userManager) => { });
}

public static void TestGenericResponse<TUser>(IEndpointRouteBuilder app) where TUser : new()
{
    app.MapPost("/test-return", () => new TUser());
}

RDG will generate code that fails to compile because TUser is undefined. As a short-term mitigation, we can skip generating MapPost and similar methods when we see an open generic parameter in the delegate signature. Long term, we can look at flowing the generic parameters through the Map methods we generate which can then hopefully be inferred.

GeneratedRouteBuilderExtensions.g.cs(73,85): error CS0246: The type or namespace name 'TUser' could not be found (are you missing a using directive or an assembly reference?)
GeneratedRouteBuilderExtensions.g.cs(88,33): error CS0246: The type or namespace name 'TUser' could not be found (are you missing a using directive or an assembly reference?)

        internal static global::Microsoft.AspNetCore.Builder.RouteHandlerBuilder MapPost(
            this global::Microsoft.AspNetCore.Routing.IEndpointRouteBuilder endpoints,
            [global::System.Diagnostics.CodeAnalysis.StringSyntax("Route")] string pattern,
            global::System.Action<global::Microsoft.AspNetCore.Identity.UserManager<TUser>> handler, // <---- Error!
            [global::System.Runtime.CompilerServices.CallerFilePath] string filePath = "",
            [global::System.Runtime.CompilerServices.CallerLineNumber]int lineNumber = 0)
        {
// ...
                            handler(ic.GetArgument<global::Microsoft.AspNetCore.Identity.UserManager<TUser>>(0)!);
// ... 
                        var userManager_local = httpContext.RequestServices.GetRequiredService<Microsoft.AspNetCore.Identity.UserManager<TUser>>();
// ...
                    var handler = (Func<TUser>)del;
// ...
                    var jsonTypeInfo =  (JsonTypeInfo<TUser>)serializerOptions.GetTypeInfo(typeof(TUser));

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. 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.

[halter73]

FWIW, I worked around this in MapIdentityApi<TUser> by injecting IServiceProvider instead of UserManager<TUser> the and calling GetRequiredService<UserManager<TUser>>() inside the body of the route handler.

[captainsafia]

I investigated what it would look like to add support for this but ultimately believe that it should be done after #48289 and dotnet/roslyn#68218 are resolved.

A current limitation in the interceptors feature is that it does not support intercepting methods with generic type arguments. This gives us three options with how to handle this moving forward:

• Implement support for endpoints that capture type parameters using overload resolution semantics and use interceptors for other endpoints. This is the least ideal option, because although we end up supporting this scenario, we do so at the cost of a straightforward generator implementation and a less robust interceptors API.
• Add support for intercepting generic methods in the interceptors feature and leverage that in the implementation. This is the ideal scenarios as it means that our source generator can rely on one strategy for intercepting method calls (using the interceptors feature) and the interceptors feature is made more robust.
• Do not support this feature (for now maybe).

My preference is the 2nd, 3rd, and 1st options in that order. I'd like to move us away from a world where we ship a generator that has two different interception strategies that we need to support for the lifetime of 8.0.