CoreCLR e relazione Progetto mono dopo Microsoft open-sourced .NET.

Question

Qualcuno potrebbe spiegarmi qual è la relazione corrente tra Mono e lo stack .NET portatile open source/Linux (CoreCLR, CoreFX, Roslyn, ASP.NET) recentemente messo a disposizione da Microsoft?

È piuttosto chiaro che questi progetti si sovrappongono quindi sono curioso di sapere quale sia la tabella di marcia per entrambi - Mono sostituirà in qualche modo il proprio componente con quelli nuovi di Microsoft, o coesisteranno in qualche modo?

Answer 1

From a Mono contributor on reddit:

penso che le persone hanno la mentalità sbagliata su tutta questa situazione Mono/CoreCLR. Perché una VM deve diventare open source e essere portata su altri sistemi operativi significa che un'altra VM non può esistere? Sarebbe come dire che ci dovrebbe essere solo una implementazione Python, o una JVM. Questa non è una buona cosa. La competizione è salutare.

Mono ha molte caratteristiche che CoreCLR non possiede: LLVM, full AOT, NaCl, tasklet, cross-VM GC bridge, vari moduli di profiler, ecc. Anche il tempo di avvio di Mono e il footprint di memoria di runtime sono ottimizzati per piattaforme/dispositivi che CoreCLR non è (almeno attualmente) di targeting. OTOH, CoreCLR ha un GC più maturo e generalmente una migliore generazione del codice (quindi il tempo di avvio più lento).Le due VM sono brave in cose diverse, e non c'è motivo per cui entrambe non possano esistere.

Non è che insistiamo nel mantenere il nostro codice. Siamo lieti di passare a CoreCLR/codice sorgente di riferimento quando ci sono chiari vantaggi nel farlo (meno manutenzione, più corretto, ancora abbastanza portatile). Abbiamo importato tonnellate di codice sorgente di riferimento già, e stiamo anche l'importazione di alcune parti del CoreCLR VM:
https://github.com/mono/mono/blob/master/mono/metadata/decimal-ms.c
https://github.com/mono/mono/blob/master/mono/metadata/threadpool-ms.c

From a .NET member on HN:

Le librerie Framework Core (CoreFX) - https://github.com/dotnet/corefx - sono utilizzati per tutti gli scenari .NET Core, incluso .NET Native (UWP). Ciò significa che il tuo codice fa la stessa cosa in tutti questi diversi ambienti, poiché utilizza le stesse librerie framework sottostanti. Separatamente, il progetto Mono sta prendendo molto dello stesso codice, il che significa che il framework di base per le app Xamarin sta diventando anche più compatibile con CoreFX. Yeahh! Speriamo di renderlo più formale in futuro. Parliamo spesso con @migueldeicaza di questo.

Fondamentalmente c'è molta condivisione di codice tra di loro e non mi sorprenderò se convergeranno in futuro. Ora che da quando MS ha acquisito Xamarin non penso che saranno terribilmente interessati a mantenere due runtime.

Answer 2

Penso che la risposta potrebbe evolversi nel tempo ma capisco che Microsoft e il Progetto Mono lavoreranno insieme, o almeno Microsoft consentirà a Mono di lavorare con il loro stack .Net open source.

http://www.mono-project.com/docs/about-mono/releases/4.0.0/

Mentre Microsoft sta lavorando per nucleo NET: una versione ridistribuibile e ri-immaginato di NET, il progetto rimane un work in progress. Mono a questo punto continua a fornire un'API che tiene traccia della versione desktop/server .NET.

Ciò significa che la maggior parte del codice che abbiamo integrato proviene dalla goccia ReferenceSource. In futuro, forniremo un "Mono Core" sulla stessa linea di .NET Core per consentire l'utilizzo del runtime Mono con il nuovo sistema di distribuzione di librerie che viene sviluppato con CoreFX.

E Miguel de Icaza (CTO e co-fondatore di Xamarin e fondatore del progetto Mono) ha commentato che:

http://tirania.org/blog/archive/2014/Nov-12.html

.NET è in fase di open source sotto la licenza MIT . Non solo il codice viene rilasciato con questa licenza molto permissiva, ma Microsoft sta promettendo un brevetto per garantire che .NET ottenga l'adozione che merita.

E per i due progetti in particolare:

Mono sarà in grado di utilizzare tanto una che vuole da questo progetto.

...

Microsoft ha dichiarato che al momento non ha intenzione di prendere le patch di nuovo o di impegnarsi in uno stile open source comunità di sviluppo integrale del presente codice di base, come i requisiti per la compatibilità con Windows sono molto elevati .