it-swarm.com.de

.NET Core vs. Mono

Was ist der Unterschied zwischen .NET Core und Mono?

Ich habe auf der offiziellen Website eine Aussage gefunden, in der es heißt: "Code, der dafür geschrieben wurde, kann auch von Anwendungsstapeln wie Mono übertragen werden."

Mein Ziel ist es, mit C #, LINQ, EF7 und Visual Studio eine Website zu erstellen, die unter Linux ausgeführt/gehostet werden kann.

Jemand sagte mir, er wolle "in Mono" sein, aber ich weiß nicht, was das bedeutet. Ich weiß, dass ich den .NET Core 1.0 mit den oben aufgeführten Technologien verwenden möchte. Er sagte auch, dass er "schnelle CGI" verwenden wollte. Ich weiß auch nicht was das bedeutet.

Können Sie mir helfen, all diese Begriffe zu verstehen und ob meine Erwartungen realistisch sind?

189
Captainlonate

Nekromanzierung.
Eine tatsächliche Antwort geben.

Was ist der Unterschied zwischen .Net Core und Mono?

.NET Core ist zum größten Teil ein Umschreiben des ASP.NET MVC - Frameworks (und der Konsolenanwendungen), um Abhängigkeiten zu verringern, modularer zu gestalten und die Leistung zu steigern.

<edit>Console Applications: this includes server applications IMHO</edit>

