.NET Execution Environment (DNX) è simile a mono?

Question

Qui è la descrizione del DNX:

L'ambiente .NET Execution (DNX) è un kit di sviluppo software (SDK) e ambiente di runtime che ha tutto il necessario per costruire ed eseguire applicazioni .NET per Windows , Mac e Linux. Fornisce un processo host , la logica di hosting CLR e il rilevamento del punto di ingresso gestito. DNX è stato creato per l'esecuzione di applicazioni Web ASP.NET multipiattaforma, ma è possibile eseguire anche altri tipi di applicazioni .NET , ad esempio le app per console multipiattaforma .

È DNX alternativa di mono? Se no, allora quale sarà la differenza?

Answer 1

È DNX alternativa di mono? Se no, allora quale sarà la differenza?

Mono è una open source piattaforma di sviluppo. L'implementazione è basata sulle specifiche CLI, come la piattaforma fornita da Microsoft. Include un compilatore C#, un runtime, un BCL e qualcosa chiamato MCL (Mono Class Library, che è un'estensione del BCL). Mono stesso può funzionare su Linux, OSX, BSD e Windows su architetture diverse.

DNX è uno SDK contenente tutti i bit necessari per costruire ed eseguire un'applicazione (compresi i servizi personalizzati come il dnu che viene utilizzato per costruire e confezionare l'applicazione), incluso il CLR (attualmente schiera con CoreCLR). Questo CoreCLR può anche essere commutato con Mono, il che significa che consumerà tutti i servizi del runtime, del compilatore Mono, ecc.

Mono al contrario di DNX fornisce l'intera piattaforma (Runtime, BCL, JIT, ecc.). DNX è utilizzato al livello più basso del processo nativo che ha invocato il CoreCLR. DNX verrebbe utilizzato per scenari come self-host o building e in esecuzione dalla riga di comando.

Come indica @xanatos, DNX aspira a poter spedire il runtime con l'applicazione, dove più runtime potranno vivere fianco a fianco senza interferire l'un l'altro.

Forse questa immagine può chiarire:

Ecco la lista che DNX può essere eseguito in alto (x86 mostrando due volte, perché è l'impostazione predefinita):

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 

C'è un esteso wiki page spiegando la struttura DNX per più. @Will sottolinea anche lo ASP.NET docs page.

Aggiornamento: 25/02/2016

DNX è ora in pensione in favore di .NET CLI Tools.

Answer 2

Sì, DNX è paragonabile a mono mono.exe. O per quanto riguarda il runtime di altri linguaggi di macchine virtuali come Java (java.exe) o Python (python.exe). Tutti risolvono lo stesso problema di gallina e uova, corrono su sistemi operativi che non conoscono i fagioli della VM.Deve essere prima inizializzato, il punto di ingresso del programma deve essere localizzato e il metodo Main() deve essere jitted prima che il programma possa iniziare a funzionare.

Una piccola differenza in DNX con queste altre macchine virtuali è che mantiene il CLR e il jitter ancora in una libreria separata, coreclr.dll. Gli altri sono monolitici con tutto il codice di supporto runtime compilato in un singolo exe. Mantenerlo monolitico migliora le prestazioni di avviamento a freddo. Probabilmente qualcosa che accadrà anche con dnx, una volta che CoreCLR si sarà stabilizzato e non avrà mille versioni beta diverse.

Questo altrimenti segue l'architettura di .NET su Windows, è c: \ windows \ system32 \ mscoree.dll che avvia il CLR. E il CLR e il jitter sono DLL separate, clr.dll e clrjit.dll per .NET 4.x. Mscoree utilizza ingannevoli trucchi e inganni per far sembrare che si possa avviare un programma gestito da un singolo file EXE. In particolare, il trucco per creare un processo a 64 bit da un file EXE a 32 bit è eroico, e consente di correggere le strutture del caricatore del sistema operativo interno per ottenere tale risultato. Ciò richiede che Windows stesso sappia che un file EXE contiene codice gestito. Trickery che non si traduce bene in altri sistemi operativi come Linux e OSX, così hanno deciso per il modo più convenzionale per CoreCLR.

---

Aggiornamento: DNX è ormai deprecato e replaced by DOTNET. Altrimenti, senza invalidare questo contenuto del post, è solo più facile da usare.

Answer 3

DNX è disattivato, come indicato sullo repo site. È meglio confrontare dotnet cli con mono. Dotnet cli è un nuovo progetto e non supporta tutte le librerie .net che ha le proprie librerie principali che sono diverse con .net framework.