The repo can be built for the following platforms, using the provided setup and the following instructions. Before attempting to clone or build, please check the requirements that match your machine, and ensure you install and prepare all as necessary.
| Chip | Windows | Linux | macOS | FreeBSD |
|---|---|---|---|---|
| x64 | ✔ | ✔ | ✔ | ✔ |
| x86 | ✔ | |||
| Arm32 | ✔ | |||
| Arm64 | ✔ | ✔ | ✔ | |
| Requirements | Requirements | Requirements | Requirements |
Additionally, keep in mind that cloning the full history of this repo takes roughly 400-500 MB of network transfer, inflating to a repository that can consume somewhere between 1 to 1.5 GB. A build of the repo can take somewhere between 10 and 20 GB of space for a single OS and Platform configuration depending on the portions of the product built. This might increase over time, so consider this to be a minimum bar for working with this codebase.
The runtime repo can be built from a regular, non-administrator command prompt, from the root of the repo.
The repository currently consists of three different major parts:
More info on this, as well as the different build configurations in the Configurations and Subsets section.
This was a concise introduction and now it’s time to show the specifics of building specific subsets in any given supported platform, since most likely you will want to customize your builds according to what component(s) you’re working on, as well as how you configured your build environment. We have links to instructions depending on your needs in this section.
You may need to build the tree in a combination of configurations. This section explains why.
A quick reminder of some concepts – see the glossary for more on these:
When we talk about mixing configurations, we’re discussing the following sub-components:
To build just one part of the repo, you add the -subset flag with the subset you wish to build to the root build script (build.cmd/sh). You can specify more than one by linking them with the + operator (e.g. -subset clr+libs would build CoreCLR and the libraries). Note that if the subset is the first argument you pass to the script, you can omit the --subset flag altogether.
At this point you probably know what you are planning to work on primarily: the runtimes or libraries. As general suggestions on how to proceed, here are some ideas:
Now you know about configurations and how we use them, so now you will want to read how to build what you plan to work on. Each of these will have further specific instructions or links for whichever platform you are developing on.
After that, here’s information about how to run tests:
And how to measure performance:
The repo build treats warnings as errors. Dealing with warnings when you’re in the middle of making changes can be annoying (e.g. unused variable that you plan to use later). To disable treating warnings as errors, set the TreatWarningsAsErrors environment variable to false before building. This variable will be respected by both the build.sh/build.cmd root build scripts and builds done with dotnet build or Visual Studio. Some people may prefer setting this environment variable globally in their machine settings.
Before submitting a PR, make sure to review the contribution guidelines. After you get familiarized with them, please read the PR guide to find more information about tips and conventions around creating a PR, getting it reviewed, and understanding the CI results.
Given the size of the runtime repository, flaky tests are expected to some degree. There are a few mechanisms we use to help with the discoverability of widely impacting issues. We also have a regular procedure that ensures issues get properly tracked and prioritized. You can find more information on triaging failures in CI.