Is .NET Execution Environment (DNX) similar to mon

Question

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 alternative of mono? If not, then what will be the difference?

Answer 1

Is DNX alternative of mono? If not, then what will be the difference?

Mono is an open sourced development platform. It's implementation is based on the CLI specification, such as the platform that is provided by Microsoft. It includes a C# compiler, a runtime, a BCL and something called MCL (Mono Class Library, which is an extensions to the BCL). Mono itself can run on Linux, OSX, BSD and Windows on varying architectures.

DNX is an SDK containing all of the bits needed to build and run an application (including custom utilities such as the dnu which is used to build and package the app), including the CLR (currently it deploys with CoreCLR). This CoreCLR can also be switched with Mono, which means it will be consuming all services of the Mono runtime, compiler, etc.

Mono as opposed to DNX provides the full platform (Runtime, BCL, JIT, etc). DNX is used at the lowest level as the Native Process which invoked the CoreCLR. DNX would be used for scenarios such as self-host or building and running from the command line.

As @xanatos points out, DNX aspire to be able to ship the runtime with the application, where multiple runtimes will be able to live side by side without interfering each other.

Perhaps this image can clarify:

Here is the list which DNX can run on top (x86 showing twice as it is the default):

Active Version           Runtime Architecture Location                           Alias
------ -------           ------- ------------ --------                           -----
  *    1.0.0-beta2-10735 clr     x86          C:\Users\victorhu\.dnx\runtimes default
       1.0.0-dev         clr     x64          C:\Users\victorhu\.dnx\runtimes clr-x64-dev
       1.0.0-dev         clr     x86          C:\Users\victorhu\.dnx\runtimes clr-x86-dev
       1.0.0-dev         coreclr xd64         C:\Users\victorhu\.dnx\runtimes coreclr-x64-dev
       1.0.0-dev         coreclr x86          C:\Users\victorhu\.dnx\runtimes coreclr-x86-dev
       1.0.0-dev         mono                 C:\Users\victorhu\.dnx\runtimes mono-dev

There is an extensive wiki page explaning the DNX structure for more. @Will points out the ASP.NET docs page as well.

Update: 25/02/2016

DNX is now retired in favor of .NET CLI Tools.

Answer 2

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.

Answer 3

DNX is retired, as it said on the repo site. It better to compare dotnet cli with mono. Dotnet cli is new project and it doesn't supports all .net libraries case it has it own core libraries that are different with .net framework.