dotnet/sdk: the shared build engine behind the .NET CLI and Visual Studio

What dotnet/sdk actually contains, and who ends up touching it

The README states the repository holds "core functionality needed to create .NET projects that are shared between Visual Studio and the .NET CLI." That sentence is the whole scope. MSBuild tasks live under src/Tasks/Microsoft.NET.Build.Tasks/, and the common project and item templates live in template_feed. Everything Visual Studio-specific was moved out to dotnet/project-system, so if your bug reproduces only inside the IDE's project properties pages, this is the wrong repository.

The audience is narrower than the download numbers suggest. Most people who type "dotnet sdk install" want a compiler and a runtime, not this source tree. The people who genuinely need dotnet/sdk are maintainers of build tooling, template authors, and anyone debugging why a property such as an implicit using or a target framework resolution behaves differently between the CLI and the IDE. If you are writing application code, you will consume this repository's output, never its source.

How the CLI, MSBuild and the templates fit together

The architecture visible from the repository layout is a split of shared assets and per-surface shells. The MSBuild tasks in src/Tasks/Microsoft.NET.Build.Tasks/ are the piece both surfaces compile against, which is why a fix there lands in the CLI and in Visual Studio at the same time. The template_feed directory is a feed of project and item templates rather than a template engine; the TemplateEngine.slnf filter and TemplateEngine.code-workspace at the root show the engine is worked on in the same tree but as a separate solution filter.

The solution filters are the clearest map of the codebase. cli.slnf, sdk.slnx, tasks.slnf, containers.slnf and source-build.slnf each carve out one workstream, and the matching .code-workspace files exist so you can open just that slice. That is a deliberate response to scale: loading the whole tree in an IDE is slow, so contributors are expected to pick a filter. It also means a change that crosses filters, say a task plus the CLI command that surfaces it, requires you to reason about more than one workspace at a time.

Installing the .NET SDK and checking what you have

The README does not give an install command. It points at official builds on dotnet.microsoft.com/download/dotnet and at a latest builds table in the dotnet/dotnet repository, and it notes that the SDK is distributed as an installer (MSI, PKG) or an archive (zip, tar.gz). Sources for dotnet-install.sh and dotnet-install.ps1 are not here either; the README redirects to the install-scripts repository. So the honest instruction is: download from the official builds page, then verify with the CLI.

After installing, the first real check is which SDKs the machine can see. The README does not spell out the verification command, so the practical step is to confirm the installed version from the CLI and compare it with the release you downloaded. If the version you expect is missing, the install went to a different location than the one the host resolves.

To confirm the toolchain end to end, create a project from a template and build it. This exercises the template feed and the MSBuild tasks in one pass. The README points at template_feed for the common project and item templates, and the CLI consumes them through the template engine worked on in this same tree. A successful build prints a restore and build summary; if restore fails, the failure is usually feed configuration rather than the SDK itself.

Building the SDK itself, and the dogfood step people skip

For contributors, the entry point is documentation/project-docs/developer-guide.md, which the README names as the starting document. The repository root carries build.cmd and build.sh plus restore.cmd and restore.sh, so a full build is a script invocation rather than a sequence of dotnet commands, and global.json pins the SDK the build expects.

Testing a locally built SDK is the part with a documented, non-obvious ritual. The README says to run `eng\dogfood.cmd` after building. That script starts a new PowerShell with the environment configured to redirect SDK resolution to your build.

Inside that shell the built SDK is what `dotnet build` and `msbuild` use, and it is also what any Visual Studio instance launched via `& devenv.exe` picks up. The practical consequence is that a build outside that shell tells you nothing about your change. Contributors who run `dotnet build` in their normal terminal and see old behaviour have almost certainly not dogfooded.

The contribution flow adds two constraints. Pull requests are assigned a reviewer once a week on Wednesday, and only PRs that are green in the build are looked at. The README asks contributors to include a test where possible and to mention @dotnet-cli to raise visibility. Neither is optional in practice: a red PR waits a week for nothing.

Where this repository is the wrong tool

The clearest failure mode is treating dotnet/sdk as a distribution. It is not. There is no installer artifact here, no release binary you can hand to a colleague, and the README explicitly routes downloads to dotnet.microsoft.com and the install scripts to a separate repository. Cloning this tree to get a working SDK is a category error.

The second limitation is triage latency, and the README is unusually candid about it. Issues are labeled with Area- prefixes and routed through CODEOWNERS, with central SDK team issues assigned in the first half of each week. Milestones are described as "our best estimate for when a fix will be targeted", and the README says plainly that not all issues will get fixed. A milestone of Backlog means the team will consider it in the future if there is more feedback; Discussion means they need more information from you. If your timeline depends on a specific fix landing, the milestone is not a commitment, and the README does not pretend otherwise.

Third, the repository is a shared surface, so a change to a task under src/Tasks/Microsoft.NET.Build.Tasks/ can alter IDE behaviour for users who never touched the CLI. That coupling is the point of the design, but it raises the review bar for anything in that directory.

How this differs from dotnet/project-system and from the install-scripts repo

The most useful comparison is the one the README makes itself. dotnet/project-system holds "the project system work that is specific to Visual Studio". The split is by consumer: shared MSBuild tasks and templates here, IDE-only project system there. If you are chasing a bug in how Visual Studio loads or displays a project, the answer usually lives in project-system; if the same bug reproduces from `dotnet build`, it is likely in the tasks in this repository. That single test, reproduce outside the IDE, decides which repository gets your issue.

The second alternative is dotnet/install-scripts, which the README names as the home of dotnet-install.sh and dotnet-install.ps1. Those scripts are how CI pipelines install an SDK without an interactive installer. If your goal is a reproducible build agent rather than a developer laptop, that repository is the one you script against, and this one is irrelevant to you.

Licence, release cadence and the cost of tracking main

The project uses the MIT license, and the README adds a detail worth reading twice: the LICENSE.txt and ThirdPartyNotices.txt inside any downloaded archive are authoritative, not the copies in the repository. For anyone redistributing an SDK, that sentence decides which file you ship. This is a factual pointer, not legal advice; the archive notices govern.

Upgrade cost depends on which side of the fence you are on. Consumers of released SDKs get three maintained lines, with v8.0.425 (.NET 8.0.31), v9.0.318 (.NET 9.0.20) and v10.0.401 (.NET 10.0.12) all published on 2026-09-08. The repository itself was last pushed on 2026-09-23. For contributors, tracking main means keeping global.json, Directory.Packages.props and Directory.Build.props in sync with the build scripts, and re-running the dogfood step after every rebuild. For everyone else, the upgrade path is a download from the official builds page, and the repository is a place to read release notes and file issues.

Editorial conclusion

Adopt dotnet/sdk as a source dependency only if you are patching SDK behaviour, adding a template to template_feed, or building the SDK itself; application teams should install the released SDK and file issues against this repository instead of forking it. If you only need to compile and run .NET code, install a released build from dotnet.microsoft.com and never clone this tree. Before opening a pull request, run eng\dogfood.cmd after a successful build and confirm the version you built is the one resolving in the new shell, because that is the only way the README describes testing a locally built SDK.

Frequently asked questions

Official sources

1. dotnet/sdk on GitHub
2. License: MIT
3. Project website
4. README
5. Releases