Skip to content

Source generator: Fix XML doc resolution for real projects#9041

Merged
michaelstaib merged 3 commits intoChilliCream:mainfrom
N-Olbert:XmlDocViaTrivia
Jan 16, 2026
Merged

Source generator: Fix XML doc resolution for real projects#9041
michaelstaib merged 3 commits intoChilliCream:mainfrom
N-Olbert:XmlDocViaTrivia

Conversation

@N-Olbert
Copy link
Copy Markdown
Contributor

Currently the source generator XML doc inference does not work in real world-projects.
This seems to be due to the reason that Roslyn can't access XML documentation for symbols originating outside the current project / compilation.
See dotnet/roslyn#23673 and especially dotnet/roslyn#23673 (comment) for further details.

This leads to the awkward situation that GetDocumentationCommentXml (what we currently use) only works for symbols that are part of the codebase of the source code analyzer, but not for symbols of the analyzed assembly.

This can easily be reproduced for example with:

[QueryType]
public static partial class Query
{
    /// <summary>
    /// Gets the product.
    /// </summary>
    public static int GetFoo() => 0;
}

-> For this, no description is emitted by the source generator during compilation (I actually added such a test case in this PR and tried the above sample with Rider, Visual Studio and directly from command line).

The description is indeed actually emitted within our unit tests, since within these tests all sources are part of the same assembly.
Also, Rider makes it look like the source generator emits the description, but this due to the fact that it uses a special design-time background build behind the scenes (?!).

This PR therefore gets rid of GetDocumentationCommentXml and instead resolves the XML doc headers by navigating through the syntax tree, which should always work (at least for types for which roslyn can access the source code).

Please note that this will only work when

<GenerateDocumentationFile>true</GenerateDocumentationFile>

is set in the .csproj (see dotnet/roslyn#5821).

All our current tests pass, but I haven't checked the ones from #9000. Generic types will probably not work correctly under all circumstances either, but we have no tests for them right now and I don't want to spend too much effort on this without knowing wheter it is the desired solution. Since the entire feature is best-effort only, I think thats OK.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants