Nekromantie.
Eine tatsächliche Antwort geben.
Was ist der Unterschied zwischen .Net Core und Mono?
.NET Core ist jetzt offiziell die Zukunft von .NET. Es begann größtenteils mit einem erneuten Schreiben des ASP.NET MVC- Frameworks und der Konsolenanwendungen, zu denen natürlich auch Serveranwendungen gehören. (Da es Turing-complete ist und Interop mit C-DLLs unterstützt, können Sie, wenn Sie dies unbedingt möchten, auch Ihre eigenen Desktop-Anwendungen damit schreiben, beispielsweise über Bibliotheken von Drittanbietern wie Avalonia, die zu der Zeit, als ich das erste Mal schrieb, ein bisschen sehr einfach waren, was bedeutete, dass Sie sich ziemlich auf Web- oder Server-Inhalte beschränkten.) Im Laufe der Zeit wurden viele APIs zu .NET Core hinzugefügt, so dass nach Version 3.1 .NET Core wird auf Version 5.0 springen, ohne den "Core" als .NET 5.0 bekannt sein, und das wird dann die Zukunft von .NET Framework sein. Was früher das vollständige .NET Framework war, wird einige Jahrzehnte lang im Wartungsmodus als vollständiges .NET Framework 4.8.x verweilen, bis es stirbt (möglicherweise wird es noch einige Upgrades geben, aber ich bezweifle es). Mit anderen Worten, .NET Core ist die Zukunft von .NET, und Full .NET Framework wird den Weg von Dodo / Silverlight / WindowsPhone gehen .
Neben der Unterstützung mehrerer Plattformen besteht der Hauptpunkt von .NET Core darin, die Leistung zu verbessern und die "native Kompilierung" / eigenständige Bereitstellung zu aktivieren (sodass auf dem Zielcomputer kein .NET Framework / VM installiert sein muss .
auf der einen Seite bedeutet dies docker.io Unterstützung auf Linux, und auf der anderen Seite , in sich geschlossene Einsatz ist in „Cloud-Computing“, nützlich , da dann können Sie nur verwenden , was auch immer Version der Sie dotnet-CORE Rahmen gefallen, und Sie müssen sich keine Gedanken darüber machen, welche Version (en) des .NET Frameworks der Systemadministrator tatsächlich installiert hat.
Während die .NET Core-Laufzeit mehrere Betriebssysteme und Prozessoren unterstützt, sieht das SDK anders aus. Während das SDK mehrere Betriebssysteme unterstützt, ist / war die ARM-Unterstützung für das SDK noch in Arbeit. .NET Core wird von Microsoft unterstützt. Dotnet-Core wurde nicht mit WinForms oder WPF oder Ähnlichem geliefert.
- Ab Version 3.0 werden WinForms und WPF auch von .NET Core unterstützt, jedoch nur unter Windows und nur von C #. Nicht von VB.NET (VB.NET-Unterstützung für Version 5 im Jahr 2020 geplant). In .NET Core gibt es keinen Forms Designer: Er wird später zu einem nicht festgelegten Zeitpunkt mit einem Visual Studio-Update ausgeliefert.
- WebForms werden von .NET Core immer noch nicht unterstützt, und es gibt keine Pläne, sie jemals zu unterstützen ( Blazor ist das neue Kind in der Stadt dafür).
- .NET Core wird auch mit System.Runtime geliefert, das mscorelib ersetzt.
- Oft wird .NET Core mit NetStandard verwechselt , einem kleinen Wrapper um System.Runtime / mscorelib (und einige andere), mit dem Sie Bibliotheken schreiben können, die auf .NET Core, Full .NET Framework und Xamarin (iOS) abzielen / Android), alle gleichzeitig.
- Das .NET Core SDK funktioniert nicht / nicht auf ARM, zumindest nicht beim letzten Mal, als ich es überprüft habe.
"The Mono Project" ist viel älter als .NET Core.
Mono ist spanisch und bedeutet Affe, und als Nebenbemerkung hat der Name nichts mit Mononukleose zu tun (Hinweis: Eine Liste der Mitarbeiter finden Sie unter http://primates.ximian.com /).
Mono wurde 2005 von Miguel de Icaza (dem Gründer von GNOME - und einigen anderen) als Implementierung des .NET Framework für Linux (Ximian / SuSe / Novell) gestartet. Mono enthält Web-Forms, Winforms, MVC, Olive und eine IDE namens MonoDevelop(auch bekannt als Xamarin Studio oder Visual Studio Mac). 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 unter Linux zum Laufen zu bringen.
Mono wird von Xamarin (dem neuen Firmennamen von Ximian, als sie sich auf den mobilen Markt anstatt auf den Linux-Markt konzentrierten) und nicht von Microsoft unterstützt.
(Da Xamarin von Microsoft gekauft wurde, ist dies technisch [aber nicht kulturell] Microsoft.)
Normalerweise wird Ihr C # -Ding auf Mono kompiliert, nicht jedoch das VB.NET-Material.
Mono vermisst einige erweiterte Funktionen wie WSE / WCF und WebParts.
Viele der Mono-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 in .NET (z. B. XML-Serialisierung) oder auf andere Weise instabil (ASP.NET MVC). und inakzeptabel langsam (Regex). Auf der anderen Seite funktioniert die Mono-Toolchain auch mit ARM.
Wenn es um .NET Core geht, sollten Sie nicht erwarten, dass plattformübergreifend bedeutet, dass Sie .NET Core unter ARM-Linux installieren können, wie Sie es mit ElasticSearch tun können. Sie müssen das gesamte Framework aus dem Quellcode kompilieren.
Das heißt, wenn Sie über diesen Speicherplatz verfügen (z. B. auf einem Chromebook mit insgesamt 16 bis 32 GB HD).
Es gab auch Probleme mit der Inkompatibilität mit OpenSSL 1.1 und libcurl.
Diese wurden in der neuesten Version von .NET Core Version 2.2 behoben.
Soviel zum plattformübergreifenden.
Ich habe auf der offiziellen Website eine Erklärung gefunden, die besagt: "Der dafür geschriebene Code ist auch über Anwendungsstapel wie Mono portierbar."
Solange dieser Code nicht auf WinAPI-Aufrufen, Windows-DLL-Pinvokes, COM-Komponenten, einem Dateisystem ohne Berücksichtigung der Groß- und Kleinschreibung, der Standardsystemcodierung (Codepage) und keinen Problemen mit dem Verzeichnistrenner beruht, ist dies der Fall richtig. .NET Core-Code wird jedoch unter .NET Core und nicht unter Mono ausgeführt. Das Mischen der beiden wird also schwierig sein. Und da Mono ziemlich instabil und langsam ist (für Webanwendungen), würde ich es sowieso nicht empfehlen. Versuchen Sie die Bildverarbeitung auf einem .NET-Kern, z. B. WebP oder das Verschieben von GIF oder Multipage-Tiff oder das Schreiben von Text auf ein Bild. Sie werden böse überrascht sein.
Hinweis:
Ab .NET Core 2.0 gibt es System.Drawing.Common (NuGet), das die meisten Funktionen von System.Drawing enthält. In .NET-Core 2.1 sollte es mehr oder weniger vollständig sein. Allerdings verwendet System.Drawing.Common GDI +, und wird daher nicht die Arbeit an Azure (System.Drawing Bibliotheken sind in Azure Cloud Service [im Grunde nur eine VM], aber nicht in Azure Web App [im Grunde Shared Hosting?])
So Bisher funktioniert System.Drawing.Common unter Linux / Mac einwandfrei, hat jedoch Probleme mit iOS / Android - wenn überhaupt, dort.
Vor .NET Core 2.0, dh Mitte Februar 2017, konnten Sie SkiaSharp für die Bildbearbeitung verwenden (Beispiel) (dies ist weiterhin möglich).
Nach .net-core 2.0 werden Sie feststellen, dass SixLabors ImageSharpist der richtige Weg, da System.Drawing nicht unbedingt sicher ist und viele potenzielle oder echte Speicherlecks aufweist, weshalb Sie GDI nicht in Webanwendungen verwenden sollten. Beachten Sie, dass SkiaSharp viel schneller als ImageSharp ist, da es native Bibliotheken verwendet (was auch ein Nachteil sein kann). Beachten Sie auch, dass GDI + zwar unter Linux und Mac funktioniert, dies jedoch nicht unter iOS / Android.
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 kein Glück(im Moment)( nicht mehr ). Egal, das ReportViewer-Steuerelement, das Windows-pInvokes verwendet (zum Verschlüsseln, Erstellen von mcdf-Dokumenten über COM, zum Abrufen von Informationen zu Schriftart, Zeichen, Kerning, zum Einbetten von Schriftarten, zum Messen von Zeichenfolgen und zum Zeilenumbruch sowie zum Zeichnen von Tiffs von akzeptabler Qualität). und läuft nicht einmal unter Mono unter Linux
(daran arbeite ich ).
Außerdem ist in .NET Core geschriebener Code nicht auf Mono portierbar, da Mono (bisher) die .NET Core-Laufzeitbibliotheken fehlen.
Mein Ziel ist es, mit C #, LINQ, EF7, Visual Studio eine Website zu erstellen, die unter Linux ausgeführt / gehostet werden kann.
EF in jeder Version, die ich bisher ausprobiert habe, war so verdammt langsam (selbst bei so einfachen Dingen wie einer Tabelle mit einem Links-Join), ich würde es niemals empfehlen - auch nicht unter Windows.
Ich würde EF besonders nicht empfehlen, wenn Sie eine Datenbank mit eindeutigen Einschränkungen oder varbinary / filestream / hierarchyid-Spalten haben. (Auch nicht für Schema-Updates.)
Und auch nicht in Situationen, in denen die DB-Leistung kritisch ist (z. B. 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, erfordert jedoch JetBrains Rider.)
MonoDevelop unterstützt (noch) nicht das Debuggen von .NET Core-Projekten.
Wenn Sie Probleme haben, sind Sie alleine. Sie müssen eine umfangreiche Protokollierung verwenden.
Seien Sie vorsichtig, beachten Sie, dass eine umfangreiche Protokollierung Ihre Festplatte in kürzester Zeit füllt, 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 Protokollspeicherplatz erforderlich ist. Wenn kein freier Speicherplatz mehr vorhanden ist, können Sie sich nicht mehr anmelden.
(Normalerweise sind etwa 5% des Speicherplatzes für den Benutzer root (auch bekannt als Administrator unter Windows) reserviert, sodass sich der Administrator immer noch anmelden kann, wenn der Datenträger fast voll ist. Wenn Ihre Anwendungen jedoch als root ausgeführt werden, gilt diese Einschränkung nicht Ihre Festplattennutzung und damit ihre Protokolldateien können 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, dh wenn Sie Ihre Daten / Ihr System schätzen.
Jemand sagte mir, dass er wollte, dass es "in Mono" ist, aber ich weiß nicht, was das bedeutet.
Entweder bedeutet dies, dass er .NET Core nicht verwenden möchte, oder er möchte nur C # 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 richtig"; An der Oberfläche scheint es zunächst zu funktionieren - aber glauben Sie mir, Sie werden 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" bei der Messung der Mono-Leistung anhand der Techempower-Benchmarks.
Ich weiß, dass ich das .Net Core 1.0-Framework mit den oben aufgeführten Technologien verwenden möchte. 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) und möglicherweise Apache verwenden möchte.
Anschließend kann er mono / dotnetCore mit virtuellem namenbasiertem Hosting (mehrere Domainnamen auf derselben IP) und / oder Lastenausgleich 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 Webanfragen 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, z. B. wenn Sie beim Übertragen von Dateien kein HTTP 1.1 verwenden können.
Andernfalls werden Dateien am Zielort verstümmelt.
Siehe auch hier und hier .
Fazit:
.NET Core ist derzeit (28.09.2016) weder wirklich portabel noch wirklich plattformübergreifend (insbesondere die Debug-Tools).
Auch für ARM ist die native Kompilierung nicht einfach.
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 gab, die häufig verwendet wird, wäre es DataTable / DataAdapter ...
Außerdem schlägt das Linux-Installationsprogramm (.deb) zumindest auf meinem Computer fehl, und ich ' Ich bin sicher, dass ich nicht der einzige bin, der dieses Problem hat.
Debuggen Sie, vielleicht mit Visual Studio Code, wenn Sie es auf ARM aufbauen können (ich habe das geschafft - folgen Sie NICHT dem Blog-Beitrag von Scott Hanselman, wenn Sie das tun - es gibt eine Anleitung im Wiki von VS-Code auf Github), weil Sie bieten die ausführbare Datei nicht an.
Yeoman scheitert auch. (Ich denke, es hat etwas mit der von Ihnen installierten Version von nodejs zu tun - VS Code erfordert eine Version, Yeoman eine andere ... aber es sollte auf demselben Computer ausgeführt werden. Ziemlich lahm
Egal, dass es auf der standardmäßig gelieferten Knotenversion ausgeführt werden sollte auf dem Betriebssystem.
Es ist egal, dass es überhaupt keine Abhängigkeit von NodeJS geben sollte.
Der Kestell-Server ist ebenfalls in Arbeit.
Und nach meiner Erfahrung mit dem Monoprojekt bezweifle ich sehr, dass sie jemals .NET Core 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, um sicherzustellen, dass "alles funktioniert" ". Tatsächlich habe ich gerade versucht, eine FastCGI-Anwendung mit .NET Core zu erstellen, und festgestellt, dass es keine FastCGI-Bibliothek für .NET Core "RTM" gibt ...
Wenn Sie also .NET Core "RTM" hinter nginx ausführen, können Sie dies nur tun, indem Sie Anforderungen an kestrell (diesen halbfertigen, von nodeJS abgeleiteten Webserver) 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 bei 25% im Vergleich zur besten Leistung, während vergleichbare Frameworks wie Go (Golang) bei 96,9% der Spitzenleistung liegen (und dies bei Rückgabe von Klartext ohne Datei) nur Systemzugriff). .NET Core schneidet bei der JSON-Serialisierung etwas besser ab, sieht aber auch nicht überzeugend aus (erreicht 98,5% des Peaks, .NET Core 65%). Das heißt, es kann unmöglich schlimmer sein als "Mono richtig".
Da es noch relativ neu ist, wurden (noch) nicht alle wichtigen Bibliotheken portiert, und ich bezweifle, dass einige von ihnen jemals portiert werden.
Imaging-Support ist ebenfalls bestenfalls fraglich.
Verwenden Sie für die Verschlüsselung stattdessen BouncyCastle.
Können Sie mir helfen, all diese Begriffe zu verstehen und ob meine Erwartungen realistisch sind ?
Ich hoffe, ich habe Ihnen geholfen, mit all diesen Begriffen mehr Sinn zu machen.
Was Ihre Erwartungen angeht: Die
Entwicklung einer Linux-Anwendung, ohne etwas über Linux zu wissen, ist in erster Linie eine wirklich dumme Idee, und sie wird auf die eine oder andere Weise auf schreckliche Weise scheitern. Da Linux keine Lizenzkosten verursacht, ist dies 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 es gibt, ist eine weitere wirklich schlechte Idee.
All diese Dinge auf einer "experimentellen" Plattform zu tun, ohne die Besonderheiten dieser Plattform zu kennen und ohne Unterstützung beim Debuggen, ist Selbstmord, wenn Ihr Projekt mehr als nur eine persönliche Homepage ist. Auf der anderen Seite denke ich, dass es wahrscheinlich eine sehr gute Erfahrung wäre, dies mit Ihrer persönlichen Homepage zu Lernzwecken zu tun - dann lernen Sie das Framework und die Nicht-Framework-Probleme kennen.
Sie können beispielsweise (programmgesteuert) ein case32, hfs oder JFS ohne Berücksichtigung der Groß- und Kleinschreibung für Ihre Anwendung in eine Schleife einbinden, um die Probleme mit der Groß- und Kleinschreibung zu umgehen (Loop-Mount wird in der Produktion nicht empfohlen).
Zusammenfassend
Derzeit (28.09.2016) würde ich mich von .NET Core (für Produktionszwecke) fernhalten. 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 wünschen, das unter Linux (x86 / AMD64 / ARMhf) sowie Windows und Mac funktioniert und 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 befindet sich in den Repositorys, die .deb wird problemlos installiert, der Quellcode wird kompiliert - ohne dass Änderungen erforderlich sind - und golang hat (in der Zwischenzeit) Debugging-Unterstützung mit delve und JetBrainsGogland unter Linux (und Windows und Mac). Golangs Erstellungsprozess (und Laufzeit) hängt auch nicht von NodeJS ab, was ein weiteres Plus ist.
Wenn es um Mono geht, halte dich davon fern.
Es ist geradezu erstaunlich, wie weit Mono gekommen ist, aber leider ist dies kein Ersatz für seine Leistungs- / Skalierbarkeits- und Stabilitätsprobleme bei Produktionsanwendungen.
Außerdem ist die Mono-Entwicklung ziemlich tot, sie entwickelt größtenteils nur noch die Teile, die für Android und iOS relevant sind, weil Xamarin dort ihr Geld verdient.
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 kommt eine Portierung jedoch weitgehend nicht in Frage. Die erforderlichen Änderungen sind enorm. Wenn Sie ein MVC-Projekt haben, kann die Anzahl der Änderungen überschaubar sein, wenn Ihr ursprüngliches Anwendungsdesign vernünftig war, was bei den meisten vorhandenen sogenannten "historisch gewachsenen" Anwendungen meist nicht der Fall ist.
Update vom Dezember 2016: Die
native Kompilierung wurde aus der .NET Core-Vorschau entfernt, da sie noch nicht fertig ist. Sie
scheint sich gegenüber dem Benchmark für Rohtextdateien ziemlich stark verbessert zu haben, ist aber andererseits ziemlich fehlerhaft geworden. Auch bei den JSON-Benchmarks hat es sich weiter verschlechtert. Es ist auch merkwürdig, dass das Entity-Framework für Updates schneller sein soll als Dapper - obwohl beide langsam sind. Dies ist sehr unwahrscheinlich. Es sieht so aus, als ob es noch mehr als nur ein paar Käfer zu jagen gibt.
Auch an der Linux-IDE-Front scheint es Erleichterung zu geben.
JetBrains veröffentlichte "Project Rider", eine frühzeitige Zugriffsvorschau einer C # /. NET Core IDE für Linux (sowie Mac und Windows), die Visual Studio Project-Dateien verarbeiten kann. Endlich eine C # IDE, die verwendbar ist und nicht so langsam wie die Hölle.
Fazit: .NET Core ist im März 2017 immer noch Qualitätssoftware vor der Veröffentlichung. Portieren Sie Ihre Bibliotheken, halten Sie sich jedoch für die Verwendung in der Produktion davon fern, bis sich die Framework-Qualität stabilisiert.
Und behalten Sie Project Rider im Auge.
Update 2017
Habe meine (Bruder-) Homepage vorerst auf .NET Core migriert.
Bisher scheint die Laufzeit unter Linux stabil genug zu sein (zumindest für kleine Projekte) - sie hat einen Auslastungstest problemlos überstanden - Mono hat dies nie getan.
Es sieht auch so aus, als hätte ich .NET-Core-native und .NET-Core-eigenständige Bereitstellung verwechselt. Die eigenständige Bereitstellung funktioniert, ist jedoch etwas unterdokumentiert, obwohl sie sehr einfach ist (die Build- / Publish-Tools sind etwas instabil, aber wenn Sie auf "Positive Nummer erforderlich. - Build FAILED" stoßen, führen Sie denselben Befehl erneut aus. 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
Hinweis: Gemäß .NET Core 3 können Sie alles, was minimiert ist, als einzelne Datei veröffentlichen :
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true
Im Gegensatz zu go handelt es sich jedoch nicht um eine statisch verknüpfte ausführbare Datei, sondern um eine selbstextrahierende Zip-Datei. Bei der Bereitstellung können daher Probleme auftreten, insbesondere wenn das temporäre Verzeichnis durch Gruppenrichtlinien oder andere Probleme gesperrt ist . Funktioniert jedoch gut für ein Hallo-Welt-Programm. Und wenn Sie nicht minimieren, wird die Größe der ausführbaren Datei bei etwa 100 MB liegen.
Außerdem erhalten Sie eine in sich geschlossene EXE-Datei (im Veröffentlichungsverzeichnis), die Sie ohne installiertes .NET Framework auf einen Windows 8.1-Computer verschieben und ausführen lassen können. Nett. Hier wird dotNET-Core gerade erst interessant. (Beachten Sie die Lücken, SkiaSharp funktioniert unter Windows 8.1 / Windows Server 2012 R2 [noch] nicht - das Ökosystem muss zuerst aufholen - aber interessanterweise stürzt der Skia-DLL-Load-Fail nicht den gesamten Server ab / Anwendung - damit 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.)
August 2017 Update
.NET Core 2.0 veröffentlicht.
Seien Sie vorsichtig - es kommt zu (großen) Änderungen bei der Authentifizierung ...
Auf der anderen Seite wurden die DataTable / DataAdaper / DataSet-Klassen und viele mehr zurückgebracht.
Bei Realized .NET Core fehlt noch die Unterstützung für Apache SparkSQL, da Mobius noch nicht portiert ist. Das ist schlecht, denn das bedeutet keine SparkSQL-Unterstützung für meinen IoT Cassandra Cluster, also keine Joins ...
Experimentelle ARM-Unterstützung (nur Laufzeit, kein SDK - schade für Entwickler auf meinem Chromebook - ich freue mich auf 2.1 oder 3.0).
PdfSharp wird jetzt experimentell auf .NET Core portiert.
JetBrains Fahrerverließ EAP. Sie können es jetzt zum Entwickeln und Debuggen von .NET Core unter Linux verwenden - bisher jedoch nur .NET Core 1.1, bis das Update für die Unterstützung von .NET Core 2.0 online geht.
Mai 2018 Update
.NET Core 2.1 steht kurz bevor. Möglicherweise wird dadurch die NTLM-Authentifizierung unter Linux behoben (die NTLM-Authentifizierung funktioniert unter Linux {und möglicherweise Mac} in .NET-Core 2.0 nicht mit mehreren Authentifizierungsheadern, 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 Vorschauversionen auf meinem Computer. Also warten.
v2.1 soll auch die Kompilierungszeiten erheblich verkürzen. Das wäre gut.
Beachten Sie außerdem, dass .NET Core unter Linux nur 64-Bit ist !
Es gibt keine x86-32-Version von .NET Core unter Linux und es wird auch keine geben .
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 per Ableitung nicht unter Manjaro (der derzeit mit Abstand beliebtesten Linux-Distribution), weil Arch Linux verwendet OpenSSL 1.1. Wenn Sie also Arch Linux verwenden, haben Sie kein Glück (auch mit Gentoo).
Bearbeiten:
Die neueste Version von .NET Core 2.2+ unterstützt OpenSSL 1.1. Sie können es also auf Arch oder (k) Ubuntu 19.04+ verwenden. Möglicherweise müssen Sie jedoch das .NET-Core-Installationsskript verwenden , da noch keine Pakete vorhanden sind.
Auf der Oberseite hat sich die Leistung definitiv verbessert:
.NET Core 3:
.NET-Core v 3.0 soll WinForms und WPF auf .NET-Core bringen.
Während WinForms und WPF .NET Core sind, werden WinForms und WPF in .NET-Core nur unter Windows ausgeführt, da WinForms / WPF die Windows-API verwendet.
Hinweis:
.NET Core 3.0 ist jetzt verfügbar (RTM), und WinForms und WPF werden unterstützt, jedoch nur für C # (unter Windows). Es gibt keinen WinForms-Core-Designer . Der Designer wird irgendwann ein Visual Studio-Update mitbringen. Die WinForms-Unterstützung für VB.NET wird nicht unterstützt , ist jedoch für 2020 für .NET 5.0 geplant .
PS:
echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1
Wenn Sie es unter Windows verwendet haben, haben Sie es wahrscheinlich nie gesehen:
Die .NET Core-Tools erfassen Nutzungsdaten, um Ihre Erfahrung zu verbessern.
Die Daten sind anonym und enthalten keine Befehlszeilenargumente.
Die Daten werden von Microsoft gesammelt und an die Community weitergegeben.
Sie können die Telemetrie deaktivieren, indem Sie eine Umgebungsvariable DOTNET_CLI_TELEMETRY_OPTOUT mit Ihrer bevorzugten Shell auf 1 setzen.
Weitere Informationen zu .NET Core-Tools finden Sie unter Telemetrie unter
https://aka.ms/dotnet-cli-telemetry .
Ich dachte, ich würde erwähnen, dass sich Monodevelop (auch bekannt als Xamarin Studio, Mono IDE oder Visual Studio Mac, wie es jetzt auf Mac heißt) recht gut entwickelt hat und in der Zwischenzeit weitgehend verwendbar ist.
JetBrains Rider (2018 EAP zu diesem Zeitpunkt) ist jedoch definitiv viel schöner und zuverlässiger (und der mitgelieferte Dekompiler ist lebenssicherer), dh wenn Sie .NET-Core unter Linux oder Mac entwickeln. MonoDevelop unterstützt Debug-StepThrough unter Linux in .NET Core jedoch nicht, da MS die Debugging-API-DLL nicht lizenziert (außer VisualStudio Mac ...). Sie können den Samsung-Debugger für .NET Core jedoch über die .NET Core-Debugger-Erweiterung für Samsung Debugger für MonoDevelop verwenden
Haftungsausschluss:
Ich verwende keinen Mac, daher kann ich nicht sagen, ob das, was ich hier geschrieben habe, auch für FreeBSD-Unix-basierte Mac 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 (ARM-64?) - basierten Prozessoren, sodass vieles, was derzeit für Mac gilt, in Zukunft (2020+) möglicherweise nicht mehr für Mac gilt.
Wenn ich schreibe "Mono ist ziemlich instabil und langsam", bezieht sich das Instabile auf WinFroms & WebForms-Anwendungen, insbesondere das Ausführen von Webanwendungen über Fastcgi oder mit XSP (in der 4.x-Version von Mono) sowie auf die XML-Serialisierung -Handhabung von Besonderheiten, und die ziemlich langsame bezieht sich auf WinForms und insbesondere auf reguläre Ausdrücke (ASP.NET-MVC verwendet auch reguläre Ausdrücke für das Routing).
Wenn ich über meine Erfahrungen mit Mono 2.x, 3.x und 4.x schreibe, bedeutet dies nicht unbedingt, dass diese Probleme bis jetzt oder zu dem Zeitpunkt, an dem Sie dies lesen, noch nicht gelöst wurden Es wurde behoben, dass es später keine Regression geben kann, die einen dieser Fehler / Funktionen wieder einführt. Das bedeutet auch nicht, dass Sie beim Einbetten der Mono-Laufzeit die gleichen Ergebnisse erzielen wie bei Verwendung der Mono-Laufzeit des (dev) -Systems. Dies bedeutet auch nicht, dass das Einbetten der Mono-Laufzeit (überall) unbedingt kostenlos ist.
Alles, was nicht unbedingt bedeutet, dass Mono für iOS oder Android ungeeignet ist oder dass es dort dieselben Probleme gibt. Ich verwende Mono nicht auf Android oder IOS, daher kann ich nichts über Stabilität, Benutzerfreundlichkeit, Kosten und Leistung auf diesen Plattformen sagen . Wenn Sie .NET unter Android verwenden, müssen Sie natürlich noch einige andere Kostenaspekte berücksichtigen, z. B. die Gewichtung der Xamarin-Kosten im Vergleich zu den Kosten und der Zeit für die Portierung des vorhandenen Codes 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 im Vergleich zu Windows identisch ist, und erwarten Sie nicht, dass das Android-Dateisystem die Groß- und Kleinschreibung nicht berücksichtigt, und erwarten Sie nicht, dass Windows-Schriftarten vorhanden sind .