Der Hauptpunkt besteht darin, die "native Kompilierung"/eigenständige Bereitstellung zu aktivieren (sodass .NET Framework/VM nicht auf dem Zielcomputer installiert sein muss.
Dies ist nützlich beim "Cloud-Computing", da Sie dann einfach jede beliebige Version des dotnet-CORE-Frameworks verwenden können und sich keine Gedanken darüber machen müssen, welche .NET-Version (en) Sie verwenden Framework, das der Sysadmin tatsächlich installiert hat.
. NET Core unterstützt auch mehrere Betriebssysteme als Diashow.
Es wird von Microsoft unterstützt.
Dotnet Core wird nicht mit Winforms oder WPF oder Ähnlichem geliefert.

Mono ist eine Implementierung von .NET Framework für Linux (einschließlich Web-Forms, Winforms, MVC). Grundsätzlich das Äquivalent von (OpenJDK) JVM und (OpenJDK) JDK/JRE (im Gegensatz zu Sun/Oracle JDK). Sie können es verwenden, um ASP.NET-WebForms + WinForms + ASP.NET-MVC-Anwendungen für Linux zu aktivieren.
Es wird von Xamarin und nicht von Microsoft unterstützt.
(da Xamarin von Microsoft gekauft wurde, ist das technisch, aber nicht wirklich, Microsoft.)
Normalerweise werden Sie Ihre C # -Dateien in Mono kompilieren lassen, nicht jedoch die VB.NET -Dateien.
Einige erweiterte Funktionen wie WSE/WCF und WebParts fehlen.
Viele der Implementierungen sind unvollständig (z. B. NotImplementedException in ECDSA-Verschlüsselung auslösen), fehlerhaft (z. B. ODBC/ADO.NET mit Firebird), verhalten sich anders als unter .NET (z. B. XML-Serialisierung) oder auf andere Weise instabil (ASP .NET MVC) und inakzeptabel langsam (Regex).

Erwarten Sie jedoch nicht, dass plattformübergreifend eine Installation von .NET Core unter ARM-Linux möglich ist, wie dies mit elasticsearch möglich ist. Sie müssen das gesamte Framwork aus dem Quellcode kompilieren.
Das heißt, wenn Sie über diesen Speicherplatz verfügen (z. B. auf einem Chromebook mit einer Gesamt-HD von 16 bis 32 GB).
Soviel zu plattformübergreifend.

Ich fand auf der offiziellen Website eine Aussage, die besagte: "Der dafür geschriebene Code ist auch auf Anwendungsstacks wie Mono übertragbar.".

Solange dieser Code nicht auf WinAPI-Aufrufen, Windows-DLL-Pinvokes, COM-Komponenten, einem Dateisystem ohne Berücksichtigung der Groß- und Kleinschreibung und ohne Probleme mit dem Verzeichnisseparator beruht, ist das richtig. .NET Core-Code wird jedoch auf .NET Core und nicht auf Mono ausgeführt. Daher wird es schwierig sein, beide zu mischen. Und da Mono ziemlich instabil und langsam ist, würde ich es sowieso nicht empfehlen. Versuchen Sie die Bildverarbeitung in .NET Core, z. WebP oder das Verschieben von GIF oder Multipage-TIFF oder das Schreiben von Text auf ein Bild werden Sie böse überraschen.

<edit> Ab Mitte Februar 2017: Sie können dafür jetzt SkiaSharp verwenden (Beispiel)</edit>

Hinweis:
Ab .NET Core 2.0 gibt es System.Drawing.Common (Nuget), das die meisten Funktionen von System.Drawing enthält. Es sollte in .NET-Core 2.1 mehr oder weniger vollständig sein. System.Drawing.Common verwendet jedoch GDI + und funktioniert daher nicht in Azure (System.Drawing-Bibliotheken sind im Azure Cloud-Dienst [im Grunde genommen nur eine VM], nicht jedoch in Azure Web App [im Grunde genommen gemeinsames Hosting?] Verfügbar.)
Bisher funktioniert System.Drawing.Common unter Linux/Mac einwandfrei.

Code, der nicht für .NET (Nicht-Core) geschrieben wurde, kann nicht auf .NET Core portiert werden.
Das heißt, wenn Sie möchten, dass eine Nicht-GPL-C # -Bibliothek wie PDFSharp PDF-Dokumente erstellt (sehr häufig), haben Sie Pech (in dem Augenblick) ( nicht mehr ). Egal, das ReportViewer-Steuerelement, das Windows-pInvokes verwendet (aus welchem ​​Grund auch immer) und unter Linux nicht einmal unter Mono ausgeführt wird
( Daran arbeite ich ).

Außerdem ist in .NET Core geschriebener Code nicht für Mono portierbar, da Mono (noch) nicht über die .NET Core-Laufzeitbibliotheken verfügt.

Mein Ziel ist es, mithilfe von C #, LINQ, EF7 und Visual Studio eine Website zu erstellen, die unter Linux ausgeführt/gehostet werden kann.

EF war in jeder Version, die ich bisher ausprobiert habe, so verdammt langsam (selbst bei so einfachen Dingen wie einem Tisch mit einem Links-Join), dass ich es niemals empfehlen würde - auch nicht unter Windows.
Ich würde EF insbesondere dann nicht empfehlen, wenn Sie eine Datenbank mit Unique-Constrains oder Spalten mit den Bezeichnungen Varbinary/Filestream/Hierarchieid haben. (auch nicht für Schema-Update)
Und auch nicht in Situationen, in denen die DB-Leistung kritisch ist (sagen wir 10+ bis 100+ gleichzeitige Benutzer).
Wenn Sie eine Website/Webanwendung unter Linux ausführen, müssen Sie sie früher oder später debuggen.
Es gibt keine Debugging-Unterstützung für .NET Core unter Linux. (nicht mehr, aber benötigt JetBrains Rider)
MonoDevelop unterstützt (noch) nicht das Debuggen von .NET-Core-Projekten.
Wenn Sie Probleme haben, sind Sie auf sich allein gestellt. Sie müssen umfangreiche Protokollierung verwenden.
Seien Sie vorsichtig, es wird darauf hingewiesen, dass eine umfassende Protokollierung Ihre Festplatte in kürzester Zeit füllen wird, insbesondere wenn Ihr Programm in eine Endlosschleife oder Rekursion eintritt.
Dies ist besonders gefährlich, wenn Ihre Web-App als Root ausgeführt wird, da für die Anmeldung Speicherplatz für Protokolldateien erforderlich ist. Wenn kein freier Speicherplatz mehr verfügbar ist, können Sie sich nicht mehr anmelden.
(Normalerweise sind ungefähr 5% des Speicherplatzes für den Benutzer root [aka Administrator unter Windows] reserviert, sodass sich zumindest der Administrator noch anmelden kann, wenn der Datenträger fast voll ist. Wenn Ihre Anwendungen jedoch als root ausgeführt werden, gilt diese Einschränkung gilt nicht für die Datenträgernutzung, daher können ihre Protokolldateien 100% des verbleibenden freien Speicherplatzes belegen, sodass sich nicht einmal der Administrator mehr anmelden kann.)
Es ist daher besser, diese Festplatte nicht zu verschlüsseln, wenn Sie Wert auf Ihre Daten/Ihr System legen.

Jemand sagte mir, dass er wollte, dass es "in Mono" ist, aber ich weiß nicht, was das bedeutet.

Entweder möchte er .NET Core nicht verwenden, oder er möchte C # nur unter Linux/Mac verwenden. Ich vermute, er möchte C # nur für eine Web-App unter Linux verwenden. .NET Core ist der richtige Weg, wenn Sie dies unbedingt in C # tun möchten. Gehen Sie nicht mit "Mono"; Auf den ersten Blick scheint es zu funktionieren - aber glauben Sie mir, Sie würden es bereuen, weil Monos ASP.NET MVC nicht stabil ist, wenn Ihr Server langfristig läuft (länger als 1 Tag) - Sie wurden jetzt gewarnt. Siehe auch die Referenzen "Nicht abgeschlossen", wenn die Monoleistung auf den techempower-Benchmarks gemessen wird.

fortunes

Ich möchte das .Net Core 1.0-Framework mit den oben aufgeführten Technologien verwenden. Er sagte auch, er wolle "fast cgi" verwenden. Ich weiß auch nicht, was das bedeutet.

Dies bedeutet, dass er einen leistungsstarken WebServer mit vollem Funktionsumfang wie nginx (Engine-X), möglicherweise Apache, verwenden möchte.
Dann kann er mono/dotnetCore mit Virtual Name Based Hosting (mehrere Domainnamen auf derselben IP) und/oder Load Balancing ausführen. Er kann auch andere Websites mit anderen Technologien betreiben, ohne eine andere Portnummer auf dem Webserver zu benötigen. Dies bedeutet, dass Ihre Website auf einem FastCGI-Server ausgeführt wird und Nginx alle Webanforderungen für eine bestimmte Domain über das FastCGI-Protokoll an diesen Server weiterleitet. Dies bedeutet auch, dass Ihre Website in einer FastCGI-Pipeline ausgeführt wird und Sie vorsichtig sein müssen, was Sie tun, z. Sie können HTTP 1.1 nicht zum Übertragen von Dateien verwenden.
Andernfalls werden die Dateien am Zielort verstümmelt.
Siehe auch hier und hier .

Schlussfolgern:
. NET Core ist derzeit weder wirklich portabel noch wirklich plattformübergreifend (insbesondere die Debug-Tools).
Auch die native Kompilierung ist nicht einfach, insbesondere für ARM.
Und für mich sieht es auch noch nicht so aus, als wäre seine Entwicklung "wirklich abgeschlossen".
Beispielsweise fehlt System.Data.DataTable/DataAdaper.Update ... (nicht mehr mit .NET Core 2.0)
Zusammen mit den System.Data.Common.IDB * -Schnittstellen. (nicht mehr mit .NET Core 1.1)
Wenn es jemals eine Klasse geben würde, die oft verwendet wird, wäre DataTable/DataAdapter das ...
Auch der Linux-Installer (.deb) schlägt fehl, zumindest auf meinem Computer, und ich bin sicher, dass ich nicht der einzige bin, der dieses Problem hat.
Debuggen, vielleicht mit Visual Studio Code, wenn Sie es aufbauen können ARM (das habe ich geschafft - folgen Sie NICHT dem Blog-Post von Scott Hanselman, wenn Sie das tun - es gibt einen Howto im Wiki von VS-Code auf Github), weil sie die ausführbare Datei nicht anbieten.
Yeoman scheitert ebenfalls. (Ich denke, es hat etwas mit der von Ihnen installierten NodeJS-Version zu tun - VS-Code erfordert eine Version, Yeoman eine andere ... aber es sollte auf demselben Computer laufen. Ziemlich lahm
Es ist egal, dass es auf der Knotenversion ausgeführt werden soll, die standardmäßig auf dem Betriebssystem ausgeliefert wird.
Egal, dass es überhaupt keine Abhängigkeit von NodeJS geben sollte.
Der Kestell-Server ist ebenfalls in Arbeit.
Und meiner Erfahrung mit dem Monoprojekt nach bezweifle ich, dass sie .NET Core jemals auf FastCGI getestet haben oder dass sie eine Vorstellung davon haben, was FastCGI-Unterstützung für ihr Framework bedeutet, geschweige denn, dass sie es getestet haben Stellen Sie sicher, dass "alles funktioniert". Tatsächlich habe ich gerade versucht, eine FastCGI-Anwendung mit .NET Core zu erstellen und festgestellt, dass es für .NET Core "RTM" keine FastCGI-Bibliothek gibt ...

Wenn Sie .NET Core "RTM" hinter nginx ausführen, können Sie dies nur tun, indem Sie Anfragen an kestrell (den von nodeJS abgeleiteten Web-Server) weiterleiten. Derzeit gibt es in .NET Core keine FastCgi-Unterstützung "RTM", AFAIK. Da es keine .net-Kern-Fastcgi-Bibliothek und keine Beispiele gibt, ist es auch sehr unwahrscheinlich, dass jemand das Framework getestet hat, um sicherzustellen, dass Fastcgi wie erwartet funktioniert.

Ich frage auch die Leistung.
Im (vorläufigen) techempower-Benchmark (Runde 13) liegt aspnetcore-linux im Verhältnis zur besten Leistung bei 25%, während vergleichbare Frameworks wie Go (golang) ) rangieren bei 96,9% der Spitzenleistung (und das ist, wenn nur Klartext ohne Dateisystemzugriff zurückgegeben wird). Bei der JSON-Serialisierung schneidet .NET Core etwas besser ab, sieht aber auch nicht überzeugend aus (go erreicht 98,5% des Peaks, .NET Core 65%). Das heißt, es kann unmöglich schlimmer sein als "Mono".

Da es noch relativ neu ist, wurden (noch) nicht alle wichtigen Bibliotheken portiert, und ich bezweifle, dass einige davon jemals portiert werden.
Imaging-Unterstützung ist im besten Fall auch fraglich.
Verwenden Sie stattdessen BouncyCastle, wenn Sie etwas verschlüsseln möchten.

Können Sie mir helfen, all diese Begriffe zu verstehen und wenn meine Erwartungen realistisch sind ?

Ich hoffe, ich habe Ihnen geholfen, mit all diesen Begriffen mehr Sinn zu machen.
So weit Ihre Erwartungen gehen:
Eine Linux-Anwendung zu entwickeln, ohne irgendetwas über Linux zu wissen, ist in erster Linie eine wirklich dumme Idee, und sie wird auch auf die eine oder andere schreckliche Weise scheitern. Das heißt, da Linux ohne Lizenzkosten auskommt, ist es im Prinzip eine gute Idee, ABER NUR, WENN SIE WISSEN, WAS SIE TUN.
Die Entwicklung einer Anwendung für eine Plattform, auf der Sie Ihre Anwendung nicht debuggen können, ist eine weitere wirklich schlechte Idee.
Für fastcgi zu entwickeln, ohne zu wissen, welche Konsequenzen das hat, ist eine weitere wirklich schlechte Idee.

All diese Dinge auf einer "experimentellen" Plattform ohne Kenntnis der Besonderheiten dieser Plattform und ohne Debugging-Unterstützung zu tun, ist Selbstmord, wenn Ihr Projekt mehr als nur eine persönliche Homepage ist. Auf der anderen Seite wäre es wahrscheinlich eine sehr gute Erfahrung für Sie, es mit Ihrer persönlichen Homepage zu Lernzwecken zu machen - dann lernen Sie das Framework und die Nicht-Framework-Probleme kennen.
Sie können beispielsweise (programmgesteuert) ein Fat32, HFS oder JFS mit ohne Berücksichtigung der Groß-/Kleinschreibung für Ihre Anwendung einbinden, um die Probleme mit der Groß-/Kleinschreibung zu umgehen (das Einbinden in einer Schleife wird in nicht empfohlen) Produktion).

