Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Produce type/member level source link information in docs xml #71953

Open
huangmin-ms opened this issue Feb 4, 2024 · 2 comments
Open

Produce type/member level source link information in docs xml #71953

huangmin-ms opened this issue Feb 4, 2024 · 2 comments

Comments

@huangmin-ms
Copy link

huangmin-ms commented Feb 4, 2024

Summary

For every .NET project that enabled SourceLink, the source link information will be embedded in CustomDebugInformation table of its PDB. However, this is not sufficient to build a type/member level source map without information from Document and MethodDebugInformation tables.

Background and Motivation

My team is responsible for publishing .NET and other reference docs on https://learn.microsoft.com/en-us/dotnet/api/. We have received a lot of user feedback regarding linking docs page to their GitHub source code. For example, MicrosoftDocs/feedback#3099
Currently what we have are the DLLs or NuGet packages provided by our partner teams and based on that we have figured out we can use the DLL to find its corresponding PDB and then use the information in PDB to build the source links for each type/member in the DLL.

During our investigation, we found:

  1. Reference assemblies don't have PDBs. To work around, we decided to download the runtime package and try to find the impl assemblies there. e.g. https://www.nuget.org/packages/Microsoft.NETCore.App.Runtime.win-x64/6.0.23
  2. If a type (interface/Enum etc.) doesn't have any method, then it won't be recorded in MethodDebugInformation table, Roslyn introduced a new GUID TypeDefinitionDocuments to solve this.
    public static readonly Guid TypeDefinitionDocuments = new("932E74BC-DBA9-4478-8D46-0F32A7BAB3D3");
    But it is not documented in https://github.com/dotnet/runtime/blob/main/docs/design/specs/PortablePdb-Metadata.md and I probably never know that without asking around.
  3. I have gone through this doc https://devblogs.microsoft.com/dotnet/go-to-definition-improvements-for-external-source-in-roslyn/ and found Go to definition has built most of what we want. One difference is that GTD is triggered per symbol while we need to enumerate all the symbols.

After a lot of researching and discussing we found that it is not as easy/straightforward as we think to generate a source map based on the PDB by ourselves. And since Roslyn has already built the logic, is it possible for the compiler to generate a source link file for us to consume?

Proposed Feature

Currently compiler will generate a documentation xml including APIs with comments. One proposal is to also include the source location for each API in it.
In our scenario, we need the source locations of all the public & protected APIs in this project. Not sure if it is ok to include them in the XML doc file, regardless of whether they actually have a comment or not. or maybe it can be achieved by a new explicit build flag?

Alternative Designs

If it cannot be produced in the docs xml file, can it be generated as a standalone file containing docCommentId and sourceLinks in it?

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged Issues and PRs which have not yet been triaged by a lead label Feb 4, 2024
@huangmin-ms huangmin-ms changed the title Produce symbol level source link information in docs xml Produce type/member level source link information in docs xml Feb 4, 2024
@huangmin-ms
Copy link
Author

@tmat any update for this feature request?

@arkalyanms arkalyanms removed the untriaged Issues and PRs which have not yet been triaged by a lead label Apr 19, 2024
@Falco20019
Copy link

I would love to see this end up in docfx :)

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

No branches or pull requests

4 participants