This repo contains the .NET Core runtime, called CoreCLR, and the base library, called System.Private.Corelib (or mscorlib). It includes the garbage collector, JIT compiler, base .NET data types and many low-level classes. We welcome contributions.
C# C++ C Smalltalk Assembly Roff Other
stephentoub Improve throughput of {U}Int32/64.{Try}Parse for hex (#18952)
* Improve throughput of {U}Int32/64.{Try}Parse for hex

- Copies/modifies the recently added TryParse32/64IntegerStyle routines for hex in order to provide more optimized parsing.
- Since AllowHexSpecifier can't be used with any other styles (other than allowing leading/trailing whitespace), deletes existing code paths for parsing hex.
- As I was copying code around, I kept getting bitten by different names used for the same thing, so I also standardized some parameter names in various helper functions.

* Clean up

- Remove a bunch of unnecessary 'unsafe' keywords
- Rephrase some while(true) loops as do/while loops for consistency and to avoid some repetition
- Remove an unnecessary wrapper function
Latest commit 624f72d Jul 17, 2018
Failed to load latest commit information.
Documentation Fixing markdown list formatting (#18936) Jul 16, 2018
buildpipeline Update ARM32 Cross Build Docker Image (#17819) Apr 28, 2018
cross Update Tizen CI docker image (#18567) Jun 28, 2018
src Improve throughput of {U}Int32/64.{Try}Parse for hex (#18952) Jul 17, 2018
tests Adding tests for the Avx2 AlignRight, Blend, and ConvertTo* hwintrins… Jul 16, 2018
.editorconfig Change csharp_indent_labels from flush_left to one_less_than_current (#… Mar 16, 2018
.gitattributes Add Word2Vec Benchmark Harness (#17350) Apr 5, 2018
.gitignore New chunk should be equal/larger than the one it replaces (#17219) Mar 27, 2018
.gitmirrorselective Rename gitmirrorfile Nov 11, 2016
BuildToolsVersion.txt Update BuildTools, CoreClr, CoreFx, PgoData to preview1-03013-03, pre… Jul 17, 2018
CMakeLists.txt Add prefix to DAC's PAL exports for alpine (#18873) Jul 13, 2018
CODE_OWNERS.TXT Update CODE_OWNERS.TXT (#17114) Mar 22, 2018 Create (#6386) Jul 22, 2016
Directory.Build.props [Infrastructure] Use MSBuild v15 extension point to control CL parall… Nov 4, 2017
DotnetCLIVersion.txt Update to latest released dotnet SDK (#18626) Jun 24, 2018
ILAsmVersion.txt Update BuildTools, CoreClr, CoreFx, PgoData to preview1-03013-03, pre… Jul 17, 2018
LICENSE.TXT Update License and add 3PN notices (#10117) Mar 12, 2017
PATENTS.TXT Add additional data to PATENTS.TXT Nov 18, 2015 Fixed typos on readme (#18304) Jun 5, 2018
THIRD-PARTY-NOTICES.TXT HashCode based on xxHash32 (#14863) Nov 16, 2017
UpdatePublishedVersions.ps1 Use versions repo tooling from BuildTools. Aug 22, 2016
all.locproj Initial commit to populate CoreCLR repo Jan 30, 2015
build-packages.cmd Merge pull request #6613 from wtgodbe/packagebuilds Oct 17, 2016 Remove Alpine 3.6 builds Apr 24, 2018
build-test.cmd Move RuntimeIDArg initialization (#18747) Jul 2, 2018 CoreFX CI Unix (#18753) Jul 12, 2018
build.cmd Use BuildManagedTools argument instead of environment variable, remov… Jul 9, 2018
build.proj Use BuildManagedTools argument instead of environment variable, remov… Jul 9, 2018 Remove -Rebuild option from build scripts (#18089) May 23, 2018
clean.cmd Fix clean.cmd to work if no parameters are passed (#14969) Nov 10, 2017 Update script to reflect changes introduced in clean.cmd, un… Nov 8, 2017
clr.coreclr.props Move x86 HW intrinsics files to shared (#18427) Jun 13, 2018
clr.defines.targets Revert "Enable EventPipe across Unix and Windows (#14772)" (#15609) Dec 21, 2017
clrdefinitions.cmake Remove relocations for vtable chunks (#17147) Jun 29, 2018
clrfeatures.cmake Disable FEATURE_NI_BIND_FALLBACK by default for all platforms Mar 7, 2018
cmake.definitions Change to Generate nuget packages for Windows Arm64 builds. Jun 25, 2016
compileoptions.cmake Set -march=armv7-a for Alpine Linux ARM32 (#17730) Apr 23, 2018
config.json Use BuildManagedTools argument instead of environment variable, remov… Jul 9, 2018
configure.cmake Add PGO support for Clang/LLVM on Unix (#10533) Mar 30, 2017
crosscomponents.cmake Remove more JIT LEGACY_BACKEND tendrils May 23, 2018
crossgen.cmake Remove always defined FEATURE_RANDOMIZE_STRING_HASHING define (#13491) Aug 28, 2017
dac.cmake Enabling profiling on Unix/OS X. Jan 31, 2016
definitionsconsistencycheck.cmake Move intermediate file into intermediate dir (#5981) Jun 28, 2016
dependencies.props Update BuildTools, CoreClr, CoreFx, PgoData to preview1-03013-03, pre… Jul 17, 2018
dir.props [Arm64] Add x64_arm64 crossgen to tools package Mar 31, 2018
dir.targets update version of buildtools Jan 29, 2016
dir.traversal.targets Respond to PR feedback Feb 14, 2017
dotnet-download.ps1 Refactor dotnet download code in init-tools.cmd (#10527) Apr 1, 2017 Fix asan false-positive errors: (#15563) Jan 25, 2018
functions.cmake Add prefix to DAC's PAL exports for alpine (#18873) Jul 13, 2018
generateexportedsymbols.awk Add prefix to DAC's PAL exports for alpine (#18873) Jul 13, 2018
generateredefinesfile.awk Add prefix to DAC's PAL exports for alpine (#18873) Jul 13, 2018
generateversionscript.awk Add prefix to DAC's PAL exports for alpine (#18873) Jul 13, 2018
global.json Using full versions, update CoreFX dependencies to beta-24328-05. Jul 29, 2016
init-tools.cmd Sync init-tools scripts with what is in source-build Mar 28, 2018
init-tools.msbuild Publish symbols using Microsoft.SymbolUploader.Build.Task package (#1… Apr 7, 2018 Pass RID to crossgen (#18592) Jun 23, 2018
netci.groovy Merge pull request #18917 from BruceForstall/dev/unix_test_workflow Jul 16, 2018
oacr.cfg Initial commit to populate CoreCLR repo Jan 30, 2015
perf.groovy Reduce the number of days to keep artifacts for perf (#18073) May 21, 2018
pgosupport.cmake Turn off PGO unprofiled warning on Linux (#17262) Mar 27, 2018
publish-packages.cmd Proof-of-concept of using new Publish infra in coreclr Oct 11, 2017 Proof-of-concept of using new Publish infra in coreclr Oct 11, 2017 NetBSD: Add support for retrieving the number of available CPUs Jan 21, 2016
run.cmd Remove vs2015 build dependencies Mar 7, 2018 Switch to sourcing in init-tools to enable the return statements to work Oct 30, 2017
sanitizerblacklist.txt Reduce clr startup noise when using Clang sanitizers Jan 21, 2016
setup_vs_tools.cmd Remove vs2015 build dependencies Mar 7, 2018
sync.cmd Proof-of-concept of using new Publish infra in coreclr Oct 11, 2017 Fix to call run.exe -p even if positional parameters are spec… Jun 27, 2018 Fix shared library dependencies verification on some platforms (#8349) Nov 29, 2016

.NET Core Common Language Runtime (CoreCLR)

This repository contains the complete source code for the runtime of .NET Core. If you are new to .NET Core start with the About .NET that quickly points you to .NET Core Tutorials.

.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.

If You Just Want to Use .NET Core

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.

Are you Here for Something Besides the Source Code?

In addition to providing the source code, this repository also acts as a useful nexus for things related to .NET Core including:

What Can you Make from this Repository?

.NET Core relies heavily on the NuGet package manager, which is a system to package, distribute and version software components. See 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. 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 application.

In concrete terms, this repository is best thought of as the source code for the following NuGet package:

  • Microsoft.NETCore.Runtime.CoreCLR - Represents the object allocator, garbage collector (GC), class loader, type system, interop and the most fundamental parts of the .NET class library (e.g. System.Object, System.String ...)

It also contains the source code for the following closely related support packages.

  • Microsoft.NETCore.Jit - The Just In Time (JIT) compiler for the .NET Intermediate language (IL)
  • Microsoft.NETCore.ILAsm - An assembler for the .NET Intermediate language (IL)
  • Microsoft.NETCore.ILDAsm - A disassembler (Pretty printer) for the .NET Intermediate language (IL)
  • Microsoft.NETCore.TestHost - This contains the corehost.exe program, which is a small wrapper that uses the .NET Runtime to run IL DLLs passed to it on the command line.
  • Microsoft.TargetingPack.Private.CoreCLR - A set of assemblies that represent the compile time surface area of the class library implemented by the runtime itself.

Relationship with the CoreFX Repository

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.Object, System.String, System.Threading.Thread, 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 (System.Collections, System.IO, System.Xml and 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.Object and System.String. Thus from an applications point of view these types live in System.Runtime.dll. However, System.Runtime.dll (defined in the CoreFX repo) forwards references ultimately to System.Private.CoreLib.dll 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 you use 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 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 to make a complete application. More on this in the Using Your Build page.

Setting up your GIT Clone of the CoreCLR Repository

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.

Building the 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.cmd or at the base of the repository.

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'

  • Debug (default)- This compiles the runtime with additional runtime checks (asserts). These checks slow runtime execution but are really valuable for debugging, and is recommended for normal development and testing.
  • Release - This compiles without any development time runtime checks. This is what end users will use but can be difficult to debug. Pass 'release' to the build script to select this.

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)

    .\build skiptests 

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.

Using Your Build

The build places all of its generated files under the bin directory at the base of the repository. There is a 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

  • bin\Product\Windows_NT.x64.Release

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

  • bin\Product\Windows_NT.x64.Release.nuget\pkg

These packages are the 'output' of your build.

There are two basic techniques for using your new runtime.

  1. 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.

  2. 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.

Editing and Debugging

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.

Running Tests

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.

Contributing to Repository

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.

This project has adopted the code of conduct defined by the Contributor Covenant to clarify expected behavior in our community. For more information, see the .NET Foundation Code of Conduct.

Related Projects

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.

  • dotnet/corefx - Source for the most common classes in the .NET Framework library.
  • dotnet/core-setup - Source code for the dotnet.exe program and the policy logic to launch basic .NET Core code (hostfxr, hostpolicy) which allow you to say 'dotnet SOME_CORE_CLR_DLL' to run the app.
  • dotnet/cli repo - Source for build time actions supported by dotnet.exe Command line Interface (CLI). Thus this is the code that runs when you do 'dotnet build', 'dotnet restore' or 'dotnet publish'.
  • dotnet/core-docs - Master copy of documentation for

See Also

Important Blog Entries


.NET Core (including the coreclr repo) is licensed under the MIT license.