Zusammenfassen
Zur Zeit würde ich mich von .NET Core fernhalten (für den produktiven Einsatz). Vielleicht können Sie in ein bis zwei Jahren einen anderen Blick darauf werfen, aber wahrscheinlich nicht vorher.
Wenn Sie ein neues Webprojekt haben, das Sie entwickeln, starten Sie es in .NET Core, nicht in Mono.

Wenn Sie ein Framework benötigen, das unter Linux (x86/AMD64/ARMhf) und Windows und Mac funktioniert, das keine Abhängigkeiten aufweist, dh nur statische Verknüpfungen und keine Abhängigkeit von .NET, Java oder Windows. Verwenden Sie stattdessen Golang. Es ist ausgereifter und seine Leistung ist bewiesen (Baidu verwendet es mit 1 Million gleichzeitigen Benutzern), und Golang hat einen deutlich geringeren Speicherbedarf. Auch golang ist in den Repositories, die .deb installiert sich ohne Probleme, der Quellcode kompiliert - ohne dass Änderungen erforderlich sind - und golang hat (in der Zwischenzeit) Debugging-Unterstützung mit delve und JetBrains Gogland an Linux (und Windows und Mac). Der Build-Prozess (und die Laufzeit) von Golang hängen auch nicht von NodeJS ab, was ein weiteres Plus ist.

