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.
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.
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:
.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 .