RDG does not support private parameter and return types

[halter73]

Given the code:

public class MyClass
{

    public static void MyMethod(IEndpointRouteBuilder app)
    {
        app.MapPost("/test-param", (MyDto param) => { });
        app.MapPost("/test-return", () => new MyDto());
    }

    private class MyDto { }
}

RDG generates code that fails to compile because MyDto is a private type. The lines that cause the compilation failure by referencing the private type are basically the same lines that fail with an undefined TUser in #47338 which is the equivalent issue about generic types.

We can skip generating MapPost and similar methods when we see a private type in the delegate signature and suggest using internal types instead. I don't think we really have an alternative unless we could somehow generate our Map extension methods directly in the same class/struct the user is calling it from. I don't know of any plans for that.

GeneratedRouteBuilderExtensions.g.cs(73,111): error CS0122: 'MyClass.MyDto' is inaccessible due to its protection level
GeneratedRouteBuilderExtensions.g.cs(88,109): error CS0122: 'MyClass.MyDto' is inaccessible due to its protection level

[captainsafia]

I don't think we really have an alternative unless we could somehow generate our Map extension methods directly in the same class/struct the user is calling it from.

Yeah, our best option is to emit a diagnostic and fallback to the runtime behavior here. Even if we solve the problem of having to use the unspeakable names in the strongly-typed endpoint overloads (via the interceptors proposal say), we still have the dilemma of needing to reference these types in the generated request handlers when we bind parameters or emit responses.

#47338 is similar but, unlike this one, it is solvable if we implement support for generic thunks in the request delegate generator.

This is one of these issues I'd be curious to get community feedback one once RDG is out. I dunno how common it is to have private DTO classes considering that you might need to access them in unit or integration tests.

[captainsafia]

I think this should be moved out of preview4 for now.

[ghost]

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.