So weit wie Mono geht, halte dich davon fern.
Es ist wirklich erstaunlich, wie weit Mono gekommen ist, aber leider ist dies kein Ersatz für seine Leistung/Skalierbarkeit und Stabilitätsprobleme bei Produktionsanwendungen.
Auch Mono-Entwicklung ist ziemlich tot, sie entwickeln größtenteils nur noch die Teile, die für Android und iOS relevant sind, denn hier verdient Xamarin sein Geld.
Erwarten Sie nicht, dass Web-Development ein erstklassiger Xamarin/Mono-Bürger ist.
. NET Core kann sich lohnen, wenn Sie ein neues Projekt starten. Bei vorhandenen großen Webformularprojekten ist eine Portierung jedoch weitgehend ausgeschlossen. Die erforderlichen Änderungen sind enorm. Wenn Sie ein MVC-Projekt haben, ist die Menge der Änderungen möglicherweise überschaubar, wenn Ihr ursprüngliches Anwendungsdesign vernünftig war, was bei den meisten vorhandenen sogenannten "historisch gewachsenen" Anwendungen meist nicht der Fall ist.

Dezember 2016 Update:
Die native Kompilierung wurde aus der .NET Core-Vorschau entfernt, da sie noch nicht fertig ist ...

Sieht so aus, als hätten sie sich im Vergleich zum Rohtext-Benchmark stark verbessert, aber andererseits ist es ziemlich fehlerhaft geworden. Auch bei den JSON-Benchmarks verschlechterte sich die Situation weiter. Neugierig ist auch, dass das Entity-Framework für Updates schneller sein soll als Dapper - obwohl beide bei Rekord-Langsamkeit. Dies ist sehr unwahrscheinlich. Sieht so aus, als gäbe es immer noch mehr als nur ein paar Käfer zu jagen.

