Is .NET Execution Environment (DNX) similar to Mono?

Vano Maisuradze picture Vano Maisuradze · May 21, 2015 · Viewed 8.1k times · Source

Here is the description of DNX:

The .NET Execution Environment (DNX) is a software development kit (SDK) and runtime environment that has everything you need to build and run .NET applications for Windows, Mac and Linux. It provide a host process, CLR hosting logic and managed entry point discovery. DNX was built for running cross-platform ASP.NET Web applications, but it can run other types of .NET applications, too, such as cross-platform console apps.

Is DNX an alternative to Mono? If not, then what will be the difference?

Answer

Hans Passant picture Hans Passant · May 21, 2015

Yes, DNX compares pretty well to Mono's mono.exe. Or for that matter the runtime of other VM languages like Java (java.exe) or Python (python.exe). They all solve the same chicken-and-egg problem, they run on operating systems that don't know beans about the VM. It has to be initialized first, the program's entry point needs to be located and the Main() method needs to be jitted before your program can start running.

One small difference in DNX with these other VMs is that it keeps the CLR and the jitter still in a separate library, coreclr.dll. The other ones are monolithic with all the runtime support code compiled into a single exe. Keeping it monolithic improves cold-start performance. Probably something that will happen with dnx as well, once CoreCLR stabilizes and doesn't have umpteen different beta releases.

This otherwise follows the architecture of .NET on Windows, it is c:\windows\system32\mscoree.dll that bootstraps the CLR. And the CLR and jitter are separate DLLs, clr.dll and clrjit.dll for .NET 4.x. Mscoree uses significant trickery and deceit to make it look like you can start a managed program from a single EXE file. Particularly the trick to create a 64-bit process from a 32-bit EXE file is heroic, it patches internal operating system loader structures to accomplish that feat. This requires Windows itself to be aware that an EXE contains managed code. Trickery that does not translate well to other operating systems like Linux and OSX so they decided for the more conventional way for CoreCLR.


Update: DNX is now deprecated and replaced by DOTNET. Otherwise without invalidating this post content, just easier to use.