The table below shows the namespaces that added APIs in 8.0 and need their documentation to be ported to dotnet-api-docs.
The dotnet-api-docs repo is our source of truth for documentation for two reasons:
- We ensure the docs go through language review there via a PR.
- We use that language-reviewed content to generate the official intellisense xmls that we then ship to customers.
In the table below, each namespace is assigned an issue containing a detailed list of the APIs that show up as undocumented in dotnet-api-docs, as well as the exact xml element that needs to be documented. Please look at your undoc APIs and follow the instructions below for documenting them.
Important: These issues are marked as blocking-release. All new APIs need to documented before the RC2 snap (September 17th).
Instructions
First, determine what's the documentation source of truth for your assembly:
A) Your assembly uses triple slash comments as the source of truth - You'll know this if your assembly's src csproj sets the <UseCompilerGeneratedDocXmlFile> property to true (example). For such assemblies, you only need to add the missing documentation in triple slash comments directly and send a PR in runtime. After merged, your documentation should show up in MS Docs in the next preview release automatically.
Note: After the RC1 snap (August 14th), you'll also have to backport your PR to the RC1 branch.
B) If the <UseIntellisensePackageDocXmlFile> property is unset or is set to true, then it means dotnet-api-docs is its source of truth. If that's your case, then follow the "porting to dotnet-api-docs" instructions below.
Porting to dotnet-api-docs
-
Clone the three involved repos locally if you haven't yet done so:
git clone https://github.com/dotnet/runtime
git clone https://github.com/dotnet/dotnet-api-docs
git clone https://github.com/dotnet/api-docs-sync
-
Run the api-docs-sync install-as-tool.ps1 script to get the docs porting tool installled as a global dotnet tool.
-
In the runtime clone, document the APIs, then build their assembly:
a) If it's a regular libraries assembly, build the src csproj:
cd runtime/src/libraries/System.Formats.Tar
dotnet build src/System.Formats.Tar.csproj
b) If the APIs are defined inside System.Private.CoreLib:
cd runtime
build.cmd clr.corelib -rc release
-
Port the xml docs from runtime into dotnet-api-docs running this command:
PortToDocs \
-Docs <pathToDocsXmlFolder> \
-IntelliSense <pathToArtifactsFolder1>[,<pathToArtifactsFolder2>,...,<pathToArtifactsFolderN>] \
-IncludedAssemblies <assembly1>[,<assembly2>,...<assemblyN>] \
-IncludedNamespaces <namespace1>[,<namespace2>,...,<namespaceN>] \
-SkipInterfaceImplementations [true|false] \
-Save true
- Example if it's a regular assembly:
PortToDocs \
-Docs "C:\path\to\dotnet-api-docs\xml" \
-IntelliSense "C:\path\to\runtime\artifacts\obj"\
-IncludedAssemblies "System.Formats.Tar"
-SkipInterfaceImplementations true \
-Save true
- If the APIs are defined under System.Private.CoreLib (for example, APIs from System.IO, System.Text, System.Globalization or System.Numerics):
PortToDocs \
-Docs "C:\path\to\dotnet-api-docs\xml" \
-IntelliSense "C:\path\to\runtime\artifacts\bin\coreclr" \
-IncludedAssemblies "System.Runtime,System.Private.CoreLib" \
-IncludedNamespaces "System.IO" \
-SkipInterfaceImplementations true \
-Save true
Notes
-
If your undocumented list contains APIs that are explicit interface implementations and use <inheritdoc/>, set the SkipInterfaceImplementations argument to false or remove it altogether. The tool will import all interfaces and will try to find and copy the parent interface's documentation for you.
-
Also notice that coreclr uses bin, while libraries uses obj.
- Submit a dotnet-api-docs PR and tag @gewarren and @carlossanlop for language review.
cc @jeffhandley @ericstj @karelz
The table below shows the namespaces that added APIs in 8.0 and need their documentation to be ported to dotnet-api-docs.
The dotnet-api-docs repo is our source of truth for documentation for two reasons:
In the table below, each namespace is assigned an issue containing a detailed list of the APIs that show up as undocumented in dotnet-api-docs, as well as the exact xml element that needs to be documented. Please look at your undoc APIs and follow the instructions below for documenting them.
Important: These issues are marked as
blocking-release. All new APIs need to documented before the RC2 snap (September 17th).Instructions
First, determine what's the documentation source of truth for your assembly:
A) Your assembly uses triple slash comments as the source of truth - You'll know this if your assembly's src csproj sets the
<UseCompilerGeneratedDocXmlFile>property totrue(example). For such assemblies, you only need to add the missing documentation in triple slash comments directly and send a PR in runtime. After merged, your documentation should show up in MS Docs in the next preview release automatically.Note: After the RC1 snap (August 14th), you'll also have to backport your PR to the RC1 branch.
B) If the
<UseIntellisensePackageDocXmlFile>property is unset or is set totrue, then it means dotnet-api-docs is its source of truth. If that's your case, then follow the "porting to dotnet-api-docs" instructions below.Porting to dotnet-api-docs
Clone the three involved repos locally if you haven't yet done so:
Run the api-docs-sync install-as-tool.ps1 script to get the docs porting tool installled as a global dotnet tool.
In the runtime clone, document the APIs, then build their assembly:
a) If it's a regular libraries assembly, build the src csproj:
b) If the APIs are defined inside System.Private.CoreLib:
Port the xml docs from runtime into dotnet-api-docs running this command:
Notes
If your undocumented list contains APIs that are explicit interface implementations and use
<inheritdoc/>, set theSkipInterfaceImplementationsargument tofalseor remove it altogether. The tool will import all interfaces and will try to find and copy the parent interface's documentation for you.Also notice that coreclr uses bin, while libraries uses obj.
cc @jeffhandley @ericstj @karelz