Auch an der Linux-Front IDE scheint es Erleichterung zu geben.
JetBrains veröffentlichte "Project Rider", eine Vorschau auf einen C #/.NET-Kern IDE für Linux (und Mac und Windows), der Visual Studio Project-Dateien verarbeiten kann. Endlich ein C # IDE, das brauchbar und nicht so langsam ist.

Fazit: .NET Core ist noch eine Pre-Release-Qualitätssoftware, da wir in das Jahr 2017 starten. Portieren Sie Ihre Bibliotheken, aber halten Sie sich für den produktiven Einsatz davon fern, bis sich die Framework-Qualität stabilisiert.
Und behalte Project Rider im Auge.

buggy .net core

Update 2017
Habe vorerst meine (Bruder-) Homepage auf .NET Core migriert.
Bisher scheint die Laufzeit unter Linux stabil genug zu sein (zumindest für kleine Projekte) - sie hat einen Auslastungstest mit Leichtigkeit überstanden - Mono hat dies nie getan.
Es sieht auch so aus, als hätte ich .NET-Core-native und .NET-Core-eigenständige Bereitstellung vermischt. Die eigenständige Bereitstellung funktioniert, ist aber etwas unterdokumentiert, obwohl sie sehr einfach zu handhaben ist (die Tools zum Erstellen/Veröffentlichen sind etwas instabil, aber führen Sie denselben Befehl erneut aus, wenn die Meldung "Positive Zahl erforderlich. Build FAILED" angezeigt wird. und es funktioniert).

Du kannst rennen

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

Und Sie erhalten eine eigenständige EXE-Datei (im Veröffentlichungsverzeichnis), die Sie auf einen Windows 8.1-Computer ohne .NET Framework verschieben und ausführen können. Nett. Hier fängt dotNET-Core gerade an, interessant zu werden. (Beachten Sie die Lücken, SkiaSharp funktioniert nicht unter Windows 8.1 /Windows Server 2012 R2, [noch] - das Ökosystem muss zuerst aufholen - aber interessanterweise das Skia -dll-load-fail stürzt nicht den gesamten Server/die gesamte Anwendung ab - alles andere funktioniert)

(Hinweis: In SkiaSharp unter Windows 8.1 fehlen die entsprechenden VC Laufzeitdateien - msvcp140.dll und vcruntime140.dll. Kopieren Sie sie in das Veröffentlichungsverzeichnis, und Skia funktioniert unter Windows 8.1.)

Aktualisierung August 2017
. NET Core 2.0 veröffentlicht.
Seien Sie vorsichtig - kommt mit (großen) Änderungen in der Authentifizierung ...
Positiv ist zu vermerken, dass die Klassen DataTable/DataAdaper/DataSet und viele weitere zurückgebracht wurden.
Es wurde festgestellt, dass in .NET Core noch keine Unterstützung für Apache SparkSQL vorhanden ist, da Mobius noch nicht portiert ist. Das ist schlecht, weil das keine SparkSQL-Unterstützung für meinen IoT Cassandra -Cluster bedeutet, also keine Joins ...
Experimentelle ARM Unterstützung (nur Laufzeit, kein SDK - schade für die Entwicklung auf meinem Chromebook - freut sich auf 2.1 oder 3.0).
PdfSharp ist jetzt experimentell auf .NET Core portiert.
JetBrains Rider hat EAP verlassen. Sie können es jetzt verwenden, um .NET Core unter Linux zu entwickeln und zu debuggen - bisher nur .NET Core 1.1, bis das Update für die .NET Core 2.0-Unterstützung live geht.

Aktualisierung Mai 2018
. NET Core 2.1 Release steht kurz bevor. Vielleicht behebt dies die NTLM-Authentifizierung unter Linux (die NTLM-Authentifizierung funktioniert unter Linux {und möglicherweise Mac} in .NET-Core 2.0 nicht mit mehreren Authentifizierungs-Headern, wie z. B. "Verhandeln", die normalerweise mit ms-exchange gesendet werden, und sie sind anscheinend nur in v2.1 behoben, keine Bugfix-Version für 2.0).
Ich installiere jedoch keine Preview-Versionen auf meinem Computer. Also warte.
v2.1 soll außerdem die Kompilierzeiten erheblich verkürzen. Das wäre gut.

