Ist .NET Execution Environment (DNX) mono ähnlich?

Question

Dies ist die Beschreibung von DNX:

.NET Execution Environment (DNX) ist ein Software Development Kit (SDK) und Laufzeitumgebung, die alles, was Sie und ausführen, die .NET-Anwendungen für Windows erstellen müssen hat , Mac und Linux. Es stellt einen Host-Prozess, eine CLR-Hosting-Logik und eine Verwaltungspunkt-Erkennung bereit. DNX wurde für die Ausführung von plattformübergreifenden ASP.NET-Webanwendungen erstellt, kann aber auch andere .NET-Anwendungstypen wie plattformübergreifende Konsolenanwendungen ausführen.

Ist DNX Alternative von Mono? Wenn nicht, was wird der Unterschied sein?

Answer 1

Ist DNX Alternative von Mono? Wenn nicht, was wird der Unterschied sein?

Mono ist eine Open Source Entwicklungsplattform. Die Implementierung basiert auf der CLI-Spezifikation, z. B. der von Microsoft bereitgestellten Plattform. Es enthält einen C# -Compiler, eine Laufzeitumgebung, eine BCL und eine so genannte MCL (Mono Class Library, eine Erweiterung der BCL). Mono selbst kann unter Linux, OSX, BSD und Windows auf verschiedenen Architekturen laufen.

DNX ist ein SDK erforderlich, um alle der Bits enthält, um eine Anwendung zu erstellen und auszuführen (einschließlich kundenspezifischer Dienstprogramme wie der dnu die verwendet wird, zu bauen und den App-Paket), einschließlich der CLR (derzeit setzt es mit CoreCLR). Diese CoreCLR kann auch mit Mono geschaltet werden, was bedeutet, dass sie alle Dienste der Mono-Laufzeit, Compiler, etc. verbraucht.

Mono im Gegensatz zu DNX bietet die volle Plattform (Runtime, BCL, JIT, etc). DNX wird auf der niedrigsten Ebene als der Native-Prozess verwendet, der die CoreCLR aufruft. DNX würde für Szenarien wie Self-Host oder das Erstellen und Ausführen von der Befehlszeile verwendet werden.

Wie @xanatos hervorhebt, möchte DNX in der Lage sein, die Laufzeit mit der Anwendung zu liefern, wobei mehrere Laufzeiten Seite an Seite nebeneinander existieren können, ohne sich gegenseitig zu stören.

Vielleicht kann dieses Bild verdeutlichen:

Hier ist die Liste, die DNX oben laufen kann (x86 zeigt zweimal, wie es der Standard ist):

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 ist umfangreiche wiki page Erläuterung der DNX-Struktur für mehr. @Will weist auch auf die hin.

Update: 25/02/2016

DNX jetzt für .NET CLI Tools im Ruhestand ist.

Answer 2

Ja, DNX vergleicht ziemlich gut mit Monos mono.exe. Oder die Laufzeit anderer VM-Sprachen wie Java (java.exe) oder Python (python.exe). Sie alle lösen das gleiche Henne-und-Ei-Problem, sie laufen auf Betriebssystemen, die nichts über die VM wissen.Es muss zuerst initialisiert werden, der Einstiegspunkt des Programms muss lokalisiert werden und die Main() - Methode muss aktiviert werden, bevor das Programm gestartet werden kann.

Ein kleiner Unterschied in DNX mit diesen anderen VMs ist, dass es die CLR und den Jitter noch in einer separaten Bibliothek, coreclr.dll, hält. Die anderen sind monolithisch mit dem gesamten Runtime-Support-Code, der zu einer einzigen exe kompiliert wurde. Indem es monolithisch gehalten wird, wird die Kaltstartleistung verbessert. Wahrscheinlich etwas, das auch mit dnx passieren wird, sobald CoreCLR sich stabilisiert und nicht viele verschiedene Betaversionen hat.

Dies folgt ansonsten der Architektur von .NET unter Windows, es ist c: \ windows \ system32 \ mscoree.dll, das die CLR bootstrappt. Und CLR und Jitter sind separate DLLs, clr.dll und clrjit.dll für .NET 4.x. Mscoree verwendet erhebliche Tricks und Täuschungen, damit es so aussieht, als könnten Sie ein verwaltetes Programm aus einer einzigen EXE-Datei starten. Besonders der Trick, einen 64-Bit-Prozess aus einer 32-Bit-EXE-Datei zu erstellen, ist heroisch: Er patcht interne Betriebssystem-Loader-Strukturen, um diese Leistung zu erreichen. Dies erfordert, dass Windows selbst beachtet, dass eine EXE verwalteten Code enthält. Trickery, die nicht gut auf andere Betriebssysteme wie Linux und OSX übersetzt werden kann, so entschieden sie sich für den konventionelleren Weg für CoreCLR.

---

Update: DNX ist veraltet und replaced by DOTNET. Ansonsten ohne diesen Post-Inhalt zu entwerten, einfach einfacher zu verwenden.

Answer 3

DNX ist im Ruhestand, wie es auf der repo site sagte. Es ist besser, dotnet cli mit Mono zu vergleichen. Dotnet cli ist ein neues Projekt und es unterstützt nicht alle .net-Bibliotheken, wenn es eigene Core-Bibliotheken hat, die sich mit .net-Framework unterscheiden.