OpenAPI: Fix duplicate xml documentation ids for Generic properties and references

[desjoerd]

OpenAPI: Fix duplicate xml documentation ids for Generic properties and references

Fixes two instances where xml comment documentation ids where duplicated.
First one was for constructed generic type properties. Foo<int>.
Second one was for Xml comment files exposing internal classes with the same namespace.

Fixes #64378

[desjoerd]

If someone has a better idea for this, let me know. The main difference compared to ParseCommentsApplicationAssembly is that it only allows "accessible" types

[dotnet-policy-service]

Thanks for your PR, @@desjoerd. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[Copilot]

Pull Request Overview

This PR fixes duplicate XML documentation IDs in OpenAPI source generation by addressing two specific issues:

1. Generic type properties with different type arguments (e.g., GenericFoo<string> vs GenericFoo<int>) were generating duplicate documentation IDs
2. Internal classes with the same namespace in different referenced assemblies were causing duplicate documentation IDs

Key Changes

• Separated comment parsing logic into application assembly vs reference assembly methods
• Modified AssemblyTypeSymbolsVisitor to use unbound generic types for documentation ID generation
• Added new test case to verify that duplicate documentation IDs are not generated

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
XmlCommentDocumentationIdTests.cs	Added comprehensive test case verifying that generic properties and duplicate internal classes don't cause duplicate documentation IDs
OpenApiXmlCommentSupport.generated.verified.cs	Generated snapshot file showing expected output with properly deduplicated documentation IDs
XmlCommentGenerator.cs	Renamed ParseComments to separate methods for application and reference assemblies
XmlCommentGenerator.Parser.cs	Split comment parsing into two methods with different filtering logic for application vs reference assemblies
AssemblyTypeSymbolsVisitor.cs	Added logic to convert constructed generic types to unbound generic types for consistent documentation ID generation

[austindrenski]

@desjoerd this seems okay, but should this PR also revisit the use of symbol.IsAccessible() up on L124?

Specifically, it seems like this source generator should default to excluding types marked with EmbeddedAttribute, since those are accessible from the application assembly, but seem to be of dubious worth w.r.t. embedding constants into the assembly for (what I assume are largely going to be) marker attributes for source generators, dev dependencies, etc.

(e.g. thinking about this from the aot perspective where I don't want paragraphs and paragraphs xml docs from internal/dev-time-only marker attributes getting baked into the executable)

[desjoerd]

For the application assembly types with [Embedded] are accessible and could even be used within your Api I think.

For referenced assemblies they will be already excluded as it will only emit xml comments for types marked as public.
https://github.com/dotnet/aspnetcore/blob/main/src%2FOpenApi%2Fgen%2FHelpers%2FISymbolExtensions.cs#L193

[captainsafia]

Hmmm...is this change related to the fix for generic types?

[desjoerd]

This one is to fix the comments coming from a documentation file when a type also exists in the main compilation.

When an internal type with the same namespace and class name exists in the Application assembly.

In the unit tests it's the Sample.Duplicate which is internal in the Application assembly. When it processes it from a different assembly it would resolve to Sample.Duplicate.

I duplicated the ParseComments into ParseCommentsReference and ParseCommentsApplicationAssembly to have a different condition. ParseCommentsReference only includes public types. ParseCommentsApplicationAssembly includes public types and types available in the compilation.