[.NET 10] ValidationsGenerator throws some errors due to inaccessibility

[erwinkramer]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I'm setting up validation but it throws some errors during build.

Expected Behavior

No response

Steps To Reproduce

Build this feature branch: https://github.com/erwinkramer/bank-api/tree/feature/dotnet10

I also attempted to add <InterceptorsNamespaces>$(InterceptorsNamespaces);Microsoft.AspNetCore.Http.Validation.Generated</InterceptorsNamespaces> but it doesn't change the errors.

Exceptions (if any)

C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\obj\Debug\net10.0\Microsoft.Extensions.Validation.ValidationsGenerator\Microsoft.Extensions.Validation.ValidationsGenerator\ValidatableInfoResolver.g.cs(433,112): error CS0122: 'InternalEntryBase.StateData' is inaccessible due to its protection level [C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\BankApi.Service.Beta.csproj]
C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\obj\Debug\net10.0\Microsoft.Extensions.Validation.ValidationsGenerator\Microsoft.Extensions.Validation.ValidationsGenerator\ValidatableInfoResolver.g.cs(436,114): error CS0122: 'InternalEntryBase.StateData' is inaccessible due to its protection level [C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\BankApi.Service.Beta.csproj]
C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\obj\Debug\net10.0\Microsoft.Extensions.Validation.ValidationsGenerator\Microsoft.Extensions.Validation.ValidationsGenerator\ValidatableInfoResolver.g.cs(439,132): error CS0122: 'InternalEntryBase.StateData' is inaccessible due to its protection level [C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\BankApi.Service.Beta.csproj]
C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\obj\Debug\net10.0\Microsoft.Extensions.Validation.ValidationsGenerator\Microsoft.Extensions.Validation.ValidationsGenerator\ValidatableInfoResolver.g.cs(491,130): error CS0122: 'InternalEntryBase.StateData' is inaccessible due to its protection level [C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\BankApi.Service.Beta.csproj]
C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\obj\Debug\net10.0\Microsoft.Extensions.Validation.ValidationsGenerator\Microsoft.Extensions.Validation.ValidationsGenerator\ValidatableInfoResolver.g.cs(1694,60): error CS0122: 'BlobClientConfiguration' is inaccessible due to its protection level [C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\BankApi.Service.Beta.csproj]
C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\obj\Debug\net10.0\Microsoft.Extensions.Validation.ValidationsGenerator\Microsoft.Extensions.Validation.ValidationsGenerator\ValidatableInfoResolver.g.cs(1697,62): error CS0122: 'BlobClientConfiguration' is inaccessible due to its protection level [C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\BankApi.Service.Beta.csproj]
C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\obj\Debug\net10.0\Microsoft.Extensions.Validation.ValidationsGenerator\Microsoft.Extensions.Validation.ValidationsGenerator\ValidatableInfoResolver.g.cs(1700,80): error CS0122: 'BlobClientConfiguration' is inaccessible due to its protection level [C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\BankApi.Service.Beta.csproj]
C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\obj\Debug\net10.0\Microsoft.Extensions.Validation.ValidationsGenerator\Microsoft.Extensions.Validation.ValidationsGenerator\ValidatableInfoResolver.g.cs(1716,78): error CS0122: 'BlobClientConfiguration' is inaccessible due to its protection level [C:\Users\erwin\Repos\bank-api\BankApi.Service.Beta\BankApi.Service.Beta.csproj]

.NET Version

10.0.100-preview.6.25358.103

Anything else?

I assume it tries to read DI-types like BlobServiceClient as used here: https://github.com/erwinkramer/bank-api/blob/63f70f94e03674335d99a78da900707deacf522b/BankApi.Core/Implementation/Operation.Teller.cs#L24

[captainsafia]

@erwinkramer Does the error repro if you add a [FromService] attribute to this parameter?

To elaborate, we currently skip validation if the parameter has a FromService attribute or is present in the DI container when the validation filter runs (see here).

[erwinkramer]

Thanks @captainsafia, yeah it goes away when i add it to BankDb and BlobServiceClient. See commit: erwinkramer/bank-api@e7a6818.

we currently skip validation if the parameter has a FromService attribute or is present in the DI container when the validation filter runs

These services are added before i even call AddValidation. So that doesn't necessarily mean it's "present in the DI container when the validation filter runs" then?

[captainsafia]

These services are added before i even call AddValidation. So that doesn't necessarily mean it's "present in the DI container when the validation filter runs" then?

Yep, I find it surprising that the check didn't work in this case, especially because you are using the service that was already present in the container. Some debugging on the codepath referenced above is required to dive into things further. The test that validates this behavior is here: https://github.com/dotnet/aspnetcore/blob/main/src/Validation/test/Microsoft.Extensions.Validation.GeneratorTests/ValidationsGenerator.Parameters.cs#L33

[mikekistler]

I just ran into this too. Here's my repro:

https://github.com/mikekistler/ModernWebApis/tree/preview6

[captainsafia]

OK, I took a closer look at this and need to correct my claims in this comment.

The source generator requires the [FromServices] and [FromKeyedServices] attributes to determine if a type needs to be skipped over because it comes from DI. The IServiceProviderIsService check only applies for the runtime resolver which isn't at play here.

Now, one thing we can do here is special case types that inherit from DbContext in the source generator check in the same way that we exempt things like HttpContext and HttpRequest. It's not fool-proof for all service types but it's our best option for something implicit absent the attributes.

Edit: In tinkering with this approach, I realize that our current type check implementation is optimized for types that are part of the shared framework since we build on the WellKnownTypes check. We could add seperate logic that is entirely string-based although that opens up another issue with which times we exempt by default.

So, best option might be to skip over the private types here to avoid the compilation errors -- then the runtime checks should kick in after the fact.