|Number of watchers on Github||9043|
|Number of open issues||1587|
|Average time to close an issue||1 day|
|Average time to merge a PR||about 19 hours|
|Open pull requests||645+|
|Closed pull requests||134+|
|Last commit||2 months ago|
|Repo Created||over 3 years ago|
|Repo Last Updated||2 months ago|
|Organization / Author||dotnet|
|Do you use coreclr? Leave a review!|
|View open issues (1587)|
|View coreclr activity|
|View on github|
|Latest Open Source Launches|
Trendy new open source projects in your inbox! View examples
.NET Core is best thought of as 'agile .NET'. Generally speaking it is the same as the Desktop .NET Framework distributed as part of the Windows operating system, but it is a cross platform (Windows, Linux, macOS) and cross architecture (x86, x64, ARM) subset that can be deployed as part of the application (if desired), and thus can be updated quickly to fix bugs or add features.
Most users don't need to build .NET Core from source since there is already a built and tested version for any supported platform. You can get the latest released version of the .NET Core SDK by following the instructions on the .NET Core Getting Started page. If you need the most up to date (daily) version of this .NET Core installer you can get it from the latest Installers of .NET Core and .NET Core SDK. If you want one of our official releases, you can get the download from the download archive page.
In addition to providing the source code, this repository also acts as a useful nexus for things related to .NET Core including:
.NET Core relies heavily on the NuGet package manager,
which is a system to package, distribute and version software components. See https://www.nuget.org/
for more information on NuGet. For now it is enough to know NuGet is a system that
bundles components into
*.nupkg files (which are ZIP archives) and these packages can be 'published'
either through a local file system path or by a URL (e.g. https://www.nuget.org/). There are then tools
(e.g. nuget.exe, Visual Studio, dotnet.exe) that based on a configuration file (.csproj) know
how to search these publishing locations and pull down consistent set of packages for the
In concrete terms, this repository is best thought of as the source code for the following NuGet package:
It also contains the source code for the following closely related support packages.
By itself, the
Microsoft.NETCore.Runtime.CoreCLR package is actually not enough to do much.
One reason for this is that the CoreCLR package tries to minimize the amount of the class library that it implements.
Only types that have a strong dependency on the internal workings of the runtime are included (e.g,
System.Threading.Tasks.Task and most foundational interfaces).
Instead most of the class library is implemented as independent NuGet packages that simply use the .NET Core
runtime as a dependency. Many of the most familiar classes (
so on), live in packages defined in the dotnet/corefx repository.
But the main reason you can't do much with CoreCLR is that ALL of the types in the class library LOOK
like they are defined by the CoreFX framework and not CoreCLR. Any library code defined here
lives in a single DLL called
System.Private.CoreLib.dll and as its name suggests is private (hidden).
Instead for any particular PUBLIC type defined in CoreCLR, we found the 'right' package in CoreFX where it naturally
belongs and use that package as its public publishing point. That 'facade' package then forwards references
to the (private) implementation in
System.Private.CoreLib.dll defined here.
For example the
System.Runtime package defined in CoreFX declares the PUBLIC name for types like
System.String. Thus from an applications point of view these types live in
System.Runtime.dll (defined in the CoreFX repo) forwards references ultimately to
which is defined here.
Thus in order to run an application, you need BOTH the
Microsoft.NETCore.Runtime.CoreCLR NuGet package
(defined in this repository) as well as packages for whatever you actually reference that were defined
in the CoreFX repository (which at a minimum includes the
System.Runtime package). You also need some
sort of 'host' executable that loads the CoreCLR package as well as the CoreFX packages and starts your code (typically
dotnet.exe for this).
These extra pieces are not defined here, however you don't need to build them in order to use the CoreCLR NuGet package you create here. There are already versions of the CoreFX packages published on https://www.nuget.org/ so you can have your test application's project file specify the CoreCLR you built and it will naturally pull anything else it needs from the official location https://www.nuget.org/ to make a complete application. More on this in the Using Your Build page.
The first step in making a build of the CoreCLR Repository is to clone it locally. If you already know how to do this, just skip this section. Otherwise if you are developing on Windows you can see Setting Up A Git Repository In Visual Studio 2017 for instructions on setting up. This link uses a different repository as an example, but the issues (do you fork or not) and the procedure are equally applicable to this repository.
The build depends on Git, CMake, Python and of course a C++ compiler. Once these prerequisites are installed
the build is simply a matter of invoking the 'build' script (
build.sh) at the base of the
The details of installing the components differ depending on the operating system. See the following
pages based on your OS. There is no cross-building across OS (only for ARM, which is built on X64).
You have to be on the particular platform to build that platform.
The build has two main 'buildTypes'
In addition, by default the build will not only create the runtime executables, but it will also build all the tests. There are quite a few tests so this does take a significant amount of time that is not necessary if you want to experiment with changes. You can skip building the tests by passing the 'skiptests' argument to the build script.
Thus to get a build as quickly as possible type the following (using
\ as the directory separator, use
/ on Unix machines)
which will build the Debug flavor which has development time checks (asserts), or
.\build release skiptests
to build the release (full speed) flavor. You can find more build options with build by using the -? or -help qualifier.
The build places all of its generated files under the
bin directory at the base of the repository. There
bin\Log directory that contains log files generated during the build (most useful when the build fails).
The the actual output is placed in a directory like this
Where you can see the operating system and CPU architecture, and the build type are part of the name. While the 'raw' output of the build is sometimes useful, normally you are only interested in the NuGet packages that were built, which are placed in the directory
These packages are the 'output' of your build.
There are two basic techniques for using your new runtime.
Use dotnet.exe and NuGet to compose an application. See Using Your Build for instructions on creating a program that uses your new runtime by using the NuGet packages you just created and the 'dotnet' command line interface. This is the expected way non-runtime developers are likely to consume your new runtime.
Use corerun.exe to run an application using unpackaged Dlls. This repository also defines a simple host called corerun.exe that does NOT take any dependency on NuGet. Basically it has to be told where to get all the necessary DLLs you actually use, and you have to gather them together 'by hand'. This is the technique that all the tests in the repo use, and is useful for quick local 'edit-compile-debug' loop (e.g. preliminary unit testsing). See Using corerun To Run .NET Core Application for details on using this technique.
Typically users run through the build and use instructions first with an unmodified build, just to familiarize themselves with the procedures and to confirm that the instructions work. After that you will want to actually make modifications and debug any issues those modifications might cause. See the following links for more.
After you have your modification basically working, and want to determine if you have broken anything it is time to run tests. See Running .NET Core Tests for more.
Looking for something to work on? The list of up-for-grabs issues is a great place to start.
Please read the following documents to get started.
As noted above, the CoreCLR Repository does not contain all the source code that makes up the .NET Core distribution. Here is a list of the other repositories that complete the picture.
.NET Core (including the coreclr repo) is licensed under the MIT license.
The January Update includes .NET Core 1.1.6 and the .NET Core SDK 1.1.7
The January Update includes .NET Core 1.0.9 and the .NET Core SDK 1.1.7