.NET Core vs Mono


257

Qual è la differenza tra .NET Core e Mono?

Ho trovato una dichiarazione sul sito ufficiale che diceva: "Il codice scritto per esso è anche portatile attraverso stack di applicazioni, come Mono."

Il mio obiettivo è utilizzare C #, LINQ, EF7 e Visual Studio per creare un sito Web che può essere eseguito / ospitato su Linux.

Qualcuno mi ha detto che voleva che fosse "in Mono", ma non so cosa significhi. So che voglio usare .NET Core 1.0 con le tecnologie che ho elencato sopra. Ha anche detto che voleva usare "Fast CGI". Non so nemmeno cosa significhi.

Potete aiutarmi a dare un senso a tutti questi termini e se le mie aspettative sono realistiche?


2
Non sono sicuro che .NET Core sia supportato su Mono (o se ha bisogno anche di mono, ora?), Almeno non del tutto. Dai un'occhiata qui per ciò che supporta Mono. FastCGI è semplicemente il server che esegue il codice ASP.NET con mono. Ora, detto questo, c'è un motivo particolare per eseguirlo su Linux? Se non c'è alcun motivo urgente (a parte il solo voler usare Linux), probabilmente è meglio prendere un server Windows per eseguire il codice .NET, almeno per il momento.
Rob

Sì, il server su cui sarà ospitato sarà sicuramente Linux. Non è un'opzione per utilizzare Windows Server. Hai detto che non sei sicuro che .NET core sia supportato su Mono. ma non so cos'è Mono. Quale sarebbe un argomento da utilizzare .Net Core invece di Mono?
Captainlonate,

12
Per essere generici su cosa sia mono: è essenzialmente un'implementazione open source delle librerie .net (oltre a compilazioni ed interpreti). Ad esempio, quando scrivi Math.Pow(2, 3): i binari che contengono l'implementazione sono di origine chiusa e sono solo per Windows. Alcune persone hanno deciso che gli piaceva .NET abbastanza da volerlo per * nix. Quindi hanno scritto la loro versione dei file binari a sorgente chiuso. Quindi hanno scritto un compilatore e un interprete. Mono è essenzialmente una reimplementazione di tutto ciò che era precedentemente chiuso e scritto per essere eseguito su Windows / Linux / OSX.
Rob

1
Ho scritto un post sul blog l'anno scorso, blog.lextudio.com/2015/12/… Puoi usare uno dei due, ma .NET Core sarà il futuro più luminoso.
Lex Li,

3
La parola "Core" in ".NET Core" potrebbe essere la fonte del malinteso. Dai ai tuoi bambini nomi propri!
Too Fat Man No Neck

Risposte:


256

Necromancing.
Fornire una risposta effettiva.

Qual è la differenza tra .Net Core e Mono?

