dotnet/arcade is the shared build layer under .NET Foundation repos

Build infrastructure shared across the .NET Core team

Arcade is described in the repository as tools that provide common build infrastructure for multiple .NET Foundation projects, and the README states the intent more precisely: Arcade is intended to provide well understood and consistent mechanisms for consuming, updating and sharing infrastructure across the .NET Core team.

Three verbs carry that sentence. Consuming means pulling in shared build logic from somewhere other than the repository itself. Updating means there is a mechanism for keeping that shared logic current across the repositories that use it. Sharing means the same definitions serve many projects at once.

This tells you the audience. The consumer of Arcade is not an application developer who wants a faster build, it is the maintainer of a repository inside the .NET Foundation set, who needs their restore, versioning and CI behaviour to line up with the rest of the ecosystem. The README is short for that reason, and it points at `Documentation/Overview.md` for details and at a documentation index in `Documentation/README.md` for tutorials and guides.

Two Maestro channels track what is current and what is being validated

The README's validation table is the most revealing part of the documentation, because it exposes the release flow. There are two rows. The first is the current version of Arcade in `.NET Eng - Latest`, pointing at channel 2 on maestro.dot.net. The second is the latest version of Arcade being validated, pointing at channel 9 on the same service.

So at any moment there are two Arcade versions in flight. One is what teams consume, the other is what is being put through validation before it becomes the current one. The split exists so that a change to shared infrastructure can be exercised in a validation channel before it lands on the channel the whole .NET Core team depends on.

Note what this table is not. It does not publish a version number, a changelog or a tag, and the repository lists no GitHub releases. A consumer therefore tracks Arcade by channel rather than by release, which is a workflow that assumes you are inside the ecosystem's own release coordination rather than pulling a pinned package from a public feed.

Packages are published daily to the dnceng tools feed

The distribution route is an Azure DevOps NuGet feed that the README says packages are published to daily:

Packages are published daily to our tools feed: https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json

The same feed is browsable from a package management page in the Azure DevOps organisation. The feed name, `dotnet-eng`, and the `dnceng` organisation are visible in the URL itself.

Daily publishing is a meaningful detail for a shared tooling layer. It means the feed is a rolling channel rather than a set of versioned releases, so a build that restores from it can pick up new build logic without anyone bumping a version in their repository. That is also the risk. If your build consumes the feed without pinning, the infrastructure under your build can change between two runs of the same commit, which is a difficult class of problem to diagnose when it happens.

The repository also ships a `NuGet.config`, which is where feed resolution for such a repository is normally configured, and a `Directory.Packages.props` for central package versions.

The repository is mostly build plumbing

Look at the top level entries and the shape of the project becomes clear. There is `Arcade.slnx` as the solution file, `Directory.Build.props` and `Directory.Build.targets` for the properties and targets that every project in the tree inherits, `Directory.Packages.props` for central package versions, and `global.json` for SDK pinning. On top of that sit `NuGet.config`, `eng/`, `src/`, `scripts/` and `tests/`.

The `eng/` directory is where engineering infrastructure usually lives in this kind of repository, and the presence of `Directory.Build.props` at the root is the mechanism by which one definition reaches every project below it. That is the consistency the README promises, expressed as files.

The pipeline definitions sit alongside them as Azure Pipelines YAML files with descriptive names: `azure-pipelines.yml`, `azure-pipelines-pr.yml`, `azure-pipelines-daily.yaml`, `azure-pipelines-codeql.yml`, `azure-pipelines-signing-validation.yml`, `azure-pipelines-renovate.yml` and `azure-pipelines-unofficial.yml`. Read as a set, they describe the CI obligations of a shared .NET infrastructure repository: pull request validation, a daily run, code scanning, signing validation, dependency update automation and a path for unofficial builds.

Two CI pipelines, one of them internal

The build status table lists two. Arcade Public CI points at a pipeline in the `dnceng-public` organisation, and Arcade Official Build points at a pipeline in the `internal` organisation of the same Azure DevOps instance.

That distinction is the one to keep in mind when evaluating the project from outside. The public pipeline is where outside contributors can see whether a change compiles and passes. The official build, including the signing validation pipeline and the internal Maestro channels, is part of the .NET engineering infrastructure and is not something an outside team can reproduce or inspect in detail.

For a maintainer inside the .NET Foundation set, that split is exactly right, because the official build has the credentials and signing keys that the public one must not have. For everyone else it means the CI story is partly invisible, and that the two build status links in the README are the only public view of it.

The scripts in the repository follow the same pattern of paired entry points. Windows developers have `Build.cmd`, `Restore.cmd` and `Test.cmd`, while Unix shells have `build.sh`, `restore.sh` and `test.sh`, with the same three verbs in each set.

Policy, security and notice files live in the repository too

Beyond the build system, the top level carries the files an open source project is expected to have: `CONTRIBUTING.md`, `CODE-OF-CONDUCT.md`, `SECURITY.md` and `THIRD-PARTY-NOTICES.TXT`, plus `LICENSE.TXT`, which the README ties to the .NET Foundation licensing position by stating that .NET, including the Arcade repository, is licensed under the MIT licence.

There are also two entries that say something about how this repository is worked on. `AGENTS.md` at the root suggests that instructions for coding agents are kept alongside the code, which is increasingly common for .NET repositories. `.git-blame-ignore-revs` exists to keep bulk formatting changes out of blame history, a sign that the repository is reformatted often enough for that to matter. `.editorconfig` and `.config/` point to enforced formatting and tool configuration.

For a shared infrastructure repository the licence choice is the low risk part. MIT with a file of third-party notices is a conventional arrangement for tooling that other repositories import, and nothing in the README suggests any restriction on consumption. The heavier obligation is operational: shared infrastructure means shared failure, so a change to Arcade affects every project that consumes it, which is why the validation channel and the signing validation pipeline exist at all.

When to reach for Arcade, and when not to

The alternative approach is the plain one. A repository outside the .NET Foundation family can use ordinary MSBuild project files, restore from the public NuGet feed, and run its own CI, with full control over versions and no shared channel in the middle. The difference in approach is exactly the thing Arcade adds and the plain route lacks: Arcade centralises the definition of how a .NET repository restores, builds, versions and signs, and then propagates updates across a family of repositories through channels and daily package publishing. The cost of that centralisation is that you inherit decisions made elsewhere, including a validation window you do not control.

For an application team with one repository, a handful of projects and no shared release obligations, that trade is a poor one. You would take on a dependency on a daily published tools feed and on channel semantics for build logic you could simply define in your own `Directory.Build.props`.

For a maintainer of a .NET Foundation repository, the calculation reverses. Staying inside Arcade means your build behaves the way the rest of the team expects, and that consistency is the product. The limits are worth stating plainly: the repository publishes no tagged releases, its documentation lives in the `Documentation/` tree rather than in the README, and the parts of its process that matter most, the official build and the validation channels, sit behind internal Azure DevOps projects.

Editorial conclusion

Adopt Arcade when you maintain a repository that is part of the .NET Foundation family and want the same restore, build, versioning and signing behaviour as the rest of the .NET Core team, and when you can add the dnceng feed to your NuGet configuration. Do not adopt it as a general build wrapper for an unrelated application, and do not plan around tagged releases, since the repository lists none. Verify first that `NuGet.config` in your checkout resolves the dnceng tools feed, that `global.json` pins the SDK your build expects, that the `Directory.Build.props` and `Directory.Packages.props` files do not conflict with your own central package management, and that the copy you take is current, since the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. dotnet/arcade on GitHub
2. Issues
3. License: MIT
4. README