Wat is het verschil tussen .NET Core en Mono?
Ik vond een verklaring op de officiële site waarin stond: “De code die ervoor is geschreven, is ook overdraagbaar over applicatie-stacks, zoals Mono.”
Mijn doel is om C#, LINQ, EF7 en Visual Studio te gebruiken om een website te maken die op Linux kan worden uitgevoerd/gehost.
Iemand vertelde me dat hij het “in Mono” wilde hebben, maar ik weet niet wat dat betekent. Ik weet dat ik .NET Core 1.0 wil gebruiken met de hierboven genoemde technologieën. Hij zei ook dat hij “snelle CGI” wilde gebruiken. Ik weet ook niet wat dat betekent.
Kun je me helpen om al deze termen te begrijpen en of mijn verwachtingen realistisch zijn?
Antwoord 1, autoriteit 100%
Necromanen.
Een echt antwoord geven.
Wat is het verschil tussen .Net Core en Mono?
.NET Coreis nu officieel de toekomst van .NET. Het begon grotendeels met een herschrijving van het ASP.NET MVC-framework en console-applicaties, waaronder natuurlijk ook serverapplicaties. (Omdat het Turing-compleet is en interop met C dll’s ondersteunt, zou je, als je dat absoluut zou willen, er ook je eigen desktop-applicaties mee kunnen schrijven, bijvoorbeeld via bibliotheken van derden zoals Avalonia, die een beetje erg basaal waren toen ik dit voor het eerst schreef, wat betekende dat je vrijwel beperkt was tot web- of serverdingen.) Er zijn API’s toegevoegd aan .NET Core, zozeer zelfs dat .NET Core na versie 3.1 naar versie 5.0 zal springen, bekend als .NET 5.0 zonder de “Core”, en dat zal dan de toekomst zijn van het .NET Framework . Wat vroeger het volledige .NET Framework was, zal een paar decennia in de onderhoudsmodus blijven hangen als Full .NET Framework 4.8.x, totdat het zal sterven (misschien komen er nog wat upgrades, maar ik betwijfel het). Met andere woorden, .NET Core is de toekomst van .NET en Full .NET Framework zal ga de weg van de Dodo/Silverlight/WindowsPhone.
Het belangrijkste punt van .NET Core, afgezien van ondersteuning voor meerdere platforms, is het verbeteren van de prestaties en het inschakelen van “native compilatie”/zelfstandige implementatie (zodat u geen .NET framework/VM hoeft te installeren op de doelmachine.
Aan de ene kant betekent dit docker.io-ondersteuning op Linux, en aan de andere kant is een op zichzelf staande implementatie nuttig bij “cloud-computing”, aangezien je dan gewoon elke versie van het dotnet-CORE-framework kunt gebruiken die je leuk vindt, en u hoeft zich geen zorgen te maken over welke versie(s) van het .NET-framework de sysadmin daadwerkelijk heeft geïnstalleerd.
Hoewel de .NET Core-runtime meerdere besturingssystemen en processors ondersteunt, is de SDK een ander verhaal. En hoewel de SDK meerdere besturingssystemen ondersteunt, wordt/was nog steeds aan ARM-ondersteuning voor de SDK gewerkt. .NET Core wordt ondersteund door Microsoft. Dotnet-Core kwam niet met WinForms of WPF of iets dergelijks.
- Vanaf versie 3.0 worden WinForms en WPF ook ondersteund door .NET Core, maar alleen op Windows en alleen door C#. Niet door VB.NET(VB.NET-ondersteuning gepland voor v5 in 2020). En er is geen Forms Designer in .NET Core: het wordt later geleverd met een Visual Studio-update, op een niet-gespecificeerd tijdstip.
- WebForms worden nog steeds niet ondersteund door .NET Core, en er zijn geen plannen om ze ooit te ondersteunen(Blazoris daarvoor de nieuweling).
- .NET Core wordt ook geleverd met System.Runtime, dat mscorelib vervangt.
- Vaak wordt .NET Core verward met NetStandard, wat een beetje een wrapper is rond System.Runtime/mscorelib (en enkele andere), waarmee u tegelijkertijd bibliotheken kunt schrijven die gericht zijn op .NET Core, Full .NET Framework en Xamarin (iOS/Android).
- de .NET Core SDK werkt/werkte niet op ARM, althans niet de laatste keer dat ik het controleerde.
“Het Mono-project”is veel ouder dan .NET Core .
Mono is Spaans en betekent aap, en als een zijdelingse opmerking, heeft de naam niets te maken met mononucleose (hint: je zou een lijst met personeel kunnen krijgen onder http://primaten.ximian.com /).
Mono werd in 2005 gestart door Miguel de Icaza (de man die GNOME – en een paar anderen) als implementatie van het .NET-framework voor Linux (XIMIAN / SUSE / NOVELL). Mono bevat webformulieren, winforms, mvc, olive en een ide genaamd monodevelop (weet ook als Xamarin Studio of Visual Studio Mac). Eigenlijk het equivalent van (OpenJDK) JVM en (OpenJDK) JDK / JRE (in tegenstelling tot Sun / Oracle JDK). U kunt het gebruiken om ASP.NET-WEBFORS + WINFORMS + ASP.NET-MVC-toepassingen te krijgen om aan Linux te werken.
Mono wordt ondersteund door Xamarin (de nieuwe bedrijfsnaam van wat vroeger XIMIAN was, toen ze zich richtten op de mobiele markt, in plaats van de Linux-markt), en niet door Microsoft.
(Omdat Xamarin door Microsoft werd gekocht, is dat technisch gezien [maar niet cultureel] Microsoft.)
Je krijgt meestal je C # -spullen om op mono te compileren, maar niet de VB.NET-dingen.
Mono mist een aantal geavanceerde functies, zoals WSE / WCF en WEBPARTS.
Veel van de mono-implementaties zijn onvolledig (bijv. Throw NotimplementedException in ECDSA-codering), buggy (bijv. ODBC / ADO.net met Firebird), zich anders gedraagt dan op .NET (bijvoorbeeld XML-serialisatie) of anderszins onstabiel (ASP.NET MVC) en onaanvaardbaar traag (regex). Op de positieve kant werkt de Mono Toolchain ook aan de arm.
Wat de .NET-kern betreft, wanneer ze een cross-platform zeggen, verwacht niet dat het cross-platform betekent dat u daadwerkelijk gewoon apt -et installeert .NET-kern op arm-Linux, zoals u kunt met elasticarch . Je moet het hele kader van de bron compileren.
Dat wil zeggen, als je die ruimte hebt (bijvoorbeeld op een chromebook, met een totaal van 16 tot 32 GB HD).
Het had ook vroeger problemen met incompatibiliteit met OpenSSL 1.1 en Libcurl.
Die zijn gerectificeerd in de nieuwste versie van .NET CORE versie 2.2.
Zoveel voor cross-platform.
Ik vond een verklaring op de officiële site die zei: “Code geschreven voor
Het is ook draagbaar over toepassingsstapels, zoals MONO “.
Zolang die code niet op WINAPI-gesprekken, Windows-DLL-Pinvookes, COM-COMPONENTS, een Case-Insensitive-bestandssysteem, is de standaard-systeemcodering (codepagina) en heeft geen directory-separator problemen, dat is correct. Echter, .NET kerncode werkt op .NET-kern, en niet op mono. Dus het mengen van de twee zullen moeilijk zijn. En aangezien Mono vrij onstabiel en langzaam is (voor webtoepassingen), zou ik het toch niet aanraden. Probeer beeldverwerking op .NET-kern, b.v. Webp of het verplaatsen van GIF of Multipage-TIFF of het schrijven van tekst op een afbeelding, u zult nastig worden verrast.
Opmerking:
Vanaf .NET Core 2.0 is er System.Drawing Common (Nuget), die
bevat het grootste deel van de functionaliteit van systeem. Het zou moeten zijn
min of meer functies compleet in .NET-CORE 2.1. Echter,
System.Drawing Comming gebruikt GDI +, en zal daarom niet werken aan Azure
(System.Dringing Libraries zijn beschikbaar in Azure Cloud Service
[In principe gewoon een VM], maar niet in Azure Web-app [in principe gedeeld
Hosting?])
Tot nu toe, System.Drawing Comming werkt prima op Linux / Mac, maar heeft problemen op iOS / Android – als het helemaal werkt, daar.
Vóór .NET Core 2.0, dat wil zeggen ergens midden februari 2017, kon je SkiaSharpgebruiken voor beeldvorming (voorbeeld)(dat kan nog steeds).
Na .net-core 2.0 zult u merken dat SixLabors ImageSharpde juiste keuze is, aangezien System.Drawing niet per se veilig is en veel potentiële of echte geheugenlekken heeft, daarom zou je GDI niet in webapplicaties moeten gebruiken; Merk op dat SkiaSharp een stuk sneller is dan ImageSharp, omdat het native-bibliotheken gebruikt (wat ook een nadeel kan zijn). Merk ook op dat hoewel GDI+ werkt op Linux & Mac, dat betekent niet dat het werkt op iOS/Android.
Code die niet is geschreven voor .NET (niet-Core) is niet overdraagbaar naar .NET Core.
Dit betekent dat als je wilt dat een niet-GPL C#-bibliotheek zoals PDFSharp PDF-documenten maakt (heel gewoon), je pech hebt (op dit moment)(niet meer). Laat staan ReportViewer-besturing, die gebruikmaakt van Windows-pInvokes (om te coderen, mcdf-documenten te maken via COM en om lettertype, tekens, tekenspatiëring, informatie over het insluiten van lettertypen te verkrijgen, tekenreeksen te meten en regelafbrekingen uit te voeren, en voor het daadwerkelijk tekenen van tiffs van acceptabele kwaliteit) , en draait niet eens op Mono op Linux
(Daar werk ik aan).
Ook is code geschreven in .NET Core niet overdraagbaar naar Mono, omdat Mono de .NET Core runtime-bibliotheken (tot nu toe) mist.
Mijn doel is om C#, LINQ, EF7, visual studio te gebruiken om een website te maken
die kan worden uitgevoerd/gehost in linux.
EF was in elke versie die ik tot nu toe heb geprobeerd zo verdomd traag (zelfs op zulke simpele dingen als één tafel met één linker-join), dat ik het nooit zou aanraden – ook niet op Windows.
Ik zou EF met name niet aanbevelen als je een database hebt met unieke beperkingen of varbinary/filestream/hiërarchyid-kolommen. (Ook niet voor schema-update.)
En ook niet in een situatie waarin DB-prestaties van cruciaal belang zijn (zeg 10+ tot 100+ gelijktijdige gebruikers).
Ook zal het draaien van een website/web-applicatie op Linux vroeg of laat betekenen dat je deze moet debuggen.
Er is geen ondersteuning voor foutopsporing voor .NET Core op Linux.(Niet meer, maar vereist JetBrains Rider.)
MonoDevelop biedt (nog) geen ondersteuning voor het debuggen van .NET Core-projecten.
Als je problemen hebt, sta je er alleen voor. U zult uitgebreide logboekregistratie moeten gebruiken.
Wees voorzichtig, houd er rekening mee dat uitgebreide logging uw schijf in een mum van tijd zal vullen, vooral als uw programma een oneindige lus of recursie binnengaat.
Dit is vooral gevaarlijk als uw web-app als root draait, omdat inloggen logfile-space vereist – als er geen vrije ruimte meer is, kunt u niet meer inloggen.
(Normaal gesproken is ongeveer 5% van de schijfruimte gereserveerd voor gebruiker root [ook bekend als administrator op Windows], dus de beheerder kan in ieder geval nog steeds inloggen als de schijf bijna vol is. Maar als uw applicaties als root draaien, is die beperking niet van toepassing op hun schijfgebruik, en dus kunnen hun logbestanden 100% van de resterende vrije ruimte gebruiken, dus zelfs de beheerder kan niet meer inloggen.)
Het is daarom beter om die schijf niet te versleutelen, dat wil zeggen, als u waarde hecht aan uw gegevens/systeem.
Iemand vertelde me dat hij wilde dat het “in Mono” zou zijn, maar ik weet het niet
wat dat betekent.
Het betekent ofwel dat hij geen .NET Core wil gebruiken, of hij wil gewoon C# gebruiken op Linux/Mac. Ik vermoed dat hij gewoon C# wil gebruiken voor een web-app op Linux. .NET Core is daarvoor de juiste keuze, als je het absoluut in C# wilt doen. Ga niet met “Mono proper”; op het eerste gezicht lijkt het in eerste instantie te werken – maar geloof me, je zult er spijt van krijgen omdat Mono’s ASP.NET MVC niet stabiel is wanneer je server langdurig draait (langer dan 1 dag) – je bent nu gewaarschuwd. Zie ook de referenties “niet voltooid” bij het meten van Mono-prestaties op de techempower-benchmarks.
Ik weet dat ik het .Net Core 1.0-framework met de technologieën wil gebruiken
heb ik hierboven vermeld. Hij zei ook dat hij “snelle cgi” wilde gebruiken. Ik weet het niet
wat dat ook betekent.
Het betekent dat hij een krachtige webserver met volledige functionaliteit wil gebruiken, zoals nginx (Engine-X), mogelijk Apache.
Dan kan hij mono/dotnetCore draaien met op virtuele naam gebaseerde hosting (meerdere domeinnamen op hetzelfde IP-adres) en/of load-balancing. Hij kan ook andere websites draaien met andere technologieën, zonder dat een ander poortnummer op de webserver nodig is. Het betekent dat je website op een fastcgi-server draait, en nginx stuurt alle webverzoeken voor een bepaald domein via het fastcgi-protocol door naar die server. Het betekent ook dat uw website in een fastcgi-pijplijn loopt en dat u voorzichtig moet zijn met wat u doet, b.v. u kunt HTTP 1.1 niet gebruiken bij het verzenden van bestanden.
Anders worden bestanden onleesbaar op de bestemming.
Zie ook hieren hier.
Tot slot:
.NET Core is op dit moment (2016-09-28) niet echt draagbaar, en ook niet echt cross-platform (met name de debug-tools).
Ook native-compilatie is niet eenvoudig, vooral voor ARM.
En voor mij ziet het er ook nog niet uit alsof de ontwikkeling “echt klaar” is.
Bijvoorbeeld System.Data.DataTable/DataAdaper.Update ontbreekt…
(niet meer met .NET Core 2.0)
Samen met de System.Data.Common.IDB* interfaces.(niet meer met .NET Core 1.1)
als er ooit één klasse was die vaak wordt gebruikt, zou DataTable/DataAdapter het zijn…
Ook het Linux-installatieprogramma (.deb) faalt, althans op mijn computer, en ik weet zeker dat ik niet de enige ben die dat probleem heeft.
Debug, misschien met Visual Studio Code, als je het op ARM kunt bouwen (het is me gelukt – volg de blogpost van Scott Hanselman NIET als je dat doet– er is een howto in de wiki van VS -Code op github), omdat ze het uitvoerbare bestand niet aanbieden.
Yeoman faalt ook. (Ik denk dat het iets te maken heeft met de nodejs-versie die je hebt geïnstalleerd – VS Code vereist één versie, Yeoman een andere… maar het zou op dezelfde computer moeten draaien. vrij zwak
Het maakt niet uit dat het moet worden uitgevoerd op de knooppuntversie die standaard op het besturingssysteem wordt geleverd.
Het maakt niet uit dat er in de eerste plaats geen afhankelijkheid van NodeJS zou moeten zijn.
Aan de Kestell-server wordt ook gewerkt.
En afgaand op mijn ervaring met het mono-project, betwijfel ik ten zeerste of ze ooit .NET Core op FastCGI hebben getest, of dat ze enig idee hebben wat FastCGI-ondersteuning betekent voor hun framework, laat staan dat ze het hebben getest om er zeker van te zijn dat “alles werkt “. Ik heb zojuist geprobeerd een fastcgi-applicatie te maken met .NET Core en ik realiseerde me net dat er geen FastCGI-bibliotheek is voor .NET Core “RTM”…
Dus als je .NET Core “RTM” achter nginx gaat draaien, kun je dit alleen doen door verzoeken te proxyen naar kestrell (die halfafgewerkte nodeJS-afgeleide webserver) – er is momenteel geen fastcgi-ondersteuning in .NET Core “RTM”, AFAIK. Aangezien er geen .net core fastcgi-bibliotheek en geen voorbeelden is, is het ook hoogst onwaarschijnlijk dat iemand het framework heeft getest om te controleren of fastcgi werkt zoals verwacht.
Ik twijfel ook aan de prestaties.
In de (voorlopige) techempower-benchmark (ronde 13)scoort aspnetcore-linux op 25% ten opzichte van de beste prestaties, terwijl vergelijkbare frameworks zoals Go (golang) scoren op 96,9% van de topprestaties (en dat is wanneer platte tekst wordt geretourneerd zonder alleen toegang tot het bestandssysteem ). .NET Core doet het iets beter op JSON-serialisatie, maar het ziet er ook niet aantrekkelijk uit (go bereikt 98,5% van piek, .NET core 65%). Dat gezegd hebbende, het kan onmogelijk slechter zijn dan “mono correct”.
Bovendien, aangezien het nog relatief nieuw is, zijn (nog) niet alle grote bibliotheken geporteerd, en ik betwijfel of sommige ervan ooit zullen worden geporteerd.
Ondersteuning voor beeldvorming is op zijn best ook twijfelachtig.
Gebruik in plaats daarvan BouncyCastle voor alles wat versleuteld is.
Kun je me helpen om al deze termen te begrijpen en of mijn verwachtingen
zijn realistisch?
Ik hoop dat ik je heb geholpen om meer betekenis te geven aan al deze termen.
Wat uw verwachtingen betreft:
Een Linux-toepassing ontwikkelen zonder iets van Linux af te weten, is in de eerste plaats een heel stom idee, en het zal ook op de een of andere manier op een of andere vreselijke manier mislukken. Dat gezegd hebbende, omdat Linux geen licentiekosten heeft, is het in principe een goed idee, MAAR ALLEEN ALS JE WEET WAT JE DOET.
Een applicatie ontwikkelen voor een platform waarop je je applicatie niet kunt debuggen, is een ander heel slecht idee.
Ontwikkelen voor fastcgi zonder te weten wat de gevolgen zijn, is nog zo’n heel slecht idee.
Al deze dingen doen op een “experimenteel” platform zonder enige kennis van de specifieke kenmerken van dat platform en zonder ondersteuning voor foutopsporing is zelfmoord, als uw project meer is dan alleen een persoonlijke startpagina. Aan de andere kant, ik denk dat het waarschijnlijk een heel goede ervaring zou zijn om het met je persoonlijke startpagina te doen voor leerdoeleinden – dan leer je wat het raamwerk en wat de niet-raamwerkproblemen zijn.
Je kunt bijvoorbeeld (programmatisch) een hoofdletterongevoelige fat32, hfs of JFS voor uw toepassing, om hoofdlettergevoeligheidsproblemen te omzeilen (lusmontage niet aanbevolen in productie).
Samenvattend
Op dit moment (2016-09-28), zou ik wegblijven van .NET Core (voor productiegebruik). Misschien kun je over een tot twee jaar nog eens kijken, maar waarschijnlijk niet eerder.
Als je een nieuw webproject hebt dat je ontwikkelt, start het dan in .NET Core, niet in mono.
Als je een framework wilt dat werkt op Linux (x86/AMD64/ARMhf) en Windows en Mac, dat geen afhankelijkheden heeft, d.w.z. alleen statische koppeling en geen afhankelijkheid van .NET, Java of Windows, gebruik dan Golang. Het is volwassener en de prestaties zijn bewezen (Baidu gebruikt het met 1 miljoen gelijktijdige gebruikers), en golang heeft een aanzienlijk lagere geheugenvoetafdruk. Ook staat golang in de repositories, de .deb installeert zonder problemen, de broncode compileert – zonder dat er wijzigingen nodig zijn – en golang heeft (in de tussentijd) debugging-ondersteuning met delve en JetBrains Goglandop Linux (en Windows en Mac). Het bouwproces (en runtime) van Golang is ook niet afhankelijk van NodeJS, wat nog een pluspunt is.
Wat mono betreft, blijf er vanaf.
Het is ronduit verbazingwekkend hoe ver mono is gekomen, maar helaas is dat geen vervanging voor de prestatie-/schaalbaarheids- en stabiliteitsproblemen voor productietoepassingen.
Bovendien is mono-ontwikkeling behoorlijk dood, ze ontwikkelen grotendeels alleen nog de onderdelen die relevant zijn voor Android en iOS, want daar verdient Xamarin hun geld mee.
Verwacht niet dat Web-Development een eersteklas Xamarin/mono-burger is.
.NET Core is misschien de moeite waard als je een nieuw project start, maar voor bestaande grote webformulierenprojecten is overzetten grotendeels uitgesloten, de vereiste veranderingen zijn enorm. Als je een MVC-project hebt, kan het aantal wijzigingen beheersbaar zijn, als je oorspronkelijke applicatieontwerp gezond was, wat meestal niet het geval is voor de meeste bestaande zogenaamde “historisch gegroeide” applicaties.
December 2016-update:
Native compilatie is verwijderd uit de .NET Core-preview, omdat deze nog niet klaar is…
Het lijkt erop dat ze behoorlijk sterk zijn verbeterd ten opzichte van de benchmark voor onbewerkte tekstbestanden, maar aan de andere kant is het behoorlijk buggy geworden. Ook verslechterde het verder in de JSON-benchmarks. Merkwaardig ook dat het entiteitskader sneller zal zijn voor updates dan Dapper – hoewel beide met een record traagheid. Het is zeer onwaarschijnlijk dat dit waar is. Het lijkt erop dat er nog steeds meer dan alleen een paar bugs zijn om op te jagen.
Er lijkt ook verlichting te komen op het Linux IDE-front.
JetBrains heeft “Project Rider” uitgebracht, een preview met vroege toegang van een C#/.NET Core IDE voor Linux (en Mac en Windows), die Visual Studio Project-bestanden aankan.
Eindelijk een C# IDE die bruikbaar is & dat is niet traag als de hel.
Conclusie: .NET Core is nog steeds pre-release kwaliteitssoftware terwijl we 2017 ingaan. Draag uw bibliotheken over, maar blijf er uit de buurt voor productiegebruik, totdat de kwaliteit van het framework zich stabiliseert.
En houd Project Rider in de gaten.
Update 2017
Heb de startpagina van mijn (broer) voorlopig naar .NET Core gemigreerd.
Tot dusverre lijkt de runtime op Linux stabiel genoeg (tenminste voor kleine projecten) – het overleefde met gemak een laadtest – mono deed het nooit.
Het lijkt er ook op dat ik .NET-Core-native en .NET-Core-self-contained-deployment door elkaar heb gehaald. Op zichzelf staande implementatie werkt, maar het is een beetje ondergedocumenteerd, hoewel het supergemakkelijk is (de tools voor bouwen/publiceren zijn een beetje onstabiel, maar – als je “Positief nummer vereist. – Build FAILED.” tegenkomt – voer je dezelfde opdracht opnieuw uit, en het werkt).
Je kunt rennen
dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64
Opmerking: volgens .NET Core 3 kunt u alles verkleindpubliceren als een één bestand:
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true
In tegenstelling tot go is het echter geen statisch gekoppeld uitvoerbaar bestand, maar een zelf-uitpakkend zip-bestand, dus bij het implementeren kunt u tegen
problemen, vooral als de tijdelijke map per groep is vergrendeld
beleid, of enkele andere problemen. Werkt prima voor een
hallo-wereld programma, dat wel. En als u niet verkleint, zal de grootte van het uitvoerbare bestand ongeveer 100 MB bedragen.
En je krijgt een op zichzelf staand .exe-bestand (in de publicatiemap), dat je naar een Windows 8.1-machine kunt verplaatsen zonder dat .NET-framework is geïnstalleerd en het vervolgens kunt laten draaien. Mooi hoor. Het is hier dat dotNET-Core net interessant begint te worden. (let op de hiaten, SkiaSharp werkt niet op Windows 8.1/ Windows Server 2012 R2, [nog] – het ecosysteem moet eerst inhalen – maar interessant is dat de Skia-dll-load-fail niet de hele server/applicatie crasht – dus al het andere werkt)
(Opmerking: SkiaSharp op Windows 8.1 mist de juiste VC runtime-bestanden – msvcp140.dll en vcruntime140.dll. Kopieer ze naar de publicatie-directory, en Skia zal werken op Windows 8.1.)
Update augustus 2017
.NET Core 2.0 uitgebracht.
Wees voorzichtig – komt met (enorme baanbrekende) wijzigingen in authenticatie…
Positief was dat het de klassen DataTable/DataAdaper/DataSet terugbracht, en nog veel meer.
Gerealiseerde .NET Core mist nog steeds ondersteuning voor Apache SparkSQL, omdat Mobiusnog niet is geporteerd. Dat is jammer, want dat betekent geen SparkSQL-ondersteuning voor mijn IoT Cassandra Cluster, dus geen joins…
Experimentele ARM-ondersteuning (alleen runtime, geen SDK – jammer voor ontwikkelwerk op mijn Chromebook – kijk uit naar 2.1 of 3.0).
PdfSharp is nu experimenteel overgezet naar .NET Core.
JetBrains Riderheeft EAP verlaten. U kunt het nu gebruiken om & debug .NET Core op Linux – maar tot nu toe alleen .NET Core 1.1 totdat de update voor .NET Core 2.0-ondersteuning live gaat.
Update van mei 2018
.NET Core 2.1-release aanstaande.
Misschien lost dit de NTLM-authenticatie op Linux op (NTLM-authenticatie werkt niet op Linux {en mogelijk Mac} in .NET-Core 2.0 met meerdere authenticatieheaders, zoals onderhandelen, meestal verzonden met ms-exchange, en ze zijn blijkbaar alleen repareren in v2.1, geen bugfix-release voor 2.0).
Maar ik installeer geen preview-versies op mijn computer. Wachten dus.
v2.1 zou ook de compileertijden aanzienlijk verkorten. Dat zou goed zijn.
Houd er ook rekening mee dat op Linux .NET Core alleen 64-bits is!
Er is geen, en er zal ook geen x86-32-versie van .NET Core op Linux zijn.
En de ARM-poort is alleen ARM-32. Nog geen ARM-64.
En op ARM heb je (momenteel) alleen de runtime, niet de dotnet-SDK.
En nog iets:
Omdat .NET-Core OpenSSL 1.0 gebruikt, draait .NET Core op Linux niet op Arch Linux, en door afleiding niet op Manjaro (veruit de meest populaire Linux-distro op dit moment), omdat Arch Linux OpenSSL 1.1 gebruikt. Dus als je Arch Linux gebruikt, heb je pech (ook met Gentoo ).
Bewerken:
De nieuwste versie van .NET Core 2.2+ ondersteunt OpenSSL 1.1. Dus je kunt gebruiken
het op Arch of (k)Ubuntu 19.04+. Mogelijk moet u de .NET-Core gebruiken
installeer echter script, omdat er nog geen pakketten zijn.
Aan de positieve kant zijn de prestaties zeker verbeterd:
.NET Core 3:
.NET-Core v 3.0 zou WinForms en WPF naar .NET-Core brengen.
Hoewel WinForms en WPF .NET Core zullen zijn, zullen WinForms en WPF in .NET-Core alleen op Windows draaien, omdat WinForms/WPF de Windows-API zal gebruiken.
Opmerking:
.NET Core 3.0 is nu uit (RTM), en er is ondersteuning voor WinForms en WPF, maar alleen voor C# (op Windows). Er is geen WinForms-Core-Designer. De ontwerper zal uiteindelijk ooit met een Visual Studio-update komen. WinForms-ondersteuning voor VB.NET wordt niet ondersteund, maar is gepland voor .NET 5.0 ergens in 2020.
PS:
echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1
Als je het op Windows hebt gebruikt, heb je dit waarschijnlijk nooit gezien:
De .NET Core-tools verzamelen gebruiksgegevens om uw
ervaring.
De gegevens zijn anoniem en bevatten geen opdrachtregel
argumenten.
De gegevens worden verzameld door Microsoft en gedeeld met de
gemeenschap.
U kunt zich afmelden voor telemetrie door a . in te stellen
DOTNET_CLI_TELEMETRY_OPTOUT omgevingsvariabele op 1 met uw
favoriete schelp.
U kunt meer lezen over telemetrie van .NET Core-tools @
https://aka.ms/dotnet-cli-telemetry.
Ik dacht even te vermelden dat ik denk dat monodevelop (ook bekend als Xamarin Studio, de Mono IDE of Visual Studio Mac zoals het nu op Mac wordt genoemd) behoorlijk is geëvolueerd en – in de tussentijd – grotendeels bruikbaar is.
JetBrains Rider (2018 EAP op dit moment) is echter zeker een stuk leuker en betrouwbaarder (en de meegeleverde decompiler is levensveiliger), dat wil zeggen, als je .NET-Core ontwikkelt op Linux of Mac. MonoDevelop biedt echter geen ondersteuning voor Debug-StepThrough op Linux in .NET Core, aangezien MS geen licentie geeft voor hun debugging API dll (behalve voor VisualStudio Mac … ). U kunt echter de Samsung debugger voor .NET Coregebruiken via de .NET Core debugger-extensie voor Samsung Debugger voor MonoDevelop
Disclaimer:
Ik gebruik geen Mac, dus ik kan niet zeggen of wat ik hier schreef ook van toepassing is op op FreeBSD-Unix gebaseerde Mac. Ik verwijs naar de Linux (Debian/Ubuntu/Mint) versie van JetBrains Rider, mono, MonoDevelop/VisualStudioMac/XamarinStudio en .NET-Core. Apple overweegt ook een overstap van Intel-processors naar zelf-gefabriceerde ARM(ARM-64?)-gebaseerde processors, dus veel van wat nu op Mac van toepassing is, zal in de toekomst (2020+) misschien niet op Mac van toepassing zijn.
Ook als ik schrijf “mono is behoorlijk onstabiel en traag”, heeft de onstabiele betrekking op WinFroms & WebForms-applicaties, met name het uitvoeren van webapplicaties via fastcgi of met XSP (op de 4.x-versie van mono), evenals eigenaardigheden van XML-serialisatieverwerking, en de vrij trage heeft betrekking op WinForms, en met name reguliere expressies (ASP .NET-MVC gebruikt ook reguliere expressies voor routering).
Als ik schrijf over mijn ervaring met mono 2.x, 3.x en 4.x, betekent dat ook niet noodzakelijk dat deze problemen nu niet zijn opgelost, of tegen de tijd dat je dit leest, noch dat als ze nu zijn opgelost, dat er later geen regressie kan zijn die een van deze bugs/functies opnieuw introduceert. Dat betekent ook niet dat als je de mono-runtime insluit, je dezelfde resultaten krijgt als wanneer je de mono-runtime van het (dev)systeem gebruikt. Het betekent ook niet dat het insluiten van de mono-runtime (overal) noodzakelijkerwijs gratis is.
Dat betekent niet noodzakelijk dat mono niet geschikt is voor iOS of Android, of dat het daar dezelfde problemen heeft. Ik gebruik geen mono op Android of IOS, dus ik ben niet in de positie om iets te zeggen over stabiliteit, bruikbaarheid, kostenen prestaties op deze platforms. Als je .NET op Android gebruikt, heb je natuurlijk ook andere kostenoverwegingen, zoals het wegen van xamarin-kosten versus kosten en tijd voor het overzetten van bestaande code naar Java. Men hoort mono op Android en IOS zal best goed zijn. Neem het met een korreltje zout. Ten eerste, verwacht niet dat de standaard systeemcodering hetzelfde is op Android/ios versus Windows, en verwacht niet dat het Android-bestandssysteem hoofdletterongevoelig is, en verwacht niet dat er Windows-lettertypen aanwezig zijn .
Antwoord 2, autoriteit 18%
In de .NET-wereld zijn er twee soorten CLR’s, “volledige” CLR’s en Core CLR’s, en dit zijn nogal verschillende dingen.
Er zijn twee “volledige” CLR-implementaties, de Microsoft native .NET CLR (voor Windows) en de Mono CLR (die zelf implementaties heeft voor Windows, Linux en Unix (Mac OS X en FreeBSD)). Een volledige CLR is precies dat – vrijwel alles wat u nodig heeft. Als zodanig zijn “volledige” CLR’s meestal groot van formaat.
Core CLR’s zijn daarentegen kleiner en veel kleiner. Omdat ze slechts een kernimplementatie zijn, is het onwaarschijnlijk dat ze alles hebben wat u nodig hebt, dus met Core CLR’s voegt u functiesets toe aan de CLR die uw specifieke softwareproduct gebruikt, met behulp van NuGet. Er zijn Core CLR-implementaties voor Windows, Linux (diverse) en Unix (Mac OS X en FreeBSD) in de mix. Microsoft heeft de .NET-frameworkbibliotheken voor Core CLR ook herschikt of is deze aan het herstructureren om ze draagbaarder te maken voor de kerncontext. Gezien de aanwezigheid van mono op *nix-besturingssystemen zou het een verrassing zijn als de Core CLR’s voor *nix geen mono-codebasis zouden bevatten, maar alleen de Mono-gemeenschap en Microsoft konden ons dat zeker vertellen.
Ook ben ik het met Nico eens dat Core CLR’s nieuw zijn — het is op dit moment bij RC2 denk ik. Ik zou er nog niet afhankelijk van zijn voor productiecode.
Om je vraag te beantwoorden zou je je site op Linux kunnen leveren met Core CLR of Mono, en dit zijn twee verschillende manieren om dit te doen. Als je nu een veilige gok wilt, zou ik voor mono op linux gaan, en als je dat later wilt porteren, naar Core.
Antwoord 3, autoriteit 5%
Je hebt niet alleen een realistisch pad gekozen, maar misschien wel een van de beste ecosystemen die sterk worden ondersteund (ook X-platforms) door MS. Toch moet u de volgende punten overwegen:
- Update: het hoofddocument over de .Net-platformstandaard is hier: https ://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
- Update: huidige Mono 4.4.1 kan de nieuwste Asp.Net core 1.0 RTM niet uitvoeren
- Hoewel mono meer complete functies heeft, is de toekomst onduidelijk, omdat MS het al enkele maanden in bezit heeft en het een duplicaat is voor hen om het te ondersteunen. Maar MS zet zich absoluut in voor .Net Core en zet er veel op in.
- Hoewel .Net core is uitgebracht, is het ecosysteem van derden er nog niet helemaal. Nhibernate, Umbraco etc kunnen bijvoorbeeld nog niet over .Net core heen lopen. Maar ze hebben een plan.
- Er ontbreken enkele functies in .Net Core, zoals System.Drawing, u moet zoeken naar bibliotheken van derden
- Je moet nginx gebruiken als frontserver met kestrelserver voor asp.net-apps, omdat kestrelserver nog niet helemaal klaar is voor productie. HTTP/2 is bijvoorbeeld niet geïmplementeerd.
Ik hoop dat het helpt
Antwoord 4, autoriteit 4%
.Net Core vereist geen mono in de zin van het mono-framework. .Net Core is een framework dat op meerdere platforms werkt, waaronder Linux. Referentie https://dotnet.github.io/.
De .Net-kern kan echter het mono-framework gebruiken. Referentie https://docs. asp.net/en/1.0.0-rc1/getting-started/choosing-the-right-dotnet.html(let op rc1 documentatie geen rc2 beschikbaar), maar monois geen Door Microsoft ondersteund framework en raadt het gebruik van een ondersteund framework aan
Entity Framework 7 heet nu Entity Framework Coreen is beschikbaar op meerdere platforms, waaronder Linux. Referentie https://github.com/aspnet/EntityFramework(bekijk de routekaart)
Ik gebruik momenteel beide frameworks, maar je moet begrijpen dat het zich nog in de fase van de kandidaat-release bevindt (RC2is de huidige versie) en over de bèta- & release kandidaten zijn er enorme veranderingen geweest die er meestal toe leiden dat je je hoofd krabt.
Hier is een tutorial over hoe je MVC .Net Core in Linux installeert. https://docs.asp.net /nl/1.0.0-rc1/aan de slag/installatie-op-linux.html
Eindelijk heb je de keuze uit webservers (waar ik aanneem dat de referentie fast cgivandaan kwam) om je applicatie op Linux te hosten. Hier is een referentiepunt voor installatie in een Linux-omgeving. https://docs.asp.net/en/1.0.0 -rc1/publishing/linuxproduction.html
Ik realiseer me dat dit bericht meestal links naar documentatie is, maar op dit moment zijn dit je beste informatiebronnen. .Net core is nog relatief nieuw in de .Net-gemeenschap en tot het volledig is uitgebracht, zou ik aarzelen om het in een productomgeving te gebruiken, gezien de grote veranderingen tussen de uitgebrachte versies.
Antwoord 5, autoriteit 4%
Dit is niet meer .NET Core versus Mono. Het is verenigd.
Update vanaf november 2020– .NET 5 uitgebracht die .NET Framework en .NET Core verenigt
.NET en Mono worden verenigd onder .NET 6 dat in november 2021 zou worden uitgebracht
- .NET 6.0 voegt
net6.0-iosennet6.0-androidtoe. - De OS-specifieke namen kunnen versienummers van het besturingssysteem bevatten, zoals
net6.0-ios14.
Bekijk onderstaande artikelen:
- https://devblogs.microsoft.com/dotnet /introducing-net-multi-platform-app-ui/
- https://github.com/dotnet/maui
Antwoord 6, autoriteit 3%
Deze vraag is vooral actueel omdat gisteren Microsoft officieel heeft de release van .NET Core 1.0 aangekondigd. Ervan uitgaande dat Mono de meeste standaard .NET-bibliotheken implementeert, kan het verschil tussen Mono en .NET core worden gezien door het verschil tussen .NET Framework en .NET Core:
- API’s — .NET Core bevat veel van dezelfde, maar minder, API’s als het .NET Framework, en met een andere factoring (assemblagenamen zijn
verschillend; typevorm verschilt in belangrijke gevallen). Deze verschillen
vereisen momenteel doorgaans wijzigingen in de poortbron naar .NET Core. .NETTO
Core implementeert de .NET Standard Library API, die zal uitgroeien tot
in de loop van de tijd meer van de .NET Framework BCL API’s opnemen.- Subsystemen — .NET Core implementeert een subset van de subsystemen in het .NET Framework, met als doel een eenvoudigere implementatie en
programmeermodel. Code Access Security (CAS) is bijvoorbeeld niet
ondersteund, terwijl reflectie wordt ondersteund.
Als je snel iets moet lanceren, ga dan voor Mono omdat het momenteel (juni 2016) een volwassener product is, maar als je een website voor de lange termijn bouwt, raad ik .NET Core aan. Het wordt officieel ondersteund door Microsoft en het verschil in ondersteunde API’s zal waarschijnlijk binnenkort verdwijnen, rekening houdend met de inspanning die Microsoft steekt in de ontwikkeling van .NET Core.
Mijn doel is om C#, LINQ, EF7, visual studio te gebruiken om een website te maken
die kan worden uitgevoerd/gehost in linux.
Linq en Entity Framework zijn opgenomen in .NET Core, dus u zijn veilig om een foto te maken.
Antwoord 7, autoriteit 3%
Om het simpel te houden,
Mono is een externe implementatie van .Net-framework voor
Linux/Android/iO’s.Net Core is Microsofts eigen implementatie hiervoor.
.Net Core is de toekomst. en Mono zal uiteindelijk dood zijn. Dat gezegd hebbende, is .Net Core niet volwassen genoeg. Ik worstelde om het te implementeren met IBM Bluemix en liet het idee later vallen. Na verloop van tijd (kan 1-2 jaar zijn), zou het beter moeten zijn.
Antwoord 8
Dit is een van mijn favoriete onderwerpen en de inhoud hier was gewoon geweldig. Ik zat te denken of het de moeite waard of effectief zou zijn om de beschikbare methoden in Runtime versus Mono te vergelijken. Ik hoop dat ik mijn voorwaarden goed heb, maar ik denk dat je begrijpt wat ik bedoel. Zou het zinvol zijn om de methoden die ze bieden te vergelijken, om een wat beter begrip te krijgen van wat elke Runtime momenteel ondersteunt? Ik realiseer me dat implementaties kunnen verschillen, en ik heb geen rekening gehouden met de Framework Class-bibliotheken of de vele andere bibliotheken die beschikbaar zijn in de ene omgeving versus de andere. Ik realiseer me ook dat iemand dit werk misschien al efficiënter heeft gedaan. Ik zou het zeer op prijs stellen als u me dit zou laten weten, zodat ik het kan beoordelen. Ik denk dat het van waarde zou zijn om een verschil te maken tussen de resultaten van dergelijke activiteiten, en ik wilde zien hoe meer ervaren ontwikkelaars erover denken en of ze nuttige begeleiding zouden bieden. Terwijl ik terug speelde met reflectie, schreef ik enkele regelsdie de .net-directory doorkruisen, en maak een lijst van de samenstellingen.
Antwoord 9
In een notendop:
Mono = Compiler voor C#
Mono Ontwikkelen = Compiler+IDE
.Net Core = ASP-compiler
De huidige case voor .Net Core is alleen web zodra het een open winform-standaard en bredere taalacceptatie toepast, zou het eindelijk de Microsoft-killer dev-krachtpatser kunnen zijn. Gezien Oracle’s recente verhuizing naar Java-licentie, heeft Microsoft een enorme tijd om te schitteren.