Compiling .NET Core code on Linux/OS X


I’m just catching up on all the announcements today. I’m looking at the project’s build scripts and I’m trying to understand the current and planned compiler story for .NET Core on Linux/OS X.

Let’s break down this line from the build script.

mono packages/Sake/tools/Sake.exe -I packages/KoreBuild/build -f makefile.shade "$@"

  • Clearly mono is required to run the build tools. Is this mono dependency the long term plan, or are their plans to eliminate the mono dependency?
  • Sake.exe. Never heard of it, will need to look into it. Documentation seems a bit slim with regards to the makefile.shade file format. Any insights?
  • KoreBuild what exactly is this?

Further, what role (if any) does Roslyn play here? Is that the KoreBuild thing?


Compiling .Net core on FreeBSD

This is a great question! and one we’ve been spending a lot of time thinking about.

What you have been digging into is what the higher level web stack components have been using to get their stuff working on Mono. It’s unclear whether we’ll want to use it for the whole core stack or not. We’re still quite early in our thinking about how we’re going to do the end to end build on Linux/OS X.

Please share your thoughts on what you’d like to see for:

  • Native C++ Build System
  • Native C++ Compiler
  • C# Build System
  • C# Compiler

Sake.exe is a custom build system used by the ASP.NET Core stack.
KoreBuild is not Roslyn as AFAIK.


I’m mostly interested in the plan around Mono. Is Mono going to be required for building or will we get a native cross-platform compiler? After reading the announcements I was hoping (expecting?) to see Roslyn or similar running natively on Linux and OS X to compile .NET Core.

Additionally, will .NET Core apps require Mono to be installed on the machines they run on?


What I gather is that in the long run you wont need Mono.

But until RyuJit and the .NET Core are ported to Unix/Mac/Linux, you will.


That’s right. And Roslyn running on .NET Core is definitely the plan. In fact, its already running on the context of ASP.NET Core at runtime.

For the build system, we are thinking that C# developers would like to be able to share their build assets across platforms and that many already know MSBuild and use it everyday. Having something like MSBuild for Linux and OS X is something we’re exploring.


I have requested that Microsoft open source MSBuild. We will see where that goes.

I am not sure that “something like msbuild” is a good idea, I think that we need msbuild. You will need msbuild to maintain, develop and extend software on Unix and participate in the larger ecosystem. While Mono has an implementation, it is a trivial one, and it is lacking too many features.

While I am not a fan of MSBuild or XML file formats, the reality is that msbuild is as encroached in the .NET ecosystem as the “.dll” extension is.


I am not sure that “something like msbuild” is a good idea, I think that we need msbuild.

I agree :slight_smile:


There seems to be some misunderstandings in this thread, and I’d like to try to sort them out with a somewhat shot explanation.

Now, before I start, I’d like to say that I am in no way an expert on the subject, but I have been following vNext, and Roslyn for a long while.

First of all, Roslyn is a managed compiler, written in C# and VB. This fact alone means it was never built to run naively anywhere. Not on windows, not on linux, not ever. That isn’t to say it can’t be done. Using stuff like .NET Native, or even some of the AOT capabilities of mono it would probably be possible to compile Roslyn down to a native application, but my point to get across here was that Roslyn is written as a managed compiler.

Given that Roslyn is a managed compiler, it needs to run on a CLR. Traditionally, on windows this meant the CLR (the big thing that comes pre-installed with your OS, and you have to reboot 10-15 times to update), and on OSX/linux this meant mono. Recently, though, as MS released the Core CLR, there is a new contender. So now you can run Roslyn on the Core CLR (meaning, when the Core CLR starts working on linux you don’t need mono to compile applications anymore).

Now, the Core CLR is a limited CLR. It does not have nearly as much frameworks supported as the full CLR (or mono) does. For instance, there is no GUI libraries (at all). Though, whether or not mono GUI frameworks would run on the Core CLR I have no idea. But for anything that isn’t either web server/service or console applications, I expect we’ll be using mono on *nix for a long time.

Next is Sake. As you pointed out, Sake has almost no documentation (at all). Sake was written as a weekend project by one of the team members on the vNext team (if I recall correctly), and they decided it worked well with their goals (cause nobody likes to try to make make work xplat, and MSBuild was not made for the kind of build used to build the vNext repositories). Sake, as far as I know does not run on the Core CLR. It’s a task runner, built as a managed application, thus requiring to run on a CLR (just like Roslyn). So unless it’s changed to be made Core CLR compatible (or already is, I just don’t know about it) it will require mono to run on linux. So to say that “Sake.exe is a custom build system used by the ASP.NET Core stack built on top of .NET Core.” I fear is really wrong.