Beachten Sie auch, dass .NET Core unter Linux nur 64-Bit ist!
Es gibt keine x86-32-Version von .NET Core unter Linux .
Und der ARM -Port ist nur ARM-32. Noch kein ARM-64.
Und auf ARM haben Sie (derzeit) nur die Laufzeit, nicht das dotnet-SDK.

Und noch etwas:
Da .NET-Core OpenSSL 1.0 verwendet, läuft .NET Core unter Linux nicht unter Arch Linux und nach Ableitung auch nicht unter Manjaro (der derzeit mit Abstand beliebtesten Linux-Distribution), da Arch Linux verwendet OpenSSL 1.1.Wenn Sie also Arch Linux verwenden, haben Sie (auch mit Gentoo) Pech.

Auf der Oberseite hat sich die Leistung definitiv verbessert: fortunes

plaintext

.NET Core 3:
. NET-Core v 3.0 soll WinForms und WPF auf .NET-Core bringen.
Während WinForms und WPF .NET Core sein werden, werden WinForms und WPF in .NET-Core nur unter Windows ausgeführt, da WinForms/WPF die Windows-API verwenden wird.

PS:

export DOTNET_CLI_TELEMETRY_OPTOUT=1 

Wenn Sie es unter Windows verwendet haben, haben Sie es wahrscheinlich noch nie gesehen:

Die .NET Core-Tools erfassen Nutzungsdaten, um Ihre Erfahrungen zu verbessern.
Die Daten sind anonym und enthalten keine Befehlszeilenargumente.
Die Daten werden von Microsoft gesammelt und mit der Community geteilt.
Sie können die Telemetrie deaktivieren, indem Sie eine DOTNET_CLI_TELEMETRY_OPTOUT-Umgebungsvariable mit Ihrer bevorzugten Shell auf 1 setzen.
Weitere Informationen zu den .NET Core-Tools finden Sie unter telemetry @ https://aka.ms/dotnet-cli-telemetry .

Ich dachte, ich würde erwähnen, dass ich denke, Monodevelop (auch bekannt als Xamarin Studio, die Mono-IDE) hat sich recht gut entwickelt und ist in der Zwischenzeit größtenteils verwendbar.
JetBrains Rider (EAP 2018 zu diesem Zeitpunkt) ist jedoch definitiv viel besser und zuverlässiger (und der enthaltene Dekompiler ist lebensrettender), das heißt, wenn Sie .NET-Core entwickeln unter Linux oder Mac.

Haftungsausschluss:
Ich verwende keinen Mac, daher kann ich nicht sagen, ob das, was ich hier geschrieben habe, auch für FreeBSD-Unix-basierte Macs gilt. Ich beziehe mich auf die Linux-Version (Debian/Ubuntu/Mint) von JetBrains Rider, Mono, MonoDevelop/VisualStudioMac/XamarinStudio und .NET-Core. Außerdem erwägt Apple einen Wechsel von Intel-Prozessoren zu selbst hergestellten ARM-Prozessoren (ARM-64?), Sodass vieles, was derzeit für Macs gilt, in Zukunft möglicherweise nicht mehr für Macs gilt (2020+) ).

Wenn ich schreibe "Mono ist ziemlich instabil und langsam", bezieht sich die Unstable auf WinFroms & WebForms-Anwendungen, insbesondere auf das Ausführen von Webanwendungen über FastCGI oder mit XSP (in der 4.x-Version von Mono) sowie auf die XML-Serialisierung -handling Besonderheiten, und die ziemlich langsam bezieht sich auf WinForms und reguläre Ausdrücke im Besonderen (ASP.NET-MVC verwendet reguläre Ausdrücke auch für das Routing).

Wenn ich über meine Erfahrungen mit Mono 4.x schreibe, heißt das nicht zwangsläufig, dass diese Probleme bis jetzt noch nicht behoben sind oder dass es keine gibt, wenn sie jetzt behoben sind Seien Sie später eine Regression, die einen dieser Fehler/Features wieder einführt. Das bedeutet auch nicht, dass Sie beim Einbetten der Mono-Laufzeit dieselben Ergebnisse erzielen wie bei Verwendung der Mono-Laufzeit des (Dev) -Systems. Dies bedeutet auch nicht, dass die Einbettung der Mono-Laufzeit (überall) unbedingt kostenlos ist.