.NET Core ora è ufficialmente il futuro di .NET. È iniziato per la maggior parte con una riscrittura del framework ASP.NET MVC e delle applicazioni console, che ovviamente include applicazioni server. (Poiché è completo di Turing e supporta l'interoperabilità con le DLL C, è possibile, se lo si desidera assolutamente, anche scrivere le proprie applicazioni desktop con esso, ad esempio tramite librerie di terze parti come Avalonia, che era un po 'molto semplice al momento in cui l'ho scritto per la prima volta, il che significava che eri praticamente limitato al Web o al server.) Nel tempo, molte API sono state aggiunte a .NET Core, tanto che dopo la versione 3.1, .NET Core passerà alla versione 5.0, sarà noto come .NET 5.0 senza "Core", e questo sarà il futuro di .NET Framework. Quello che era il completo .NET Framework rimarrà in modalità di manutenzione come Full .NET Framework 4.8.x per alcuni decenni, fino a quando non morirà (forse ci saranno ancora alcuni aggiornamenti, ma ne dubito). In altre parole, .NET Core è il futuro di .NET e Full .NET Framework seguirà la strada di Dodo / Silverlight / WindowsPhone .

Il punto principale di .NET Core, oltre al supporto multipiattaforma, è migliorare le prestazioni e abilitare la "compilazione nativa" / distribuzione autonoma (quindi non è necessario che .NET framework / VM sia installato sul computer di destinazione .
Da un lato, questo significa docker.io supporto su Linux, e dall'altro, la distribuzione self-contained è utile in "cloud computing", da allora si può semplicemente utilizzare qualsiasi versione del framework dotnet-CORE che ti piace, e non devi preoccuparti di quale versione (s) del framework .NET ha effettivamente installato sysadmin.

Mentre il runtime .NET Core supporta più sistemi operativi e processori, l'SDK è una storia diversa. E mentre l'SDK supporta più sistemi operativi, il supporto ARM per l'SDK è / era ancora in corso di elaborazione. .NET Core è supportato da Microsoft. Dotnet-Core non è stato fornito con WinForms o WPF o simili.

  • A partire dalla versione 3.0, WinForms e WPF sono supportati anche da .NET Core, ma solo su Windows e solo da C #. Non da VB.NET (supporto VB.NET previsto per v5 nel 2020). E non esiste Forms Designer in .NET Core: viene fornito con un aggiornamento di Visual Studio in un secondo momento, in un momento non specificato.
  • I Webform non sono ancora supportati da .NET Core e non ci sono piani per supportarli, mai ( Blazor è il nuovo figlio in città per quello).
  • .NET Core include anche System.Runtime, che sostituisce mscorelib.
  • Spesso, .NET Core si confonde con NetStandard , che è un po 'un involucro attorno a System.Runtime / mscorelib (e alcuni altri), che consente di scrivere librerie destinate a .NET Core, Full .NET Framework e Xamarin (iOS / Android), tutti allo stesso tempo.
  • .NET Core SDK non funziona / non ha funzionato su ARM, almeno non l'ultima volta che ho verificato.

"The Mono Project" è molto più vecchio di .NET Core.
Mono è spagnolo e significa scimmia e, come osservazione laterale, il nome non ha nulla a che fare con la mononucleosi (suggerimento: è possibile ottenere un elenco di personale su http://primates.ximian.com /).
Mono è stato avviato nel 2005 da Miguel de Icaza (il ragazzo che ha avviato GNOME - e pochi altri) come implementazione di .NET Framework per Linux (Ximian / SuSe / Novell). Mono include Web-Form, Winforms, MVC, Olive e un IDE chiamato MonoDevelop(noto anche come Xamarin Studio o Visual Studio Mac). Fondamentalmente l'equivalente di (OpenJDK) JVM e (OpenJDK) JDK / JRE (al contrario di SUN / Oracle JDK). Puoi usarlo per far funzionare le applicazioni ASP.NET-WebForms + WinForms + ASP.NET-MVC su Linux.

Mono è supportato da Xamarin (il nome della nuova società di quello che era Ximian, quando si concentravano sul mercato Mobile, anziché sul mercato Linux), e non da Microsoft.
(dal momento che Xamarin è stato acquistato da Microsoft, tecnicamente [ma non culturalmente] Microsoft.)
Solitamente otterrai le tue cose C # da compilare su mono, ma non su VB.NET.
Mono manca alcune funzionalità avanzate, come WSE / WCF e WebParts.
Molte delle implementazioni Mono sono incomplete (ad es. Not NotplementedException nella crittografia ECDSA), buggy (ad es. ODBC / ADO.NET con Firebird), si comportano in modo diverso rispetto a .NET (ad esempio serializzazione XML) o altrimenti instabile (ASP.NET MVC) e inaccettabilmente lento (Regex). Sul lato positivo, la toolchain Mono funziona anche su ARM.

Per quanto riguarda .NET Core, quando dicono multipiattaforma, non aspettarti che multipiattaforma significhi che potresti effettivamente apt-get install .NET Core su ARM-Linux, come puoi fare con ElasticSearch. Dovrai compilare l'intero framework dalla fonte.
Cioè, se hai quello spazio (ad esempio su un Chromebook, che ha un HD totale da 16 a 32 GB).
Aveva anche problemi di incompatibilità con OpenSSL 1.1 e libcurl.
Quelli sono stati corretti nell'ultima versione di .NET Core Versione 2.2.
Questo per quanto riguarda multipiattaforma.

Ho trovato una dichiarazione sul sito ufficiale che diceva: "Il codice scritto per esso è anche portatile attraverso stack di applicazioni, come Mono".

Fintanto che quel codice non si basa su chiamate WinAPI, Windows-dll-pinvokes, COM-Components, un file system senza distinzione tra maiuscole e minuscole, la codifica di sistema predefinita (codepage) e non ha problemi di separazione delle directory, questo è corretta. Tuttavia, il codice .NET Core viene eseguito su .NET Core e non su Mono. Quindi mescolare i due sarà difficile. E poiché Mono è piuttosto instabile e lento (per applicazioni web), non lo consiglierei comunque. Prova l'elaborazione delle immagini su .NET core, ad esempio WebP o spostando GIF o multipage-tiff o scrivendo testo su un'immagine, rimarrai sgradevolmente sorpreso.

Nota: a
partire da .NET Core 2.0, esiste System.Drawing.Common (NuGet), che contiene la maggior parte delle funzionalità di System.Drawing. Dovrebbe essere più o meno completo in .NET-Core 2.1. Tuttavia, System.Drawing.Common usa GDI + e pertanto non funzionerà su Azure (le librerie System.Drawing sono disponibili nel servizio cloud di Azure [praticamente solo una macchina virtuale], ma non nell'applicazione Web di Azure [sostanzialmente hosting condiviso?])
Quindi lontano, System.Drawing.Common funziona bene su Linux / Mac, ma ha problemi su iOS / Android - se funziona, lì.
Prima di .NET Core 2.0, ovvero a metà febbraio 2017, è possibile utilizzare SkiaSharp per l'imaging (esempio) (è ancora possibile).
Dopo .net-core 2.0, noterai che SixLabors ImageSharpè la strada da percorrere, poiché System.Drawing non è necessariamente sicuro e presenta molte perdite di memoria potenziali o reali, motivo per cui non si dovrebbe usare GDI nelle applicazioni web; Nota che SkiaSharp è molto più veloce di ImageSharp, perché utilizza librerie native (che possono anche essere uno svantaggio). Inoltre, nota che mentre GDI + funziona su Linux e Mac, ciò non significa che funzioni su iOS / Android.

Il codice non scritto per .NET (non Core) non è portabile su .NET Core.
Vale a dire, se desideri che una libreria C # non GPL come PDFSharp crei documenti PDF (molto comune), sei sfortunato(al momento)( non più ). Non importa il controllo di ReportViewer, che utilizza Windows-pInvokes (per crittografare, creare documenti mcdf tramite COM e ottenere caratteri, caratteri, crenatura, informazioni sull'incorporamento dei caratteri, misurare stringhe e interrompere la linea e per disegnare effettivamente tiff di qualità accettabile) e non funziona nemmeno su Mono su Linux
( ci sto lavorando ).

Inoltre, il codice scritto in .NET Core non è portabile su Mono, poiché a Mono mancano le librerie di runtime .NET Core (finora).

Il mio obiettivo è utilizzare C #, LINQ, EF7, Visual Studio per creare un sito Web che può essere eseguito / ospitato in Linux.

EF in qualsiasi versione che ho provato finora è stato così dannatamente lento (anche su cose così semplici come un tavolo con un join sinistro), non lo consiglierei mai, nemmeno su Windows.
In particolare, non consiglierei EF se si dispone di un database con vincoli univoci o colonne varbinary / filestream / hierarchyid. (Neanche per l'aggiornamento dello schema.)
E nemmeno in una situazione in cui le prestazioni del DB sono fondamentali (diciamo da 10+ a 100+ utenti simultanei).
Inoltre, eseguire un sito Web / un'applicazione Web su Linux prima o poi significa che dovrai eseguirne il debug.
Non è disponibile il supporto per il debug di .NET Core su Linux.(Non più, ma richiede JetBrains Rider.)
MonoDevelop non supporta (ancora) il debug di progetti .NET Core.
Se hai problemi, sei da solo. Dovrai utilizzare una registrazione estesa.
Fai attenzione, tieni presente che una registrazione estesa riempirà il tuo disco in pochissimo tempo, in particolare se il tuo programma entra in un ciclo infinito o in una ricorsione.
Ciò è particolarmente pericoloso se la tua app web funziona come root, perché il login richiede logfile-space - se non c'è più spazio libero, non potrai più accedere.
(Normalmente, circa il 5% dello spazio su disco è riservato all'utente root [aka amministratore su Windows], quindi almeno l'amministratore può ancora accedere se il disco è quasi pieno. Ma se le applicazioni vengono eseguite come root, tale restrizione non si applica per il loro utilizzo del disco, e quindi i loro file di log possono usare il 100% dello spazio libero rimanente, quindi nemmeno l'amministratore può accedere più.)
Pertanto è meglio non crittografare quel disco, vale a dire, se si valuta i propri dati / sistema.

Qualcuno mi ha detto che voleva che fosse "in Mono", ma non so cosa significhi.

Significa che non vuole usare .NET Core, o vuole semplicemente usare C # su Linux / Mac. Suppongo che voglia solo usare C # per un'app Web su Linux. .NET Core è la strada da percorrere, se vuoi assolutamente farlo in C #. Non andare con "Mono proprio"; in superficie, sembrerebbe funzionare all'inizio, ma credetemi ve ne pentirete perché ASP.NET MVC di Mono non è stabile quando il server funziona a lungo (più di 1 giorno) - ora siete stati avvisati. Vedi anche i riferimenti "non completati" quando si misurano le prestazioni Mono sui benchmark techempower.

fortune

So che voglio usare il framework .Net Core 1.0 con le tecnologie che ho elencato sopra. Ha anche detto che voleva usare "fast cgi". Non so nemmeno cosa significhi.

Vuol dire che vuole usare un WebServer ad alte prestazioni completo come nginx (Engine-X), probabilmente Apache.
Quindi può eseguire mono / dotnetCore con hosting basato su nome virtuale (più nomi di dominio sullo stesso IP) e / o bilanciamento del carico. Può anche eseguire altri siti Web con altre tecnologie, senza richiedere un numero di porta diverso sul server Web. Significa che il tuo sito Web viene eseguito su un server fastcgi e nginx inoltra tutte le richieste Web per un determinato dominio tramite il protocollo fastcgi a quel server. Significa anche che il tuo sito Web viene eseguito in una pipeline fastcgi e devi fare attenzione a ciò che fai, ad esempio non puoi utilizzare HTTP 1.1 durante la trasmissione di file.
Altrimenti, i file verranno confusi nella destinazione.
Vedi anche qui e qui .

Per concludere:
.NET Core al momento (2016-09-28) non è realmente portatile, né è realmente multipiattaforma (in particolare gli strumenti di debug).
Né la compilazione nativa è facile, specialmente per ARM.
E per me, inoltre, non sembra che il suo sviluppo sia "veramente finito", ancora.
Ad esempio, System.Data.DataTable / DataAdaper.Update non è presente ... (non più con .NET Core 2.0)
Insieme alle interfacce System.Data.Common.IDB *.(non più con .NET Core 1.1)
se ci fosse mai stata una classe che viene spesso usata, DataTable / DataAdapter lo sarebbe ...
Inoltre, il programma di installazione Linux (.deb) fallisce, almeno sulla mia macchina, e io ' Sono sicuro che non sono l'unico ad avere questo problema.
Debug, forse con Visual Studio Code, se puoi costruirlo su ARM (sono riuscito a farlo - NON seguire il post sul blog di Scott Hanselman se lo fai - c'è un howto nella wiki di VS-Code su github), perché non offrono l'eseguibile.
Anche Yeoman fallisce. (Immagino che abbia qualcosa a che fare con la versione nodejs che hai installato - VS Code richiede una versione, Yeoman un'altra ... ma dovrebbe funzionare sullo stesso computer. Pretty Lame
Non importa che dovrebbe funzionare sulla versione del nodo spedita per impostazione predefinita sul sistema operativo.
Non importa che in primo luogo non ci dovrebbe essere dipendenza da NodeJS.
Anche il server kestell è in fase di elaborazione.
E a giudicare dalla mia esperienza con il mono-progetto, dubito fortemente che abbiano mai testato .NET Core su FastCGI o che abbiano idea di cosa significhi il supporto FastCGI per il loro framework, per non parlare del fatto che lo hanno testato per assicurarsi che "tutto funzioni ". In effetti, ho appena provato a creare un'applicazione fastcgi con .NET Core e ho appena realizzato che non esiste una libreria FastCGI per .NET Core "RTM" ...

Quindi, quando eseguirai .NET Core "RTM" dietro nginx, puoi farlo solo inviando richieste a Kestrell (quel web server derivato dal nodo semi-finito JS) - al momento non c'è supporto fastcgi in .NET Core "RTM", AFAIK. Dal momento che non esiste una libreria fastnet core .net e nessun campione, è anche altamente improbabile che qualcuno abbia fatto dei test sul framework per assicurarsi che fastcgi funzioni come previsto.

Metto anche in dubbio la performance.
Nel (preliminare) techempower-benchmark (round 13) , aspnetcore-linux si posiziona al 25% rispetto alle migliori prestazioni, mentre framework comparabili come Go (golang) si posizionano al 96,9% delle massime prestazioni (e cioè quando si restituisce testo in chiaro senza file -solo accesso al sistema). .NET Core fa un po 'meglio sulla serializzazione JSON, ma non sembra neanche avvincente (vai raggiunge il 98,5% del picco, .NET core 65%). Detto questo, non può essere peggio del "mono proprio".

Inoltre, poiché è ancora relativamente nuovo, non tutte le principali librerie sono state portate (ancora), e dubito che alcune di esse saranno mai portate.
Il supporto per l'imaging è anche discutibile nella migliore delle ipotesi.
Per qualsiasi crittografia, utilizzare invece BouncyCastle.

Potete aiutarmi a dare un senso a tutti questi termini e se le mie aspettative sono realistiche ?

Spero di averti aiutato a dare più senso a tutti questi termini.
Per quanto riguarda le tue aspettative: lo
sviluppo di un'applicazione Linux senza sapere nulla di Linux è in primo luogo un'idea davvero stupida, ed è anche destinata a fallire in un modo orribile in un modo o nell'altro. Detto questo, poiché Linux non ha costi di licenza, in linea di principio è una buona idea, MA SOLO SE LO SAPI COSA FACCIAI.
Lo sviluppo di un'applicazione per una piattaforma su cui non è possibile eseguire il debug dell'applicazione è un'altra idea davvero negativa.
Sviluppare per FastCGI senza sapere quali conseguenze ci sono è un'altra idea davvero cattiva.

Fare tutte queste cose su una piattaforma "sperimentale" senza alcuna conoscenza delle specifiche di quella piattaforma e senza supporto per il debug è un suicidio, se il tuo progetto è più di una semplice homepage personale. D'altra parte, immagino che farlo con la tua home page personale a fini di apprendimento sarebbe probabilmente un'esperienza molto positiva, quindi conoscerai quale sia il framework e quali sono i problemi non framework.
Ad esempio, è possibile (programmaticamente) eseguire il loop-loop di un fat32 insensibile al maiuscolo / minuscolo, hfs o JFS per la propria applicazione, per aggirare i problemi di distinzione tra maiuscole e minuscole (montaggio in loop non consigliato in produzione).

Riassumendo
Al momento (28-09-2016), starei lontano da .NET Core (per l'utilizzo in produzione). Forse tra uno o due anni, puoi dare un'altra occhiata, ma probabilmente non prima.
Se si sviluppa un nuovo progetto Web, avviarlo in .NET Core, non in mono.

Se si desidera un framework che funziona su Linux (x86 / AMD64 / ARMhf) e Windows e Mac, che non ha dipendenze, ovvero solo collegamenti statici e nessuna dipendenza da .NET, Java o Windows, utilizzare invece Golang. È più maturo e le sue prestazioni sono comprovate (Baidu lo usa con 1 milione di utenti simultanei) e Golang ha un'impronta di memoria significativamente inferiore. Anche Golang è nei repository, il .deb si installa senza problemi, il codice sorgente viene compilato - senza richiedere modifiche - e Golang (nel frattempo) ha il supporto per il debug con delve e JetBrainsGogland su Linux (e Windows e Mac). Anche il processo di compilazione (e il runtime) di Golang non dipendono da NodeJS, che è un altro vantaggio.

Per quanto riguarda il mono, stai lontano da esso.
È incredibile quanto sia arrivato il mono, ma sfortunatamente non sostituisce i suoi problemi di prestazioni / scalabilità e stabilità per le applicazioni di produzione.
Inoltre, lo sviluppo mono è piuttosto morto, in gran parte sviluppano solo le parti relative ad Android e iOS, perché è lì che Xamarin guadagna.
Non aspettarti che lo sviluppo Web sia un cittadino Xamarin / mono di prima classe.
.NET Core potrebbe valerne la pena, se si avvia un nuovo progetto, ma per i progetti di moduli Web di grandi dimensioni esistenti, il porting è in gran parte fuori questione, le modifiche richieste sono enormi. Se si dispone di un progetto MVC, la quantità di modifiche potrebbe essere gestibile, se la progettazione dell'applicazione originale fosse sana, cosa che non accade nella maggior parte delle cosiddette applicazioni "storicamente sviluppate".

Aggiornamento di dicembre 2016: la
compilazione nativa è stata rimossa dall'anteprima di .NET Core, poiché non è ancora pronta ...

Sembra che siano notevolmente migliorati sul benchmark dei file di testo non elaborati, ma d'altra parte è diventato piuttosto difettoso. Inoltre, si è ulteriormente deteriorato nei benchmark JSON. Curioso anche che il framework delle entità sia più veloce per gli aggiornamenti rispetto a Dapper, sebbene entrambi con una lentezza record. È molto improbabile che ciò sia vero. Sembra che ci siano ancora molti altri bug da cacciare.

Inoltre, sembra esserci sollievo in arrivo sul fronte IDE di Linux.
JetBrains ha rilasciato "Project Rider", un'anteprima di accesso anticipato di un IDE Core C # /. NET per Linux (e Mac e Windows), in grado di gestire i file di progetto di Visual Studio. Finalmente un IDE C # utilizzabile e non lento come l'inferno.

Conclusione: .NET Core è ancora un software di qualità pre-release mentre marciamo nel 2017. Porta le tue librerie, ma stai lontano da esso per l'uso in produzione, fino a quando la qualità del framework non si stabilizza.
E tieni d'occhio Project Rider.

buggy .net core

Aggiornamento 2017
Ho migrato la mia home page di mio fratello su .NET Core per ora.
Finora, il runtime su Linux sembra essere abbastanza stabile (almeno per i piccoli progetti) - è sopravvissuto facilmente a un test di carico - Mono non lo ha mai fatto.
Inoltre, sembra che abbia confuso .NET-Core-native e .NET-Core-self-contenute-deploy. La distribuzione autonoma funziona, ma è un po 'poco documentata, anche se è super facile (gli strumenti di compilazione / pubblicazione sono un po' instabili, tuttavia - se si riscontra "Richiesto numero positivo. - Build FAILED." - Eseguire di nuovo lo stesso comando, e funziona).

Puoi correre

dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64

Nota: secondo .NET Core 3, è possibile pubblicare tutto ciò che è minimizzato in un singolo file :

dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true

Tuttavia, a differenza di go, non è un eseguibile collegato staticamente, ma un file zip autoestraente, quindi durante la distribuzione, potresti riscontrare problemi, specialmente se la directory temporanea è bloccata da criteri di gruppo o da altri problemi . Funziona bene per un programma ciao-mondo, però. E se non si minimizza, la dimensione dell'eseguibile avrà un clock di circa 100 MB.

E ottieni un file .exe autonomo (nella directory di pubblicazione), che puoi spostare su un computer Windows 8.1 senza .NET framework installato e lasciarlo funzionare. Bello. È qui che dotNET-Core inizia a diventare interessante. (attenzione alle lacune, SkiaSharp non funziona su Windows 8.1 / Windows Server 2012 R2, [ancora] - l'ecosistema deve recuperare prima - ma è interessante notare che Skia -dll-load-fail non va in crash l'intero server / applicazione - quindi tutto il resto funziona)

(Nota: a SkiaSharp su Windows 8.1 mancano i file di runtime VC appropriati - msvcp140.dll e vcruntime140.dll. Copiarli nella directory di pubblicazione e Skia funzionerà su Windows 8.1.)

Aggiornamento di agosto 2017
rilasciato .NET Core 2.0.
Fai attenzione: vengono fornite (enormi modifiche) all'autenticazione ...
L'aspetto positivo è che ha riportato le classi DataTable / DataAdaper / DataSet e molte altre.
Realized .NET Core manca ancora del supporto per Apache SparkSQL, perché Mobius non è ancora stato portato. È un male, perché non significa supporto SparkSQL per il mio cluster Cassandra IoT, quindi nessun join ...
Supporto ARM sperimentale (solo runtime, non SDK - peccato per devwork sul mio Chromebook - in attesa di 2.1 o 3.0).
PdfSharp è ora trasferito sperimentalmente su .NET Core.
JetBrains Riderlasciato EAP. Ora puoi usarlo per sviluppare ed eseguire il debug di .NET Core su Linux, sebbene finora solo .NET Core 1.1 fino a quando l'aggiornamento per il supporto di .NET Core 2.0 non sarà attivo.

Aggiornamento di Maggio
Core .NET Core 2.1 imminente. Forse questo risolverà l'autenticazione NTLM su Linux (l'autenticazione NTLM non funziona su Linux {e possibilmente Mac} in .NET-Core 2.0 con più intestazioni di autenticazione, come la negoziazione, comunemente inviate con ms-exchange e apparentemente sono risolto solo in v2.1, nessuna versione bugfix per 2.0).
Ma non sto installando le versioni di anteprima sul mio computer. Quindi aspetto.
Si dice anche che v2.1 riduca notevolmente i tempi di compilazione. Sarebbe bello.

Inoltre, tieni presente che su Linux, .NET Core è solo a 64 bit !
Non esiste alcuna versione x86-32 di .NET Core su Linux .
E la porta ARM è solo ARM-32. Nessun ARM-64, ancora.
E su ARM, tu (al momento) hai solo il runtime, non il dotnet-SDK.

E un'altra cosa:
poiché .NET-Core utilizza OpenSSL 1.0, .NET Core su Linux non funziona su Arch Linux e per derivazione non su Manjaro (la distribuzione Linux più popolare di gran lunga a questo punto nel tempo), perché Arch Linux utilizza OpenSSL 1.1. Quindi se stai usando Arch Linux, sei sfortunato (anche con Gentoo).

Modificare:

L'ultima versione di .NET Core 2.2+ supporta OpenSSL 1.1. Quindi puoi usarlo su Arch o (k) Ubuntu 19.04+. Potrebbe essere necessario utilizzare lo script di installazione .NET-Core , poiché non ci sono ancora pacchetti.

Sul lato positivo, le prestazioni sono decisamente migliorate: fortune

testo in chiaro

.NET Core 3:
si dice che .NET-Core v 3.0 porti WinForms e WPF a .NET-Core.
Tuttavia, mentre WinForms e WPF saranno .NET Core, WinForms e WPF in .NET Core funzioneranno solo su Windows, poiché WinForms / WPF utilizzerà l'API di Windows.

Nota:
.NET Core 3.0 è ora disponibile (RTM) e sono supportati WinForms e WPF, ma solo per C # (su Windows). Non esiste WinForms-Core-Designer . Alla fine il designer verrà fornito con un aggiornamento di Visual Studio. Il supporto di WinForms per VB.NET non è supportato , ma è previsto per .NET 5.0 da qualche parte nel 2020 .

PS:

echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1 

Se l'hai usato su Windows, probabilmente non l'hai mai visto:

Gli strumenti .NET Core raccolgono dati di utilizzo per migliorare la tua esperienza.
I dati sono anonimi e non includono argomenti della riga di comando.
I dati vengono raccolti da Microsoft e condivisi con la community.
Puoi disattivare la telemetria impostando una variabile di ambiente DOTNET_CLI_TELEMETRY_OPTOUT su 1 usando la tua shell preferita.
Puoi leggere di più sugli strumenti di telemetria di .NET Core @ https://aka.ms/dotnet-cli-telemetry .

Ho pensato di menzionare che penso che il monodevelop (noto anche come Xamarin Studio, Mono IDE o Visual Studio Mac come viene ora chiamato su Mac) si sia evoluto abbastanza bene e, nel frattempo, sia ampiamente utilizzabile.
Tuttavia, JetBrains Rider (EAP 2018 a questo punto nel tempo) è sicuramente molto più bello e affidabile (e il decompilatore incluso è più sicuro per la vita), vale a dire se sviluppi .NET-Core su Linux o Mac. MonoDevelop non supporta Debug-StepThrough su Linux in .NET Core, tuttavia, poiché MS non concede in licenza la loro DLL API di debug (tranne VisualStudio Mac ...). Tuttavia, è possibile utilizzare il debugger Samsung per .NET Core tramite l' estensione di debug .NET Core per Samsung Debugger per MonoDevelop

Disclaimer:
non uso il Mac, quindi non posso dire se ciò che ho scritto qui si applica anche al Mac basato su FreeBSD-Unix. Mi riferisco alla versione Linux (Debian / Ubuntu / Mint) di JetBrains Rider, mono, MonoDevelop / VisualStudioMac / XamarinStudio e .NET-Core. Inoltre, Apple sta pensando di passare da processori Intel a processori basati su ARM (ARM-64?) Autocostruiti, quindi molto di ciò che si applica al Mac in questo momento potrebbe non applicarsi al Mac in futuro (2020+).

Inoltre, quando scrivo "mono è piuttosto instabile e lento", l'instabile si riferisce alle applicazioni WinFroms e WebForms, in particolare l'esecuzione di applicazioni Web tramite fastcgi o con XSP (sulla versione 4.x di mono), nonché serializzazione XML -handling peculiarità, e il piuttosto lento si riferisce a WinForms, ed espressioni regolari in particolare (ASP.NET-MVC usa anche espressioni regolari per il routing).

Quando scrivo della mia esperienza su mono 2.x, 3.x e 4.x, ciò non significa necessariamente che questi problemi non siano stati risolti da ora, o dal momento in cui stai leggendo questo, né che se lo sono risolto ora, che non ci può essere una regressione in seguito che reintroduca uno di questi bug / funzionalità. Ciò non significa nemmeno che se si incorpora il mono-runtime, si otterranno gli stessi risultati di quando si utilizza il mono-runtime del sistema (dev). Inoltre, ciò non significa che l'incorporamento del mono-runtime (ovunque) sia necessariamente gratuito.

Tutto ciò che non significa necessariamente che mono sia inadatto per iOS o Android, o che abbia gli stessi problemi lì. Non uso il mono su Android o IOS, quindi non sono in grado di dire nulla su stabilità, usabilità, costi e prestazioni su queste piattaforme. Ovviamente, se usi .NET su Android, hai anche altre considerazioni sui costi da fare, come la ponderazione dei costi di xamarin rispetto ai costi e ai tempi per il porting del codice esistente su Java. Si sente mono su Android e IOS dovrebbe essere abbastanza buono. Prendilo con un granello di sale. Per uno, non aspettarti che la codifica del sistema predefinito sia la stessa su Android / iOS rispetto a Windows, e non aspettarti che il filesystem Android non faccia distinzione tra maiuscole e minuscole, e non aspettarti che siano presenti caratteri Windows .


6
@Tseng: Ah sì, è bs? Hai visto Winforms Core o WPF Core allora? Sì, tecnicamente è una porta multipiattaforma di .NET Framework e non ha nulla a che fare con MVC. Ma le applicazioni Web (ASP.NET MVC) e le applicazioni console sono l'unica cosa che puoi fare con .NET Core al momento ... E sì MVC, perché non è WebForms Core. Questo è quello che è al momento, chiaro e semplice. Ma è vero, non è necessario utilizzare MVC nelle applicazioni Web solo perché si utilizza .NET Core. È inoltre possibile creare un'applicazione Web senza MVC. Ma SEO-saggio, avrebbe poco senso farlo.
Stefan Steiger,

16
Dire che Mono è "piuttosto instabile e lento" è infondato, se non addirittura sbagliato. Ma a parte questo, buone informazioni qui.
Noldorin,

65
Questa risposta è fortemente supponente e contiene molti riferimenti temporali.
Caleb,

23
Mi fa male vedere la prima frase di questa risposta molto votata essere così palesemente sbagliata. .NET Core non è una riscrittura del framework ASP.NET MVC.
JHo

6
@ stefan-steiger Anche dire "per la maggior parte" è completamente sbagliato e non è affatto lo scopo di .NET Core. "Ancora"? Invece di ripeterti, perché non lo cambi?
JHo

51

Nel mondo .NET ci sono due tipi di CLR, CLR "completi" e CLR Core, e queste sono cose abbastanza diverse.

Esistono due implementazioni CLR "complete", .NET CLR nativo di Microsoft (per Windows) e Mono CLR (che ha implementazioni per Windows, Linux e Unix (Mac OS X e FreeBSD)). Un CLR completo è esattamente questo: tutto, praticamente, di cui hai bisogno. Pertanto, i CLR "completi" tendono ad essere di grandi dimensioni.

I CLR core sono invece ridotti e molto più piccoli. Poiché sono solo un'implementazione di base, è improbabile che abbiano tutto ciò di cui hai bisogno, quindi con CLR Core aggiungi set di funzionalità al CLR che il tuo specifico prodotto software utilizza, usando NuGet. Ci sono implementazioni Core CLR per Windows, Linux (varie) e unix (Mac OS X e FreeBSD) nel mix. Microsoft ha o sta eseguendo il refactoring delle librerie di framework .NET anche per Core CLR, per renderle più portabili per il contesto principale. Data la presenza di mono sui sistemi operativi * nix, sarebbe una sorpresa se i CLR Core per * nix non includessero una base di codice mono, ma solo la comunità Mono e Microsoft potrebbero dirlo con certezza.

Inoltre, concordo con Nico sul fatto che i Core CLR sono nuovi - è in RC2 al momento penso. Non dipenderei ancora da questo per il codice di produzione.

Per rispondere alla tua domanda potresti consegnare il tuo sito su Linux usando Core CLR o Mono, e questi sono due modi diversi di farlo. Se vuoi una scommessa sicura in questo momento andrei con mono su Linux, quindi porta se vuoi in seguito, a Core.


2
Non andrei in Mono sapendo che non è un host permanente per la mia applicazione Web di produzione, soprattutto sapendo fin dall'inizio che mi costerebbe un ulteriore sforzo per portarlo su Core!
Panayiotis Hiripis,

@Panayiotis Hiripis: il debug delle deviazioni del comportamento mono, la gestione di web server mono instabili e le eccezioni non implementate, nonché i costi di interruzione in caso di crash di un mono-server instabile, ti costeranno, e probabilmente molto di più che il porting su .NET Nucleo. Se trascorro del tempo, preferirei di gran lunga passare il tempo ad aggiornare a versioni più recenti, più veloci e meglio progettate, piuttosto che correggere bug nelle vecchie versioni e mantenere un progetto con tecnologia legacy. Lo spostamento nel tempo ti farà risparmiare molto mal di testa in seguito. Ad un certo punto, dovrai comunque effettuare il porting ... TheSoonerYouMove, theLessYouPort più tardi.
Stefan Steiger,

Vale la pena notare la giostra che è collegata alla libreria mgt. Un tempo (non molto tempo fa!) Avevamo questa cosa chiamata inferno DLL. Si è verificato perché sono state rilasciate più copie di DLL (a volte versioni diverse) con applicazioni diverse. Java ha ancora questo problema. Microsoft ha provato a risolvere questo problema con il registro COM e successivamente .NET GAC. .NET Core lo reintroduce. Un giorno gireremo tutti in giro - dopo alcuni anni di confusione con dll e distribuzioni ci inventeremo di nuovo: un registro. NuGet, Maven, Gradle: questi sono solo modi di gestire piuttosto che risolvere.
muszeo,

13

Hai scelto non solo un percorso realistico, ma probabilmente uno dei migliori ecosistemi fortemente supportati (anche piattaforme X) dalla SM. Tuttavia dovresti considerare i seguenti punti:

  • Aggiornamento: il documento principale sullo standard della piattaforma .Net è qui: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
  • Aggiornamento: L'attuale Mono 4.4.1 non può eseguire l'ultimo Asp.Net core 1.0 RTM
  • Sebbene mono sia più completo, il suo futuro non è chiaro, perché MS lo possiede da alcuni mesi e per loro è un lavoro duplicato. Ma MS è decisamente impegnata in .Net Core e scommette molto su di esso.
  • Anche se .Net core viene rilasciato, l'ecosistema di terze parti non è del tutto presente. Ad esempio Nhibernate, Umbraco ecc. Non possono ancora funzionare su .Net core. Ma hanno un piano.
  • Ci sono alcune caratteristiche mancanti in .Net Core come System.Drawing, dovresti cercare librerie di terze parti
  • Dovresti usare nginx come front server con kestrelserver per le app asp.net, perché kestrelserver non è del tutto pronto per la produzione. Ad esempio HTTP / 2 non è implementato.

spero possa essere d'aiuto


Esiste un server jexusWeb chiamato che può ospitare il sito Web ASP.NET su Linux. Il mio sito personale è scritto con NancyFx (originariamente ASP.NET MVC4).
zwcloud,

Il secondo proiettile non è corretto. Attualmente sto spedendo un'applicazione ASP.NET Core 1.0 su Mono 4.4.0 e lo sono da circa beta8.
Ben Collins,

@zwcloud: perché non usare solo mono.xsp4 /4.5 con nginx? Non c'è davvero bisogno di jexus.
Stefan Steiger,

9

.Net Core non richiede mono nel senso del framework mono. .Net Core è un framework che funzionerà su più piattaforme tra cui Linux. Riferimento https://dotnet.github.io/ .

Tuttavia, il core .Net può usare il framework mono. Riferimento https://docs.asp.net/it/1.0.0-rc1/getting-started/choosing-the-right-dotnet.html (notare che document rc1 no rc2 disponibile), tuttavia mono non è un framework supportato da Microsoft e consiglierei di usare un framework supportato

Ora entità framework 7 viene ora chiamato Entity Framework Coreed è disponibile su più piattaforme tra cui Linux. Riferimento https://github.com/aspnet/EntityFramework (rivedere la road map)

Attualmente sto utilizzando entrambi questi framework, tuttavia è necessario comprendere che è ancora in fase di rilascio candidato ( RC2è la versione corrente) e nel corso dei candidati beta e rilascio ci sono stati cambiamenti enormi che di solito finiscono con il grattarsi la testa.

Ecco un tutorial su come installare MVC .Net Core in Linux. https://docs.asp.net/en/1.0.0-rc1/getting-started/installing-on-linux.html

Finalmente hai una scelta di Web Server (da cui suppongo che il fast cgiriferimento provenga) per ospitare la tua applicazione su Linux. Ecco un punto di riferimento per l'installazione in un ambiente Linux. https://docs.asp.net/en/1.0.0-rc1/publishing/linuxproduction.html

Mi rendo conto che questo post finisce per essere principalmente link alla documentazione, ma a questo punto quelle sono le tue migliori fonti di informazione. Il core .Net è ancora relativamente nuovo nella comunità .Net e fino al suo completo rilascio sarei titubante ad usarlo in un ambiente di prodotto date le ultime modifiche tra la versione rilasciata.


6
Microsoft ora possiede Xamarin, che sviluppa mono. Quindi sia mono che .Net Core sono supportati da MS.
Joel Coehoorn,

@JoelCoehoorn Capisco che Microsoft possiede Xamarin, ma non so di Xamarin possedere Mono. Tuttavia dai documenti docs.asp.net/en/1.0.0-rc1/getting-started/… afferma che non è supportato. Mono non è una piattaforma supportata da Microsoft; tuttavia, è un buon banco di prova per lo sviluppo multipiattaforma mentre matura il supporto multipiattaforma in .NET Core. Ora potrebbe essere sbagliato o obsoleto.
Nico,

@Nico ai tempi di RC1, Xamarin non era ancora stato acquisito da Microsoft. Puoi controllare la sequenza temporale per maggiori dettagli, corefx.strikingly.com
Lex Li

Mono non è supportato da Microsoft. MS supporta l'organizzazione Xamarin, ma non fanno nulla per il progetto Mono.
Kotauskas,

7

Questa domanda è particolarmente attuale perché ieri Microsoft ha annunciato ufficialmente la versione .NET Core 1.0 . Supponendo che Mono implementa la maggior parte delle librerie .NET standard, la differenza tra Mono e .NET core può essere vista attraverso la differenza tra .NET Framework e .NET Core:

  • API: .NET Core contiene molte delle stesse, ma meno , API di .NET Framework e con un factoring diverso (i nomi degli assembly sono
    diversi; la forma del tipo differisce nei casi chiave). Queste differenze
    attualmente richiedono in genere modifiche all'origine delle porte su .NET Core. .NET Core implementa l'API .NET Standard Library, che aumenterà per
    includere nel tempo più API BCL di .NET Framework.
  • Sottosistemi: .NET Core implementa un sottoinsieme dei sottosistemi in .NET Framework, con l'obiettivo di un
    modello di programmazione e implementazione più semplice . Ad esempio, Code Access Security (CAS) non è
    supportato, mentre la riflessione è supportata.

Se devi lanciare qualcosa rapidamente, vai con Mono perché è attualmente (giugno 2016) un prodotto più maturo, ma se stai costruendo un sito web a lungo termine, suggerirei .NET Core. È ufficialmente supportato da Microsoft e la differenza nelle API supportate probabilmente scomparirà presto, tenendo conto dello sforzo che Microsoft mette nello sviluppo di .NET Core.

Il mio obiettivo è utilizzare C #, LINQ, EF7, Visual Studio per creare un sito Web che può essere eseguito / ospitato in Linux.

Linq ed Entity Framework sono inclusi in .NET Core , quindi puoi fare un tentativo sicuro.


4

Per essere semplice

Mono è l'implementazione di terze parti del framework .Net per Linux / Android / iO

.Net Core è l'implementazione di Microsoft per lo stesso.

.Net Core è il futuro. e alla fine Mono sarà morto. Detto questo. Net Core non è abbastanza maturo. Stavo lottando per implementarlo con IBM Bluemix e successivamente ho abbandonato l'idea. Nel tempo (potrebbe essere 1-2 anni), dovrebbe essere migliore.


8
Questo non sembra essere il caso, ma piuttosto stai affermando ipotesi / opinioni Ufficialmente questo è il futuro del mono: mono-project.com/news/2016/11/29/mono-code-sharing Sembra che loro manterrà come .net core è solo che "core" un sottoinsieme dell'intero framework e mono sarà ancora l'unico framework multipiattaforma, sebbene con il codice standard .net possa essere condiviso con mono e l'intero framework .net (e altri Anche le implementazioni .net come .net core ovviamente)
pqsk,

-14

In breve:

Mono = compilatore per C #

Mono Develop = Compiler + IDE

.Net Core = compilatore ASP

Il caso attuale per .Net Core è web non appena adotta uno standard openform winform e una più ampia adozione del linguaggio, potrebbe finalmente essere la potenza di sviluppo di Microsoft Killer. Considerando la recente mossa delle licenze Java di Oracle, Microsoft ha un tempo enorme per brillare.


11
Quasi tutto in questa risposta è gravemente errato.
Douglas Gaskell,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.