A (Hitchhiker’s) Guide To The .NET Core Projects on GitHub

Following on from my last post, I’ve been playing around some more with the various things that constitute the new .NET, and talking to people on the various teams. So I’m planning a few follow-up posts going into more detail, of which this is the first.

I’m going to push Markdown headings to their limit in this; I can sense it coming.

The .NET Core Projects

Most of the work on this stuff is happening within two organizations on GitHub:

the dotnet organization is where you’ll find the foundational stuff; while the aspnet organization contains what is now called ASP.NET Core 1.0.


This organization has a couple of dozen repositories, but there are six main ones that interest me right now.


The CoreFx project is the open-source (as in proper, MIT-license) version of the .NET Base Class Library (BCL) and Framework Class Library (FCL). I’ve never been entirely clear where one of those stops and the other starts, but the BCL goes right down to the primitive types, string handling, I/O, all that sort of stuff. Some of the really fundamental BCL types are contained in mscorlib, which is part of the CoreCLR project, because they’re needed by the runtime itself, or because they need special knowledge about it. The FCL, in the full (closed-source, Windows-only) .NET Framework, included Windows Forms, WPF, ASP.NET (Web Forms), WCF, and I think things like System.Xml too. Obviously all that Windows-specific stuff isn’t in CoreFx, but the general-purpose things have mostly made it across, although it looks like Microsoft have taken the opportunity to finally retire some "deprecated" types. There are also some brand new components in there, such as System.Buffers, which provides basic array-pooling functionality.

Regardless of which runtime you’re using, you’ll be using CoreFx components.


The CoreCLR project is the new cross-platform Common Language Runtime. The CLR is .NET’s "virtual machine", like Java’s JVM. It loads assemblies that contain byte-code, and uses a "Just-In-Time" (JIT) compiler to turn it into machine code for the specific OS, CPU and so on that it’s running on. It also includes low-level features like the Garbage Collector, which cleans up the memory used by objects when they’re no longer needed.

This project is also where you’ll find mscorlib, the absolutely-lowest level of the Base Class Library.

Unlike the proprietary, Windows-only .NET CLR, CoreCLR is open-source (MIT again) and cross-platform (Linux and OSX as well as Windows). Enthusiastic contributors are also working to get it running on BSD-based operating systems, and ARM CPUs as well as x86.

For the initial .NET Core 1.0 release, CoreCLR will be the only runtime capable of running all .NET Core applications. You’ll be able to deploy the entire runtime along with your application, rather than having it pre-installed on the target computer. That’s going to be great for simplifying installations (no more "This application requires Microsoft .NET Framework 2.0" messages), as well as removing concerns about whether upgrading to newer versions will break other applications on the computer.


This was the subject of the earlier blog post, so I already went into a fair amount of detail. To recap, CoreRT is an alternative to CoreCLR that is optimized for Ahead-Of-Time (AOT) compilation, as opposed to JIT. It has its own variant of mscorlib, and will have its own Garbage Collector, although I guess much of the code for both may well be shared between the projects.

Certain other areas of .NET which make active use of JIT compilation at runtime (such as optimizations in System.Linq.Expressions) will be implemented differently for CoreRT, since there will be no JIT at runtime. I don’t know exactly how these differences will be handled by the CoreFx project, but CoreRT applications will use the CoreFx libraries, just like CoreCLR applications.

The CoreRT project is at a very early stage compared to CoreFx and CoreCLR, and not all features will be at "ship-it" quality at the time of the main .NET Core 1.0 release (such as native compilation). Right now, it works on Windows and Mac, but only a small subset of Linux distros (including Ubuntu 14.04 and CentOS 7.1); various people are working hard to get it working on more (somebody get it on Arch, please!).

Eventually you should be able to compile most .NET Core code, including ASP.NET Core, to a native binary for a specific platform, but it sounds like that’s a fair way off yet.

CoreRT is also MIT licensed.


The CLI project is the .NET Core command line interface. It provides the dotnet command that .NET Core developers will become very familiar with: it’s used to create new projects, install packages, and build and run applications. I think this is built on CoreRT rather than CoreCLR, although I may have that wrong. Certainly, if you’re building CoreRT applications, you use the dotnet CLI to do it.

This new dotnet command is replacing the dnu and dnx commands in ASP.NET Core. That change is why there’s been so much upheaval in that project lately, but it’s all going to be better for it in the long run.


LLILC (LLVM MSIL Compiler) is an alternative compiler for turning .NET byte-code into machine code, using the LLVM compiler infrastructure project.

LLVM started out as a step in a C/C++/Objective-C compiler (Clang), but is now used by all sorts of languages including Rust, Swift and Rubinius. It’s even used by Emscripten to compile C/C++ to JavaScript.

The LLILC project is currently focused on providing an alternative to RyuJIT, placing more emphasis on the optimization of the generated machine code and less on doing the compilation quickly. This makes great sense for applications that are designed to be started infrequently and to run for a long time, such as web applications or daemons/services.

A longer term goal for LLILC is to look at providing AOT compilation; it could end up being used instead of RyuJIT by the CoreRT native compiler, although only time will tell.


The dotnet organization also owns Roslyn, the C# and Visual Basic compilers and tools (written in C# and Visual Basic respectively). Roslyn is also open-source, although unlike the other projects it is Apache 2.0 rather than MIT.

Having an open, cross-platform compiler framework is fundamental to all the other .NET Core projects, including ASP.NET Core, which runs from source code by default. It has also meant we get cross-platform language services for projects like OmniSharp.

If you’re interested in the future of C# or VB, the Roslyn issues area is where they’re being discussed.


The other organization, aspnet, contains a whole bunch of projects that, when put together, make up ASP.NET Core 1.0. This new web framework includes both MVC and WebAPI functionality in such a way that we don’t need to think of (or version) them separately any more. They’re just how you make web applications now (although Nancy and other frameworks will be able to run on top of the lower level components).

For the 1.0 release, you’ll be able to run ASP.NET Core applications on the Windows-only Microsoft .NET Framework, the CoreCLR, and Mono 4.2+.

You’ll also use the .NET Core CLI (dotnet) to create, package and build applications.

Throughout most of its development, the framework previously known as ASP.NET 5 has used its own dnx and dnu command line tools, and its own Target Framework Monikers (TFMs): dnxcore50 for .NET Core and dnx451 for Microsoft .NET or Mono (depending on which OS you’re running). The Core TFMs are going to change to netstandard or netstandardapp; I don’t know what’s happening to dnx451.

There are a ton of projects in this organization, as they’ve broken everything out into stand-alone modules as much as possible. The MVC project is where it all comes together, but there are separate projects for Razor, Security, Identity, Logging, Configuration and more. Entity Framework Core lives here, too.

One ASP.NET project I do want to call out in particular is the Kestrel HTTP Server, which is a new cross-platform HTTP Server built specially for .NET Core. It wraps around libuv, which is the asynchronous I/O library at the heart of Node.js, among other things. Kestrel has seen some amazing work lately, and its performance is astoundingly good. Whether you’re running your ASP.NET Core application on Windows or Linux, it’s going to run really, really well.

Right, this post has shot past 1000 words, so I’m going to stop writing it now. In future posts, I’ll be looking in more detail at all these projects, including what’s changed, what’s new and what’s gone in CoreFx, as well as more info and regular updates on progress on the CoreRT project.

Share on facebook
Share on google
Share on twitter
Share on linkedin


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.