Alles, was nicht unbedingt bedeutet, dass Mono für IOS oder Android ungeeignet ist oder die gleichen Probleme aufweist. Ich verwende Mono nicht auf Android oder IOS, daher bin ich nicht in der Position, etwas über Stabilität, Benutzerfreundlichkeit, Kosten und Leistung auf diesen Plattformen zu sagen. Wenn Sie .NET unter Android verwenden, müssen Sie natürlich auch einige andere Kostenaspekte berücksichtigen, z. B. die Gewichtung der Xamarin-Kosten im Vergleich zu den Kosten und der Zeit für die Portierung von vorhandenem Code nach Java. Man hört Mono auf Android und IOS soll ganz gut sein. Nimm es mit einem Körnchen Salz. Erwarten Sie zum einen nicht, dass die Standard-Systemcodierung unter Android/ios und Windows gleich ist, und erwarten Sie nicht, dass beim Dateisystem Android die Groß- und Kleinschreibung nicht beachtet wird.

217
Stefan Steiger

In der .NET-Welt gibt es zwei Arten von CLRs, "volle" CLRs und Core-CLRs, und dies sind sehr unterschiedliche Dinge.

Es gibt zwei "vollständige" CLR-Implementierungen, die native .NET-CLR von Microsoft (für Windows) und die Mono-CLR (die selbst über Implementierungen für Windows, Linux und Unix (Mac OS X und FreeBSD) verfügt). Eine vollständige CLR ist genau das - alles, was Sie brauchen. Infolgedessen neigen "volle" CLRs dazu, groß zu sein.

Core-CLRs werden dagegen reduziert und sind viel kleiner. Da es sich nur um eine Kernimplementierung handelt, ist es unwahrscheinlich, dass sie über alles verfügen, was Sie brauchen. Mit Core-CLRs fügen Sie der von Ihrem speziellen Softwareprodukt verwendeten CLR-Funktion mit NuGet Funktionssätze hinzu. Es gibt Core-CLR-Implementierungen für Windows, Linux (verschiedene) und Unix (Mac OS X und FreeBSD) im Mix. Microsoft hat oder hat die .NET Framework-Bibliotheken für Core CLR auch überarbeitet, um sie für den Kernkontext tragbarer zu machen. Angesichts der Präsenz von Mono auf * nix-Betriebssystemen wäre es eine Überraschung, wenn die Core-CLRs für * nix keine Monocodebasis enthalten würden, aber nur die Mono-Community und Microsoft könnten uns dies mit Sicherheit sagen.

Außerdem stimme ich mit Nico darin überein, dass Core CLRs neu sind - es ist im Moment auf der RC2, denke ich. Ich würde mich noch nicht auf den Produktionscode verlassen.

Um Ihre Frage zu beantworten, können Sie Ihre Site mit Core CLR oder Mono unter Linux bereitstellen. Dies sind zwei verschiedene Möglichkeiten, dies zu tun. Wenn Sie jetzt eine sichere Wette wünschen, würde ich mit Mono auf Linux gehen und dann, wenn Sie möchten, später auf Core portieren.

50
muszeo

Sie haben nicht nur einen realistischen Weg gewählt, sondern eines der besten Ökosysteme (auch X-Plattformen), das von MS stark unterstützt wird. Dennoch sollten Sie folgende Punkte beachten:

  • Update: Das Hauptdokument zum .Net-Plattformstandard ist hier: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
  • Update: Current Mono 4.4.1 kann den neuesten Asp.Net Core 1.0 RTM nicht ausführen
  • Obwohl Mono mehr Funktionen bietet, ist die Zukunft unklar, da MS es seit einigen Monaten besitzt und es eine doppelte Arbeit ist, um sie zu unterstützen. Aber MS setzt sich definitiv für .Net Core ein und setzt viel darauf.
  • Obwohl .Net Core veröffentlicht wird, ist das 3rd-Party-Ökosystem nicht ganz vorhanden. Zum Beispiel können Nhibernate, Umbraco usw. noch nicht über .Net Core laufen. Aber sie haben einen Plan.
  • In .Net Core fehlen einige Funktionen wie System.Drawing. Sie sollten daher nach Bibliotheken von Drittanbietern suchen
  • Sie sollten nginx als Front-Server mit Kestrelserver für asp.net-Apps verwenden, da der Kestrelserver nicht für die Produktion bereit ist. Zum Beispiel ist HTTP/2 nicht implementiert.

Ich hoffe, es hilft

13
Otabek Kholikov

.Net Core erfordert kein Mono im Sinne des Mono-Frameworks. .NET Core ist ein Framework, das auf mehreren Plattformen einschließlich Linux funktioniert. Referenz https://dotnet.github.io/ .

