Can .NET Core be used to build native Linux binaries?

Question

Apologies if the question seems basic, but I did some Googling and couldn't find a clear answer (Perhaps I don't know the right keywords).

Can .NET Core be used to build native command-line Linux binaries from C# / F# sources? (I'm aware of Mono)

Narthex

Answer 1

Yeah, it can. I've messed with it a bit.

dotnet new console

...

dotnet publish -c release -r linux-x64

Or something along those lines... It's been a while since I messed with it, but there is help and tutorials out there for doing dotnet on Linux and I've gotten it to work just fine on CentOS 7. Of course, I did this on a Linux machine and not from a Windows machine. If your asking if you can create a console (command-line) app on Windows for Linux with .NET Core, I don't know.

Sosna

Thanks, do you know if the performance is comparable to JIT-compiled bytecode? – Narthex

I didn't work on any big projects or concern myself with performance, so I couldn't really say. I would assume it would be better than JIT-compiled bytecode, but I wouldn't think .NET on Linux would be terribly efficient. Even the smallest programs with the most optimizations and least amount of libraries are still rather large with several .so shared libraries on the side. But, that's just the nature of .NET. I don't even know if you can compile the libraries in statically, but the main program would still be large for a simple hello world. – Sosna

I don't think this builds a native library, it builds a .NET application ready to be deployed on Linux (and you should be able to build on windows). Single binary exe is slated for .net core 3 (so soon), that should include the dependencies in one file. – Decoy

@Decoy It depends on your settings in your config files. It's been some time since I messed with it, but it can produce an executable file with .so shared objects (dynamic link libraries .dll equivalent in Linux) and you don't need to "dotnet run" them, they run natively. – Sosna

Tbh, the OP was a bit vague, however the follow-up comment from OP indicated he is comparing JIT compiled code with native compiled code. You can create an exe for sure but that is still JIT compiled, it just calls dotnet run behind the scenes. So a an executable (w/o dotnet run, called self-contained), a single executable (statically linked with the libararies and trimmed, so think 30MB for Hello World), and a true compiled to native code binary are three different things. This latter one is called AOT ahead of time instead of JJIT), and CoreRT does it but it's not there yet for everything. – Decoy

Answer 2

AOT is a feature available starting from dotnet 7.0, even though it has a few limitations such as currently being available only for console applications, requiring trimming which also has some limitations and not all dotnet libraries being compatible with it (see more information at the provided links).

Enabling

In order to enable AOT, in your .csproj:

<PropertyGroup>
    <!-- enabled aot publishing -->
    <PublishAot>true</PublishAot>

    <!-- reduces binary size, no debug symbols -->
    <StripSymbols>true</StripSymbols> 
</PropertyGroup>

Publishing

$ dotnet publish --runtime <RID> --configuration <Debug | Release>

Example

Hello world application, native binary size and memory consumption.

Fistula

In time, rid catalog and code samples. – Fistula