# dotnet-api-docs: the source text behind the .NET API reference > The dotnet/dotnet-api-docs repository holds the text and code snippets that the published .NET API reference for .NET 8 and later is built from. It is a content pipeline rather than a library, and a large part of it is deliberately not editable from the published site. **dotnet/dotnet-api-docs** — .NET API reference documentation (.NET 8+) - Repository: https://github.com/dotnet/dotnet-api-docs - Website: https://learn.microsoft.com/dotnet/api/ - Stars: 955 · Forks: 1,704 - Language: C# - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/dotnet-dotnet-api-docs ## A content repository, not a library The opening line of the README defines the scope: this repository contains documentation for the .NET API reference for .NET 8 and later and for package-provided APIs. That distinction matters because the .NET API reference people read at learn.microsoft.com/dotnet/api is not a thing you can clone and run. It is a published artifact, assembled from prose and code that live in source control here, and from samples that live in another repository. The README says the documentation for APIs is built from the text and code snippets in this repo and from the samples in the dotnet/samples repository. So the audience for this repository is narrower than the audience for the documentation itself. The readers of the docs are every .NET developer. The people who work in this repository are the ones fixing a description, adding an example, or registering a newly shipped package so its API appears in the reference at all. The workflow is issue-driven, and the README says so explicitly: all work for this repository is tracked using GitHub issues. That is unusual for a documentation repository of this size, and it changes how a contribution starts. You claim an issue rather than opening a pull request against whatever file you happen to find. The primary language of the repository being C# is a consequence of what it documents rather than of what it contains. ## Why some types have no Edit button on the published page This is the most confusing thing about working in this repository, and the README addresses it directly. For some assemblies, the API reference documentation is maintained in the assembly's own source code repository rather than here. For those assemblies, edits to the XML in this repository are auto-generated and ported, so documentation for those APIs should be updated by editing the source code comments instead. The mechanism that makes this visible to readers is a metadata flag. Namespaces and types whose documentation is maintained in the assembly's source repository set open_to_public_contributors to false in docfx.json. The README explains what that does: the metadata disables the Edit button on the published docs. So when you open a type on learn.microsoft.com and there is no Edit button, that is not a broken page. It is the system telling you that the text belongs to the runtime repository and that any change has to be made where the code lives. For a contributor, this is a routing decision. Before you start editing a type, you need to know which of the two paths applies, and the answer is per namespace and per type, not per file. Getting that wrong produces an edit that is either overwritten by the next port or rejected in review. ## The XML files are the unit of work The repository layout is the DocFX pipeline laid out as folders. The xml directory is where the API reference material lives, which follows from the README's statement that edits to the XML in this repository are auto-generated and ported. The snippets directory holds code fragments that the pages embed, and the includes directory holds reusable text pulled into multiple pages. The add directory is for adding new API surfaces, and breadcrumb holds the navigation data that decides how a type appears in the tree of the reference. Configuration lives in a small set of files at the root. docfx.json is the DocFX configuration, and it is where the open_to_public_contributors metadata is set. quest-config.json and .repoman.yml are the repository automation configuration, and .openpublishing.publish.config.json is the publishing configuration, which is what drives the pipeline that turns this content into the pages on learn.microsoft.com. The _zip directory and the ThirdPartyNotices directory handle packaged artefacts and third-party attributions. There is also a CODE_OF_CONDUCT.md and a CONTRIBUTING.md at the root, and the README points at the .NET Contributor Guide on learn.microsoft.com for the procedures the project uses, plus issues labelled help wanted as the source of ideas to work on. The code of conduct is the .NET Foundation's, defined by the Contributor Covenant. ## Three repositories, three different jobs The README names the neighbouring repositories, and the split explains where your change belongs. This repository, dotnet/dotnet-api-docs, holds the API reference for.NET 8 and later plus package-provided APIs. The.NET Framework API reference is in a separate repository, dotnet/dotnetfw-api-docs, kept separate from the.NET 8 and later reference. Conceptual documentation, the kind that explains how to do something rather than what a member does, is in dotnet/docs. And the samples used to build the API pages come from dotnet/samples. For anyone writing documentation for a.NET library, this produces a decision tree. A reference page for a package you own can go in this repository, provided the package's API is registered as package-provided. A conceptual article goes to dotnet/docs. An API that belongs to the runtime goes to the runtime source repository, because this repository's copy is generated. A code example that will appear on a reference page goes to dotnet/samples. The.NET 8+ cut is worth noting as a boundary rather than a preference. A repository that documents the current runtime generation is a different maintenance commitment from one that spans several versions of a framework, and the split in the repository layout follows the product lifecycle. ## A custom licence and a documentation-only contribution The licence on this repository is not one GitHub's classifier could place. The project is distributed under a custom licence, and the LICENSE file at the repository root is the authoritative text, with a separate LICENSE-CODE file alongside it. The split into two files, and the presence of a ThirdPartyNotices directory, tell you that the content in this repository is not covered by a single standard open source licence the way most code repositories are. This is normal for a documentation corpus and worth understanding before you plan to reuse it. Text copied from the .NET API reference into your own internal documentation, for example, is a licensing question rather than a technical one, and the answer lives in those files. I am not a lawyer and this is not legal advice; the point is only that the LICENSE file is where the answer is, and it is not the MIT or Apache text you might assume. The contribution model is the second thing to plan around. Rather than opening a pull request straight away, the README asks that you work from an issue, and points to issues labelled help wanted as the place to find ideas. The .NET Contributor Guide covers the procedures. The stated purpose of the repository is to help improve and complete the API reference docs, which is an invitation aimed at filling gaps, not at rewriting the reference wholesale. ## Conclusion Adopt this repository when you maintain a .NET library and want the API reference for your own package to be published alongside the framework reference, or when you want to fix documentation text for the framework itself. Do not adopt it as a source of API truth for offline reading, since the published output lives at learn.microsoft.com/dotnet/api and is assembled by a publishing pipeline this repository only feeds. Verify first that the namespaces you intend to edit are not among the ones whose docs are maintained in the runtime source, because the README states that edits to those XML files here are auto-generated and ported and that changes must be made in the source code comments, and check the open_to_public_contributors setting in docfx.json before you plan a documentation contribution for a specific type. ## FAQ ### Where is the source of the .NET API reference documentation? The dotnet/dotnet-api-docs repository contains the documentation for the .NET API reference for .NET 8 and later and for package-provided APIs. The published pages are built from the text and code snippets in that repo and from the samples in dotnet/samples. ### Why does some .NET API documentation have no Edit button? For some assemblies the docs are maintained in the assembly's source code repository, and the XML in dotnet-api-docs is auto-generated and ported. Those namespaces and types set open_to_public_contributors to false in docfx.json, which disables the Edit button on the published docs. ### Where do .NET Framework API docs and conceptual docs live? The .NET Framework API reference is in the dotnet/dotnetfw-api-docs repository, and conceptual .NET documentation is in the dotnet/docs repository. dotnet-api-docs covers the API reference for .NET 8 and later. ### How do I contribute to dotnet-api-docs? The README says all work is tracked using GitHub issues, points to issues labelled help wanted as sources of ideas, and asks contributors to follow the .NET Contributor Guide for the procedures the project uses. ### What licence applies to the dotnet API docs repository? It is a custom licence that GitHub's classifier could not categorise, with the LICENSE file at the repository root as the authoritative text and a separate LICENSE-CODE file beside it. ## Sources - [dotnet/dotnet-api-docs on GitHub](https://github.com/dotnet/dotnet-api-docs) - [Issues](https://github.com/dotnet/dotnet-api-docs/issues) - [Project website](https://learn.microsoft.com/dotnet/api/) - [README](https://github.com/dotnet/dotnet-api-docs/blob/main/README.md) - [Releases](https://github.com/dotnet/dotnet-api-docs/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dotnet-dotnet-api-docs