CoreCLR is now Open Source

CoreCLR is now Open Source

Rate This
  • Comments 16

We’re excited to announce that CoreCLR is now open source on GitHub. CoreCLR is the .NET execution engine in .NET Core, performing functions such as garbage collection and compilation to machine code. .NET Core is a modular implementation of .NET that can be used as the base stack for a wide variety of scenarios, today scaling from console utilities to web apps in the cloud. To learn how .NET Core differs from the .NET Framework, take a look at the Introducing .NET Core blog post.

You can check out the CoreCLR sources, fork, clone and build. We have released the complete and up-to-date CoreCLR implementation, which includes RyuJIT, the .NET GC, native interop and many other .NET runtime components. This release follows from our earlier release of the core libraries, both of which demonstrate our strong commitment to sharing a complete cross-platform .NET implementation.

Today, .NET Core builds and runs on Windows. We will be adding Linux and Mac implementations of platform-specific components over the next few months. We already have some Linux-specific code in .NET Core, but we’re really just getting started on our ports. We wanted to open up the code first, so that we could all enjoy the cross-platform journey from the outset.

Talking to the Team

The .NET Core folks spent some time in the Channel 9 studio, talking about CoreCLR and CoreCLR repo. Check out the conversation, below. The team will also be showing up for today’s ASP.NET Community standup. We’ll post the live link when we have it.

Taking a look at the coreclr repo

The CoreCLR repo is very similar in nature to the CoreFX repo, which many of you have been engaging with over the last few months. We’ll continue to evolve these repos together so that your experience feels natural across the fairly large codebase.

From a size perspective, the coreclr repo has ~ 2.6M lines of code. Within that count, the JIT is about 320K lines and the GC about 55k. We recently shared that the CoreFX repo is at 500K lines and only at about 25% of its eventual size. It's fair to say that the two repos will total ~ 5M lines by the time .NET Core is fully available on GitHub.

clip_image002

The one key difference between the two repos is that corefx is all C# and coreclr includes large collections of both C# and C++ code. The coreclr repo requires multiple toolsets to build both C# and C++ code, including tools that do not ship with Visual Studio. We took a dependency on CMake, an open source and cross-platform build system. We needed a build system that we could use on Windows, Linux and Mac and that could build for each of those targets. We looked around at the options, and also based on advice, selected CMake.

You can learn how to build CoreCLR from the CoreCLR Developer Guide. The team will be updating the guide over time, particularly as Linux and Mac builds become a reality.

We hope to see many community contributions to the codebase, too. We're in the process of bringing more of our validation infrastructure to the open source environment to make it easier to make contributions. .NET Core supports a diverse set of .NET scenarios, so it’s important that we have a rich set of tests to catch issues as early as possible.

Building applications with .NET Core

It’s great to see .NET Core open source and cross-platform implementations, but you might be wondering what type of apps you can build with it. There are two app types that we are working on and that you can try today:

  • ASP.NET 5 web apps and services
  • Console apps

We’ve been talking about ASP.NET 5 for nearly a year now. You can build ASP.NET 5 apps with the .NET Framework or with .NET Core. Today, ASP.NET 5 uses the Mono runtime to run on Linux and Mac. Once .NET Core supports Linux and Mac, then ASP.NET 5 will move to using .NET Core for those platforms. You can learn more about how to build ASP.NET 5 apps from the ASP.NET team blog or on the asp.net web site. You can also get started building ASP.NET 5 apps in Visual Studio 2015 Preview, right now.

We want to make it possible to build the CoreFX and CoreCLR repos, and use the built artifacts with an ASP.NET 5 app. That's not yet possible, for a few different technical reasons, but we're working on it. It's a strong goal to enable an end-to-end open source experience for .NET Core and ASP.NET 5. You should be able to build your forks with your own changes and use the resulting binaries as the base stack for your apps.

The console app type is a great way to kick the CoreCLR tires. It also gives you a very flexible base to build any kind of app you want. Almost all of our testing infrastructure is built using this app type. You can also build your own custom CoreCLR and run console apps on top of it.

.NET Core Console Apps

At the moment, the .NET Core console app type is a useful byproduct of our engineering process. Over the next few months, we will be shaping it into a fully supported app type, including Visual Studio templates and debugging. We'll also make sure that there is good OmniSharp support for console apps. We believe that many of you will build console tools for Windows, Linux and Mac. You'll also be able to build tools that are cross-platform, that run on all 3 OSes, with just one binary.

Here's a first console demo of .NET Core running on Windows, based on the open source CoreCLR implementation on GitHub.

image

Console App Walkthrough

The easiest way to try out CoreCLR is via the prototype of the CoreCLR-based console application. You can get it from our new corefxlab repo. In order to use it, you can just clone, build, and run via the command line:

git clone https://github.com/dotnet/corefxlab

cd .\corefxlab\demos\CoreClrConsoleApplications\HelloWorld

nuget restore

msbuild

.\bin\Debug\HelloWorld.exe

Of course, once you have cloned the repo you can also simply open the HelloWorld.sln file and edit the code in Visual Studio. Please note that debugging is not yet supported, but debuggers are only for people who make mistakes anyway, right?

You can also modify CoreCLR and make the Console app run against the locally built version of it. At this point, the build automation isn’t that great but here is how you can do that manually with the sources we have today:

  1. Modify CoreCLR to your heart’s content
  2. Build CoreCLR via build.cmd x64 release
  3. Copy the following files from coreclr\binaries\x64\release to corfxlab\demos\CoreClrConsoleApplications\HelloWorld\NotYetPackages\CoreCLR:
    • coreclr.dll
    • CoreConsole.exe
    • mscorlib.dll
  4. Rebuild HelloWorld.sln (either using the command line or in VS)