Der .NET-Kern kann jedoch das Mono-Framework verwenden. Referenz https://docs.asp.net/de/1.0.0-rc1/getting-started/choosing-the-right-dotnet.html (Hinweis rc1 dokumentatiopn kein rc2 verfügbar), jedoch mono ist kein von Microsoft unterstütztes Framework und würde die Verwendung eines unterstützten Frameworks empfehlen 

Das Entity Framework 7 heißt jetzt Entity Framework Core und ist auf mehreren Plattformen einschließlich Linux verfügbar. Referenz https://github.com/aspnet/EntityFramework (Straßenkarte überprüfen)

Ich verwende derzeit beide Frameworks, aber Sie müssen wissen, dass es sich noch im Release-Kandidatenstadium befindet (RC2 ist die aktuelle Version), und bei den Beta- und Release-Kandidaten gab es massive Änderungen, die normalerweise dazu führen, dass Sie sich am Kopf kratzen.

Hier finden Sie ein Tutorial zur Installation von MVC .Net Core in Linux. https://docs.asp.net/de/1.0.0-rc1/getting-started/installing-on-linux.html

Schließlich haben Sie die Wahl zwischen Webservern (von denen ich annehme, dass die fast cgi-Referenz stammt), um Ihre Anwendung unter Linux zu hosten. Hier ist ein Bezugspunkt für die Installation in einer Linux-Umgebung. https://docs.asp.net/de/1.0.0-rc1/publishing/linuxproduction.html

Ich weiß, dass dieser Beitrag meistens Links zu Dokumentationen ist, aber an diesem Punkt sind dies die besten Informationsquellen. .Net core ist in der .Net-Community noch relativ neu und bis zur vollständigen Veröffentlichung wäre ich zögerlich, es in einer Produktumgebung zu verwenden, da sich die veröffentlichten Versionen grundlegend ändern.

9
Nico

Diese Frage ist besonders aktuell, weil Microsoft gestern offiziell angekündigtes .NET Core 1.0-Release . Unter der Annahme, dass Mono die meisten .NET-Standardbibliotheken implementiert, kann der Unterschied zwischen Mono- und .NET-Core durch den Unterschied zwischen .NET Framework und .NET Core gesehen werden:

  • APIs - .NET Core enthält viele der gleichen, aber weniger, APIs wie .NET Framework und mit einem anderen Factoring (Assemblynamen)
    anders; Typform unterscheidet sich in wichtigen Fällen). Diese Unterschiede
    Derzeit sind normalerweise Änderungen an der Portquelle für .NET Core erforderlich. .NETZ Core implementiert die .NET-Standardbibliothek-API
    Sie können im Laufe der Zeit mehr BCL-APIs für .NET Framework hinzufügen.
  • Subsysteme - .NET Core implementiert eine Teilmenge der Subsysteme in .NET Framework mit dem Ziel einer einfacheren Implementierung und
    Programmiermodell. Beispielsweise ist Code Access Security (CAS) nicht
    unterstützt, während die Reflexion unterstützt wird.

Wenn Sie etwas schnell starten müssen, gehen Sie zu Mono, da es derzeit (Juni 2016) ausgereifter ist. Wenn Sie jedoch eine langfristige Website erstellen, würde ich .NET Core vorschlagen. Es wird offiziell von Microsoft unterstützt, und der Unterschied bei den unterstützten APIs wird wahrscheinlich bald verschwinden, wenn man berücksichtigt, welche Anstrengungen Microsoft bei der Entwicklung von .NET Core unternommen hat.

Mein Ziel ist, C #, LINQ, EF7, Visual Studio zu verwenden, um eine Website zu erstellen das kann in Linux ausgeführt werden.

Linq und Entity Framework sind in .NET Core enthalten , sodass Sie sicher eine Aufnahme machen können.

7
Miljen Mikic

Um einfach zu sein, 

Mono ist eine Drittanbieter-Implementierung von .NET Framework für Linux/Android/iOs

.Net Core ist die eigene Implementierung von Microsoft.

.Net Core ist Zukunft. und Mono wird irgendwann tot sein. Allerdings ist .Net Core noch nicht ausgereift. Ich hatte Schwierigkeiten, es mit IBM Bluemix zu implementieren, und verwarf die Idee später. Im Laufe der Zeit (1-2 Jahre) sollte es besser sein.

2
Thakur

In einer Nussschale:

Mono = Compiler für C #

Mono Develop = Compiler + IDE

.Net Core = ASP Compiler

Der aktuelle Fall für .Net Core ist nur Web, sobald ein offener Winform-Standard und eine breitere Sprachanwendung angenommen werden. Es könnte sich schließlich um das Microsoft-Killer-Dev-Powerhouse handeln. In Anbetracht der jüngsten Umstellung der Java-Lizenzierung durch Oracle hat Microsoft viel Zeit, um zu glänzen.

0
mrcrunch