dotnet/AspNetCore.Docs: the repository behind the official ASP.NET Core documentation

What dotnet/AspNetCore.Docs actually is, and who it is written for

This repository contains the official ASP.NET Core documentation, served at learn.microsoft.com/aspnet/core. The README states that plainly, and the top-level layout backs it up: an aspnetcore/ directory holds the content, .openpublishing.publish.config.json and .openpublishing.redirection.json drive the publishing pipeline, and .markdownlint.json plus cspell.json enforce formatting and spelling rules on the prose itself.

The audience is narrower than the repository's visibility suggests. It is not aimed at someone who wants to build a web API. It is aimed at the person who found a wrong code sample, the person adding a section for a feature that shipped without docs, and the writer who has to keep hundreds of articles consistent with a moving framework. If you are evaluating ASP.NET Core as a technology, this is the wrong artifact to read first; the articles it produces are the artifact, and they live on the documentation site.

One structural detail matters early. The README points out that the dotnet/AspNetDocs repository contains the ASP.NET 4.x documentation. Two repositories, two product generations. A correction filed in the wrong one will be redirected or closed, which is a predictable waste of a contributor's afternoon.

How the publishing pipeline turns Markdown into learn.microsoft.com pages

The mechanism visible from the repository root is a docs-as-code pipeline. Content lives under aspnetcore/ as Markdown. Configuration files at the root control how that content is validated and published: .openpublishing.publish.config.json describes the publishing setup, .openpublishing.redirection.json maps old URLs to new ones so that renamed articles do not break inbound links, .markdownlint.json defines the allowed Markdown style, and cspell.json carries the project's accepted vocabulary.

The redirection file is the part contributors underestimate. Documentation URLs are public API. When an article is renamed or split, the old path has to keep resolving, and that is handled by a checked-in mapping rather than by anything at runtime. A pull request that renames a file without touching the redirection configuration creates a broken link that only shows up for readers arriving from search results or from older articles.

There is also a .whatsnew.json at the root, which the repository uses to track what changed in the documentation. Combined with .repoman.yml and quest-config.json, the root reads as a set of automated checks layered on top of ordinary Markdown. The practical consequence for a contributor is that a documentation change is a build artifact, not a blog post: lint rules, spelling rules and link rules all run before anything reaches the site.

No install step: how to work with the docs repository and make a first real edit

There is no package to install for this repository, because it is not a library. The README does not document a local build command, and the repository's own guidance for small changes points at the quick-edit path on the documentation site rather than at a local toolchain. What you can do locally is clone the content and read it.

Start by getting the repository onto disk. The default branch is main.

git clone https://github.com/dotnet/AspNetCore.Docs.git
cd AspNetCore.Docs

After cloning you should see the root entries the repository publishes: aspnetcore/, CONTRIBUTING.md, LICENSE, LICENSE-CODE and the publishing configuration files. The documentation articles themselves are the Markdown files under aspnetcore/.

For a simple typo or a similar correction, the README says you can submit a pull request directly and points at the contributor guide for quick edits to existing documents. For anything larger, the README is explicit about the entry point: do not open a blank issue. Use the Open a documentation issue link and feedback form at the bottom of the article you are reading on the documentation site.

Because that form attaches article metadata for tracking, indicates which article you are commenting on, and automatically pings the author, the README says it leads to a faster response. A blank issue carries none of that context. If your problem is not a documentation defect at all, the README routes general support questions to Stack Overflow, the ASP.NET Core Slack or the ASP.NET Gitter, and site design concerns to the MicrosoftDocs/Feedback repository.

Where this repository will not help you

The clearest failure mode is category confusion. Someone searching for how to install ASP.NET Core can land on this repository, see the product name, and clone it expecting a framework. Nothing here installs a runtime, a template pack or a CLI. The README describes a documentation repository and links to the documentation site; it does not describe a distribution channel.

The second limitation is scope. The README separates ASP.NET Core from ASP.NET 4.x across two repositories, and it separates documentation defects from support questions and from site design problems. A question about why a tutorial does not compile is explicitly routed by the README to a comparison against the completed sample, not to the issue tracker. If your problem is that your own code is broken, this is the wrong queue, and filing there delays you.

Third, the release history is not a useful signal about the documentation. The recent releases listed for the repository are from October 2020 and are titled around creating a gRPC client and server in ASP.NET Core 3.1. That tells you the release feed reflects sample or article milestones, not documentation currency. Judging whether an article is up to date from the release list would be a mistake. The last push to the repository was on 2026-09-21.

dotnet/AspNetDocs and the other place your change might belong

The real alternative is not a competing documentation project. It is the sibling repository the README names directly: dotnet/AspNetDocs, which contains the ASP.NET 4.x documentation. The difference in approach is generational, not stylistic. ASP.NET Core and ASP.NET 4.x are separate product lines with separate documentation sets and separate repositories, so the same conceptual article can exist twice with different code and different APIs.

That split has a practical cost. A contributor who learned the framework on 4.x and now works on Core has to remember which repository owns which article, and the README gives no mapping between them beyond the statement that the 4.x docs live in the other repository. If you are unsure which product your issue concerns, the article's own feedback form resolves it, because the form is attached to a specific published page and therefore to a specific product line.

For general questions the README also names external venues rather than a repository: Stack Overflow under the asp.net-core tag, the ASP.NET Core Slack, and the ASP.NET Gitter. Those are not alternatives to the documentation repository so much as a different kind of destination, and the README treats them as the correct place for support rather than for documentation changes.

Licence, maintenance and the cost of keeping up

The repository is licensed CC-BY-4.0, and the file list shows a separate LICENSE-CODE alongside LICENSE. That split is worth noticing: prose and code samples in a documentation repository are frequently governed by different terms, and the presence of two licence files indicates the project distinguishes them. Read both before reusing a sample in your own product; this is a description of what the repository contains, not legal advice.

The repository is not archived, and its last push was on 2026-09-21, so it is being changed. For a consumer of the documentation, that is mostly good news and partly a maintenance consideration: articles you link to can move, which is exactly why .openpublishing.redirection.json exists. If you cite documentation URLs in your own material, the redirection layer is what keeps those citations alive after a rename.

For a contributor, the upgrade cost is the tooling around the content rather than the content itself. Markdown lint rules, the spell-check dictionary and the publishing configuration all change over time, and a pull request that ignores them will fail checks rather than merge. The cheapest way to stay current is to read CONTRIBUTING.md before your first pull request and to keep changes small, since the README's own guidance for typos is to submit the fix directly rather than open an issue about it.

Editorial conclusion

Adopt dotnet/AspNetCore.Docs if you are correcting an article, adding a sample, or need the docs source of truth for a version you support; do not clone it expecting to install or run ASP.NET Core, because the framework ships elsewhere. Before opening anything, verify which article is wrong, check whether the same fix already exists in an open issue, and confirm whether your change belongs in this repository or in dotnet/AspNetDocs for ASP.NET 4.x. Start from the article's own Open a documentation issue link rather than a blank issue, because that form attaches the article metadata the maintainers track.

Frequently asked questions

Official sources

1. dotnet/AspNetCore.Docs on GitHub
2. License: CC-BY-4.0
3. Project website
4. README
5. Releases