Summary

We’ve been preparing CoreCLR to release as open source for the last several months, concurrent with new feature development. You'll now see commits showing up in the CoreCLR repo on a daily basis, much like you have with CoreFX . Please do check out the CoreCLR repo and 'watch' it if you want to stay notified on what's going on there. We'll be watching the Issue and PR queues to see where you want improvements in the product.

If you are really excited and want to talk about it, try out the .NET Foundation forums. There are sure to be some good threads that get started about CoreCLR open source. We'll also have some folks from the .NET Core team watching for those threads to answer questions you might have.

We still have a lot to do to deliver on our open source and cross-platform .NET plan. The next stop on the journey will be .NET Conf. It's a virtual .NET conference, slated for March, 2015. We hope to have more fun demos to share, then.

Leave a Comment
  • Please add 8 and 5 and type the answer here:
  • Post
  • Congratulation on this achievement!

    I have some bikeshedding to to about the dotnet/home, dotnet/core and dotnet/projects repositories. It seems like they are repositories for the single purpose of containing some documentation (like readme.md) but they are confusing when you talk about .NET Core, CoreFx and CoreClr.

  • You have an error in your Patent notice, as the wrong URL is referenced, it points to the CoreFX url

  • Also, what is github.com/.../dotnet Is it going to be a Microsoft specific fork of .NET? If so, which part?

  • In gc.cpp I see:

    // file:../../doc/BookOfTheRuntime/GC/GCDesign.doc

    What's that BookOfTheRuntime? Can we have it?

  • Great! I had a look and notice most of the Code Contracts are commented out. Will this be fixed at some point?

  • Nice.

    I'm still not sure I get the 'new' .NET ecosystem... Too many app types and frameworks (.net core, .net micro, .net framework, universal apps, etc) - which is built with what ?

    Also, where does Roslyn fit into this puzzle ?

    For example -- can i create code analysis tools using Roslyn that will execute on Mono already ? and on .NET core in the future ?

  • If you want to blow everyone away, just opensource the Windows source code minus the drivers. That's certain to blow everyone's top worldwide.

  • Our company will not use Mono, because Mono's founders support and fund terrorism. Is .NET Core 100% free of mono?

  • Exciting ... thank you Microsoft.

  • Thank you! Will XNA be soon to follow? It's a top request actually:

    visualstudio.uservoice.com/.../3725445-xna-5

  • @Mike:

    > I have some bikeshedding to to about the dotnet/home, dotnet/core and dotnet/projects repositories.

    We hear you. We're also not entirely happy with these repos. We'll do some more cleanup. At the time we created them it seemed like a good idea :-)

    @Kyle Mueller:

    > You have an error in your Patent notice, as the wrong URL is referenced, it points to the CoreFX url

    Good catch! We've fixed this now:

    github.com/.../7b87614b606cb7f2db5f9aef7dba687d5642d3c0

    github.com/.../ea82bbab30341214fd8d050d1e98808bd5042a3d

    @Mike:

    > Also, what is github.com/.../dotnet Is it going to be a Microsoft specific fork of .NET?

    No, it's essentially simply a repo with Microsoft specific product information that relates to .NET. See my comments above; we aren't entirely happy with the repos we have. We'll probably refactor this to have less of these "landing page" like repos.

    @mark:

    > What's that BookOfTheRuntime? Can we have it?

    Book of the runtime (BOR) is a term we use for implementation specific documentation that our devs wrote. Yes, we're going to publish them. Currently, it's a mix of Word documents, HTML files, and CHM files. We've a task to convert them to standard Markdown documents.

    @Lloyd:

    > I had a look and notice most of the Code Contracts are commented out. Will this be fixed at some point?

    No, we currently don't have plans to bring in code contracts.

    @Lior Tal:

    > I'm still not sure I get the 'new' .NET ecosystem

    OK, let me try:

    Think of .NET Core as a complete .NET implementation. We've two app models for it: the new touch based devices as well as ASP.NET 5.

    .NET Core has two runtimes: CoreCLR, which we open sourced today and .NET Native. You can think of .NET Native as a compiler pipeline that takes MSIL and produces native code plus the GC. Of course, .NET Native is a bit more complicated than that.

    On top of the runtimes, we have the framework which is mostly represented by CoreFX. On top of the runtimes and the framework we have the app models.

    Roslyn is really completely orthogonal to .NET Core. It's the C# and VB compilers. They allow you to target .NET Core as well as .NET Framework. In fact, the compilers can target really anything because as far as the compilers are concerned the runtime is irrelevant on the framework is simply the set of references passed in. So in the context of Roslyn, the .NET implementation you're running against doesn't matter at all.

    In general, you may want read my blog post Introducing .NET Core.

    Does this help?

    @Martin

    > If you want to blow everyone away, just opensource the Windows source code minus the drivers.

    I'm afraid that's not in the realm of things my team has influence on :-)

    @Moishe Pipik

    > Is .NET Core 100% free of mono?

    At this point yes but our goal is to work with the Mono community to make .NET Core great on Mac and Linux, so we do expect some of amount of code flow from Mono to .NET Core.

  • Really cool!

    I was wondering if there is any way to use this to compile ahead-of-time in order to use C# without using Mono on iOS?

    Thanks

  • > more complicated than that

    That link is broken! Seems to be relative instead of absolute

  • @Kevin

    > That link is broken! Seems to be relative instead of absolute

    Sigh. Thanks for pointing this out. Fixed.

  • Awesome work!

    I am really loving the new open Microsoft, and am looking forward to finding out what new posibilities this will bring us all in the coming year(s)!

Page 1 of 2 (16 items) 12