On to the next thing:
KoreBuild has nothing to do with Roslyn. It’s named KoreBuild because it’s used to build K projects (as they were called way back when). KoreBuild is a collection of Sake shade-files that has defaults for building vNext projects. Think of it like including CSharp.props (or whatever it’s called) in your MSBuild files.

And as to MSBuild, I understand that many would like it on linux, and see that it would be usefull to build projects and integrate with other teams etc. However, personally I’d rather see the new build system, based on project.json extended and used. That build system already work xplat and is open source, and it’s a lot more friendly to work with than MSBuild, albeit a lot more limited.


Open sourcing msbuild would be great, but I think the .net ecosystem is missing a full, integrated, code-based build system with built-in dependency management (NuGet in our case, in place of ivy). I would look to other build systems like gradle and sbt as examples.

Msbuild files and other ide project files should be generated by the tool. Gradle and sbt similarly have plugins that can generate eclipse and intellij project files (at least until intellij added native support for both of these).

The closest thing we have now are Fake, the F# build tool, and k, the json based build system for vnext. Unfortunately fake doesn’t support other .net languages or integrate NuGet into the build system. And while k integrates NuGet, it isn’t a code based build system, so it isn’t extensible or customizable like sbt or gradle.

Edit: Correction - Fake DOES support built-in nuget package restore.


This is a very helpful walkthrough. Thank you for clarifying so much!

Sounds like the real thing to look for is the Core CLR running natively on Linux, without Mono. If you have any more resources on that end of things I’d love to read up.

Thanks again!


The news of that was released only 2 days ago, so your best bet is MS blogs currently.


“Sake.exe is a custom build system used by the ASP.NET Core stack built on top of .NET Core.” I fear is really wrong.

Good catch, you are right, its not built explicitly on .NET Core. It is a managed build system.


This is coming. Stay tuned… You’ll see things filling in both below and above the code currently released in the dotnet/corefx repo. We plan to keep it flowing as we decouple it from our internal infrastructure and implement Linux support.


Hi, the Core CLR come from Silverlight and base on Rotor/SSCLI ?



In some ways yes… It’s an evolved version of what was at the core of Silverlight.


I have been trying to use KRE (kestrel, kvm) and would like to see it evolve more and more. I understand that the initial purpose of KRE is for ASP.NET vNext, but I was able to compile a Console Application and run it using kestrel. There was one difference though - the console application was compiled to a DLL instead of EXE. So we will always need k to execute it.

Does that mean k will be expanded for all application types once entire .NET framework becomes cross-platform?

I like the simple format of project.json but I don’t see a point in having both a .csproj for MSBuild and a .kproj and project.json for K builds. I would like to see project.json to be auto-created for those using Visual Studio for development - for both new projects and existing projects that are upgraded to .NET 4.6.

Is there anything like this in the pipeline?


Why do you want to make complicated stuff, 45656425142 step to compile a crossplatform app

Can’t you do like java ? Write your code, Press Play, Run Everywhere

I’ll never understand that Microsoft logic… always complicate stuff for new users

It’s a begining of something new, so please make things EASY, and EASIER to learn


I think you’re not understanding something important; this is talking about compiling the .NET Core Libraries themselves, not applications that will use them. Writing end user applications will remain the same as always.


It would be nice to have one NEW build system for all .NET Core based apps which is also crossplatform.

I don’t think making MSBuild xplat will be the right solution. MSBuild is quite old and little bit obsolete.
Also KVM is something like NPM in Node. It is not used for build mostly.

Why not take Java as example? or Node JS?
They all have build systems, which use their languages as build system languages (like Gulp in NodeJS which is pure javascript and Gradle in Java which is dialect of Groovy). This gives tremendous flexibility and extensibility (no XML at all). These build systems are very good integrated to their package managers (NPM for Node & Ivy for Java).
Why should we invent wheel?
We need something very similar for .NET!

New build system must be:

  1. based on C# or F# (even better as it is better for DSL scripting)
  2. must be integrated to Nuget
  3. must be xplat and managed based on .NET Core
  4. must be highly extensible with third-party plugins (just give us build system and community will make all plugins it needs)
  5. all we need to build apps is project.json (like packege.json) & build script on new build system (like gulp.js or gruntfile.js)

Maybe this one is good enough ? It seems to be very fluent and easy-to-use


Good news: MSBuild Engine is now Open Source on GitHub

.NET Foundation Website | Blog | Projects | Code of Conduct