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

[Bug] Metadata extracted from DLL does not include triple slash comments #10231

Open
MarkStega opened this issue Sep 24, 2024 · 4 comments
Open
Labels
bug A bug to fix

Comments

@MarkStega
Copy link

Describe the bug
When I create a doc site using DocFx I get different results if I reference a DLL versus a CSPROJ. Using the DLL as a metadata source looses the '///' comments

To Reproduce
Steps to reproduce the behavior:

  1. Clone the repository at BlazorBounce
  2. From the root run ServeDocs
  3. Observe the output, there are no /// comments
  4. Change the source spec to be the csproj
  5. Run ServeDocs again
  6. Observe /// comments

Expected behavior
I expect the output to be the same or that documentation be added that states that /// comments aren't available when metadata is extracted from a DLL

Context (please complete the following information):

  • OS: Windows 11
  • Docfx version: 2.77.0

Additional context
Add any other context about the problem here.

@MarkStega MarkStega added the bug A bug to fix label Sep 24, 2024
@MarkStega MarkStega changed the title [Bug] Metadate extracted from DLL does not include triple slash comments [Bug] Metadata extracted from DLL does not include triple slash comments Sep 24, 2024
@filzrev
Copy link
Contributor

filzrev commented Sep 24, 2024

When generating API metadata from DLLs.
It requires documentation XML files to extract comments.

What would happen if the following lines were added to .csproj.

<PropertyGroup>
  <GenerateDocumentationFile>true</GenerateDocumentationFile>
</PropertyGroup>

@MarkStega
Copy link
Author

@filzrev

That works, however:

  1. Why does specifying the csproj as input work without having that entry?

  2. This 'hint' needs to be added to the DocFx documentation

Thanks for the help...

MarkStega added a commit to Material-Blazor/Material.Blazor that referenced this issue Sep 25, 2024
MarkStega added a commit to Material-Blazor/Material.Blazor that referenced this issue Sep 25, 2024
* Check if WASM build is broken on GHA

* Update ServeDocs.cmd

* npm updates

* Update documentation build

* Remove gitignore of root docfx files

* Account for artifacts directory

* Add to M.B.csproj per dotnet/docfx#10231 (comment)

* npmupdate, DocFx addition to M.B.csproj

* Release notes

* Additional WiP debug

* wip #2
@filzrev
Copy link
Contributor

filzrev commented Sep 28, 2024

Why does specifying the csproj as input work without having that entry?

When generating docs from csproj.
docfx run code analysis to C# source code. (It's executed on memory. and DLL is no generated)
So separated documentation xml files are not needed.

On the contrary, when generating docs from DLL files.
docfx manually loading documentation xml files.
https://github.com/dotnet/docfx/blob/4d5949af96797a34d418f3fcb6b31f63392df5de/src/Docfx.Dotnet/CompilationHelper.cs#L201C2-L201C21

@MarkStega
Copy link
Author

@filzrev

Thanks very much for explaining the difference in the two methods.

I think all that is needed now is a minor documentation update.

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

No branches or pull requests

2 participants