Support Sandcastle's behavior to recognize triple-slash on namespace
See original GitHub issueTriple-slash comments on the namespace itself is currently not supported. It would be great to add this, so that <summary>
and <remarks>
tags works, and would be presented on the API Documentation page, similar to old style MSDN pages like: http://msdn.microsoft.com/en-us/library/system.data.aspx.
Example:
/// <summary>Does not show up in .yml or .html output, but</summary>
/// <remarks>would be really nice if it did.</remarks>
namespace Boogie.On
{
}
Issue Analytics
- State:
- Created 7 years ago
- Comments:12 (6 by maintainers)
Top Results From Across the Web
Namespace documentation on a .Net project (Sandcastle)?
Simply create a non-public class called NamespaceDoc in the namespace you want to document, and the xml doc comment for that class will...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
In Sandcastle, namespace documentation was generated by creating an internal dummy class named NamespaceDoc and putting the documentation on it.
The
CompilerGeneratedAttribute
was used to ensure the class itself didn’t wind up in the documentation.This is another Sandcastle feature that DocFX should understand/use IMHO. External documentation files would work just as well, but the more the API reference documentation lives with the code, the better, IMHO. External documentation files should be for just that… documentation external to the API reference documentation.
@cesarsouza I was hoping that migrating
NamespaceDoc
to overwrite files or something similar would be dead simple.If it is not, I would rather see a (well documented) migration path that makes more sense. We should not built features into DocFX just to be compatible with SHFB.