[OpenAPI] error CS0122: 'Type' is inaccessible due to its protection level

[martincostello]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Relates to #60977 (comment).

Using the latest nightly build for .NET 10 preview 3, I get the following error trying to compile a test project that generates XML documentation where the tests depend on an library which references Microsoft.AspNetCore.OpenApi:

C:\Coding\martincostello\openapi-extensions\artifacts\obj\MartinCostello.OpenApi.Extensions.Tests\release_net10.0\Microsoft.AspNetCore.OpenApi.SourceGenerators\Microsoft.AspNetCore.OpenApi.SourceGenerators.XmlCommentGenerator\OpenApiXmlCommentSupport.generated.cs(188,99): error CS0122: 'XmlCommentsHelperTests.SomeClass' is inaccessible due to its protection level

The types causing the error are private nested types of a public test class.

To get that far I also had to add <InterceptorsNamespaces>$(InterceptorsNamespaces);Microsoft.AspNetCore.OpenApi.Generated</InterceptorsNamespaces>.

The raises a few questions:

1. Isn't the need to add InterceptorsNamespaces redundant these days?
2. Should the source generator be flowing transitively?
3. Should the source generator ignore projects where IsTestProject=true?

Expected Behavior

The project compiles.

Steps To Reproduce

1. Clone martincostello/openapi-extensions@6b686d9
2. Build the solution

Exceptions (if any)

No response

.NET Version

10.0.100-preview.3.25169.19

Anything else?

No response

[captainsafia]

I think the root of the issue here is the fact that our accessibility check is relaxed for comments in the same assembly. We need to do a better job of detecting between internal types that can be accessed within the assembly and private types that cannot. I'll cook up a bug fix for this.

Isn't the need to add InterceptorsNamespaces redundant these days?

I believe this is still required as a clue to the compiler about where to search for intercepted methods to bind to during the compilation phase. The property was renamed from InterceptorsPreviewNamespaces to InterceptorsNamespaces recently to account for the fact that the feature is out of preview.

Edit: Seperately it looks like the PropertyGroup I'm setting in the targets file might not be respected. I think I need to move this to a props file.

Should the source generator be flowing transitively?

Hmmm....can you clarify what you mean by this?

Should the source generator ignore projects where IsTestProject=true?

Yep, I need to update the target file to handle these kinds of exemptions and also provide a nicer disable property that doesn't require folks to manually pluck it out of the Analyzer item group.

[martincostello]

Hmmm....can you clarify what you mean by this?

What I meant was that my test project doesn't have a direct reference to M.A.OA, it's just getting it transitively from the project being tested. Was just wondering if the source generator should be running on the types in the test project at all if it isn't explicitly referencing the package?