¿El entorno de ejecución.NET(DNX) es similar a mono?

Question

Aquí está la descripción de DNX:

.NET Execution Environment (DNX) es un kit de desarrollo de software (SDK) y entorno de ejecución que tiene todo lo que necesita para crear y ejecutar aplicaciones .NET para Windows, Mac y Linux. Proporciona un proceso de host, lógica de alojamiento de CLR y descubrimiento de punto de entrada administrado. DNX fue creado para ejecutar aplicaciones web ASP.NET multiplataforma, pero también puede ejecutar otros tipos de aplicaciones .NET, como aplicaciones de consola multiplataforma.

¿DNX es una alternativa de mono? Si no, ¿cuál será la diferencia?

Answer 1

¿DNX es una alternativa de mono? Si no, ¿cuál será la diferencia?

Mono es una plataforma de desarrollo de fuente abierta. Su implementación se basa en la especificación CLI, como la plataforma que proporciona Microsoft. Incluye un compilador de C #, un tiempo de ejecución, un BCL y algo llamado MCL (Mono Class Library, que es una extensión del BCL). Mono puede funcionar en Linux, OSX, BSD y Windows en arquitecturas variables.

DNX es un SDK que contiene todos los bits necesarios para compilar y ejecutar una aplicación (incluidas las utilidades personalizadas como el dnu que se usa para compilar y empaquetar la aplicación), incluido el CLR (actualmente se implementa con CoreCLR ). Este CoreCLR también se puede cambiar con Mono, lo que significa que consumirá todos los servicios del tiempo de ejecución Mono, compilador, etc.

Mono a diferencia de DNX proporciona la plataforma completa (Runtime, BCL, JIT, etc.). DNX se utiliza en el nivel más bajo como el Proceso nativo que invocó el CoreCLR. DNX se usaría para escenarios como el auto-host o la construcción y ejecución desde la línea de comandos.

Como @xanatos señala, DNX aspira a poder enviar el tiempo de ejecución con la aplicación, donde múltiples tiempos de ejecución podrán vivir uno al lado del otro sin interferirse entre sí.

Quizás esta imagen puede aclarar:

Aquí está la lista que DNX puede ejecutar en la parte superior (x86 se muestra dos veces, ya que es la predeterminada):

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

Hay una extensa página wiki explicando la estructura de DNX para más. @Will también señala la página de documentos ASP.NET .

Actualización: 25/02/2016

DNX ahora está retirado a favor de .NET CLI Tools .

Answer 2

DNX está retirado, como se dijo en el sitio de repos . Es mejor comparar dotnet cli con mono. Dotnet cli es un proyecto nuevo y no admite todas las bibliotecas .net si tiene sus propias bibliotecas centrales que son diferentes con .NET Framework.

Answer 3

Sí, DNX se compara bastante bien con mono.exe de Mono. O, para el caso, el tiempo de ejecución de otros lenguajes VM como Java (java.exe) o Python (python.exe). Todos resuelven el mismo problema de la gallina y el huevo, se ejecutan en sistemas operativos que no saben sobre la máquina virtual. Primero debe inicializarse, el punto de entrada del programa debe ubicarse y el método Main () debe ser jed antes de que su programa pueda comenzar a ejecutarse.

Una pequeña diferencia en DNX con estas otras máquinas virtuales es que mantiene el CLR y la inestabilidad aún en una biblioteca separada, coreclr.dll. Los otros son monolíticos con todo el código de soporte de tiempo de ejecución compilado en un solo archivo ejecutable. Mantenerlo monolítico mejora el rendimiento de arranque en frío. Probablemente algo que sucederá con dnx también, una vez que CoreCLR se estabilice y no tenga muchas versiones beta diferentes.

De lo contrario, sigue la arquitectura de .NET en Windows, es c: / windows / system32 / mscoree.dll que inicia el CLR. Y el CLR y el jitter son archivos DLL separados, clr.dll y clrjit.dll para .NET 4.x. Mscoree usa trucos y engaños significativos para que parezca que puede iniciar un programa administrado desde un solo archivo EXE. Particularmente, el truco para crear un proceso de 64 bits a partir de un archivo EXE de 32 bits es heroico, parchea las estructuras internas del cargador del sistema operativo para lograr esa hazaña. Esto requiere que Windows sepa que un EXE contiene código administrado. Engaño que no se traduce bien en otros sistemas operativos como Linux y OSX, por lo que optaron por la forma más convencional para CoreCLR.

Actualización: DNX ahora está en desuso y reemplazado por DOTNET . De lo contrario, sin invalidar el contenido de esta publicación, simplemente más fácil de usar.