Nekromancja.
Udzielenie rzeczywistej odpowiedzi.
Jaka jest różnica między .Net Core a Mono?
.NET Core to teraz oficjalnie przyszłość .NET. Zaczęło się w dużej mierze od ponownego zapisu frameworka ASP.NET MVC i aplikacji konsolowych, które oczywiście obejmują aplikacje serwerowe. (Ponieważ jest kompletny z Turinga i obsługuje współdziałanie z bibliotekami dll C, możesz, jeśli absolutnie chcesz, również pisać z nim własne aplikacje komputerowe, na przykład za pośrednictwem bibliotek zewnętrznych, takich jak Avalonia, które były trochę bardzo proste w momencie, gdy to napisałem, co oznaczało, że ograniczałeś się do stron WWW lub serwera.) Z biegiem czasu wiele interfejsów API zostało dodanych do .NET Core, tak bardzo, że po wersji 3.1, .NET Core przejdzie do wersji 5.0, znanej jako .NET 5.0 bez „Core”, i wtedy będzie to przyszłość .NET Framework. To, co kiedyś było pełną wersją .NET Framework, pozostanie w trybie konserwacji jako Pełna .NET Framework 4.8.x przez kilka dekad, aż do śmierci (być może nadal będą jakieś aktualizacje, ale wątpię). Innymi słowy, .NET Core jest przyszłością platformy .NET, a pełna .NET Framework pójdzie drogą Dodo / Silverlight / WindowsPhone .
Głównym celem platformy .NET Core, oprócz obsługi wielu platform, jest poprawa wydajności i umożliwienie „natywnej kompilacji” / samodzielnego wdrażania (więc nie trzeba instalować platformy .NET Framework / VM na komputerze docelowym .
z jednej strony oznacza to docker.io wsparcie na Linuksie, a po drugiej, samowystarczalnego rozmieszczenia jest przydatna w „cloud computing”, ponieważ wtedy można po prostu użyć niezależnie od wersji ramach dotnet-Core chcesz, i nie musisz się martwić, które wersje systemu .NET faktycznie zainstalował sysadmin.
Chociaż środowisko wykonawcze .NET Core obsługuje wiele systemów operacyjnych i procesorów, SDK to inna historia. I chociaż zestaw SDK obsługuje wiele systemów operacyjnych, obsługa ARM dla zestawu SDK jest / była w toku. .NET Core jest obsługiwany przez Microsoft. Dotnet-Core nie był dostarczany z WinForms, WPF lub czymkolwiek podobnym.
- Począwszy od wersji 3.0, WinForms i WPF jest również obsługiwany przez .NET Core, ale tylko w systemie Windows i tylko przez C #. Nie przez VB.NET (wsparcie VB.NET planowane dla wersji 5 w 2020 roku). W programie .NET Core nie ma produktu Forms Designer: jest on dostarczany z aktualizacją Visual Studio później, w nieokreślonym czasie.
- Formaty internetowe nadal nie są obsługiwane przez platformę .NET Core i nigdy nie planuje się ich obsługiwać ( Blazor jest nowym dzieckiem w mieście).
- .NET Core zawiera także System.Runtime, który zastępuje mscorelib.
- Często .NET Core jest mieszany z NetStandard , który jest trochę otulaczem System.Runtime / mscorelib (i niektórych innych), który pozwala pisać biblioteki, które są ukierunkowane na .NET Core, Full .NET Framework i Xamarin (iOS / Android), wszystkie jednocześnie.
- .NET Core SDK nie działa / nie działa na ARM, przynajmniej nie ostatnim razem, gdy sprawdzałem.
„Projekt Mono ” jest znacznie starszy niż .NET Core.
Mono jest Hiszpanem i oznacza Małpę, a na marginesie nazwa nie ma nic wspólnego z mononukleozą (wskazówka: listę pracowników można znaleźć pod adresem http://primates.ximian.com /).
Mono zostało uruchomione w 2005 roku przez Miguela de Icazę (gościa, który założył GNOME - i kilka innych) jako implementacja .NET Framework dla Linuxa (Ximian / SuSe / Novell). Mono obejmuje Web-Forms, Winforms, MVC, Olive oraz IDE o nazwie MonoDevelop(znany również jako Xamarin Studio lub Visual Studio Mac). Zasadniczo odpowiednik JVM (OpenJDK) i JDK / JRE (OpenJDK) (w przeciwieństwie do JDK SUN / Oracle). Możesz go użyć, aby aplikacje ASP.NET-WebForms + WinForms + ASP.NET-MVC działały w systemie Linux.
Mono jest obsługiwany przez Xamarin (nowa nazwa firmy, która była Ximian, kiedy koncentrowali się na rynku mobilnym, a nie na rynku Linux), a nie przez Microsoft.
(ponieważ Xamarin został kupiony przez Microsoft, to technicznie [ale nie kulturowo] Microsoft.)
Zwykle możesz dostać swoje C # kompilować na mono, ale nie VB.NET.
Mono brakuje niektórych zaawansowanych funkcji, takich jak WSE / WCF i WebParts.
Wiele implementacji Mono jest niekompletnych (np. Wyrzucenie NotImplementedException w szyfrowaniu ECDSA), błędnych (np. ODBC / ADO.NET z Firebird), zachowują się inaczej niż w .NET (na przykład serializacja XML) lub w inny sposób niestabilny (ASP.NET MVC) i niedopuszczalnie wolny (Regex). Z drugiej strony łańcuch narzędzi Mono działa również na ARM.
Jeśli chodzi o platformę .NET Core, kiedy mówią, że jest ona wieloplatformowa, nie oczekuj, że międzyplatformowa oznacza, że możesz po prostu apt-get zainstalować .NET Core na ARM-Linux, podobnie jak w przypadku ElasticSearch. Będziesz musiał skompilować cały framework ze źródła.
To znaczy, jeśli masz to miejsce (np. Na Chromebooku, który ma 16 do 32 GB całkowitego HD).
Miał również problemy z niekompatybilnością z OpenSSL 1.1 i libcurl.
Zostały one naprawione w najnowszej wersji .NET Core w wersji 2.2.
Tyle o wielu platformach.
Na oficjalnej stronie znalazłem stwierdzenie: „Napisany dla niego kod jest również przenośny w stosach aplikacji, takich jak Mono”.
Dopóki ten kod nie opiera się na wywołaniach WinAPI, Windows-dll-pinvokes, COM-Components, systemie plików bez rozróżniania wielkości liter, domyślnym kodowaniu systemu (stronie kodowej) i nie ma problemów z separatorem katalogów, poprawny. Jednak kod .NET Core działa na .NET Core, a nie na Mono. Mieszanie tych dwóch będzie trudne. A ponieważ Mono jest dość niestabilny i wolny (dla aplikacji internetowych), i tak nie poleciłbym go. Spróbuj przetwarzania obrazu na rdzeniu .NET, np. WebP lub przenoszenie GIF-a lub wielostronicowego tiffa lub pisanie tekstu na obrazie, będziesz bardzo zdziwiony.
Uwaga:
od wersji .NET Core 2.0 dostępna jest System.Drawing.Common (NuGet), która zawiera większość funkcji System.Drawing. Powinien on być mniej więcej kompletny z funkcjami w .NET-Core 2.1. Jednak System.Drawing.Common używa GDI +, a zatem nie będzie działać na Azure (System.Drawing biblioteki są dostępne w chmurze Azure Służby [zasadzie tylko VM], ale nie w Azure Web App [zasadzie dzielonego hostingu?])
Tak daleko System.Drawing.Common działa dobrze na Linux / Mac, ale ma problemy na iOS / Android - jeśli w ogóle działa, tam.
Przed wersją .NET Core 2.0, czyli mniej więcej w połowie lutego 2017 r., Możesz używać SkiaSharp do obrazowania (przykład) (nadal możesz).
Po .net-core 2.0 zauważysz, że SixLabors ImageSharpjest droga, ponieważ System.Drawing nie jest koniecznie bezpieczny i ma wiele potencjalnych lub rzeczywistych wycieków pamięci, dlatego nie powinieneś używać GDI w aplikacjach internetowych; Zauważ, że SkiaSharp jest znacznie szybszy niż ImageSharp, ponieważ korzysta z bibliotek natywnych (co może być również wadą). Pamiętaj też, że chociaż GDI + działa w systemach Linux i Mac, nie oznacza to, że działa w systemach iOS / Android.
Kod niepisany dla platformy .NET (innej niż Core) nie jest przenośny na platformę .NET Core.
Oznacza to, że jeśli chcesz tworzyć dokumenty PDF w bibliotece innej niż GPL C #, jak PDFSharp (bardzo powszechne), nie masz szczęścia(w tym momencie)( już nie ). Nie wspominając o formancie ReportViewer, który wykorzystuje Windows-pInvokes (do szyfrowania, tworzenia dokumentów mcdf przez COM i do uzyskiwania czcionek, znaków, kerningu, informacji o osadzaniu czcionek, mierzenia ciągów i dzielenia linii oraz do rysowania tiffów o akceptowalnej jakości) i nawet nie działa na Mono w systemie Linux
( pracuję nad tym ).
Ponadto kod napisany w .NET Core nie jest przenośny dla Mono, ponieważ Mono nie ma bibliotek środowiska uruchomieniowego .NET Core (jak dotąd).
Moim celem jest użycie C #, LINQ, EF7, visual studio do stworzenia strony internetowej, którą można uruchomić / hostować w systemie Linux.
EF w każdej wersji, którą próbowałem do tej pory, był tak cholernie powolny (nawet przy tak prostych rzeczach, jak jeden stół z jednym lewym złączeniem), nie polecałbym tego nigdy - nie w systemie Windows.
Szczególnie nie polecałbym EF, jeśli masz bazę danych z unikalnymi ograniczeniami lub kolumny varbinary / filestream / hierarchyid. (Nie dotyczy to także aktualizacji schematu.)
A także nie w sytuacji, w której wydajność DB jest krytyczna (powiedzmy od 10+ do 100 + równoczesnych użytkowników).
Ponadto uruchomienie witryny / aplikacji internetowej w systemie Linux prędzej czy później oznacza, że będziesz musiał ją debugować.
W systemie Linux nie ma obsługi debugowania .NET Core.(Już nie, ale wymaga JetBrains Rider.)
MonoDevelop nie obsługuje (jeszcze) debugowania projektów .NET Core.
Jeśli masz problemy, jesteś sam. Będziesz musiał korzystać z obszernego logowania.
Zachowaj ostrożność, pamiętaj, że obszerne logowanie zapełni Twój dysk w krótkim czasie, szczególnie jeśli Twój program wejdzie w nieskończoną pętlę lub rekurencję.
Jest to szczególnie niebezpieczne, jeśli twoja aplikacja internetowa działa jako root, ponieważ logowanie wymaga przestrzeni plików dziennika - jeśli nie pozostanie wolne miejsce, nie będziesz już mógł się zalogować.
(Zwykle około 5% miejsca na dysku jest zarezerwowane dla użytkownika root [inaczej administrator w systemie Windows], więc przynajmniej administrator nadal może się zalogować, jeśli dysk jest prawie pełny. Ale jeśli aplikacje działają jako root, to ograniczenie nie dotyczy ich użycie dysku, dzięki czemu ich pliki dziennika mogą zużyć 100% pozostałego wolnego miejsca, więc nawet administrator nie może się zalogować.)
Dlatego lepiej nie szyfrować tego dysku, to znaczy, jeśli cenisz swoje dane / system.
Ktoś powiedział mi, że chciał, aby było to „w mono”, ale nie wiem, co to znaczy.
Oznacza to, że albo nie chce używać .NET Core, albo po prostu chce używać C # na Linux / Mac. Domyślam się, że chce po prostu używać C # dla aplikacji sieci Web w systemie Linux. .NET Core jest na to dobrym sposobem, jeśli absolutnie chcesz to zrobić w C #. Nie idź z „Mono właściwy”; na pierwszy rzut oka wydaje się, że na początku działa - ale wierzcie mi, że będziecie tego żałować, ponieważ Mono's ASP.NET MVC nie jest stabilny, gdy serwer działa długo (dłużej niż 1 dzień) - teraz zostałeś ostrzeżony. Zobacz także odniesienia „nie ukończono” podczas pomiaru wydajności mono w testach wydajności techempower.
Wiem, że chcę korzystać z .Net Core 1.0 z technologiami wymienionymi powyżej. Powiedział także, że chce użyć „szybkiego cgi”. Nie wiem też, co to znaczy.
Oznacza to, że chce skorzystać z wydajnego, w pełni funkcjonalnego serwera WWW, takiego jak nginx (Engine-X), być może Apache.
Następnie może uruchomić mono / dotnetCore z wirtualnym hostingiem opartym na nazwach (wiele nazw domen w tym samym adresie IP) i / lub równoważenie obciążenia. Może także uruchamiać inne strony internetowe z innymi technologiami, nie wymagając innego numeru portu na serwerze WWW. Oznacza to, że twoja strona działa na serwerze fastcgi, a nginx przekazuje wszystkie żądania sieciowe dla określonej domeny za pośrednictwem protokołu fastcgi na ten serwer. Oznacza to również, że twoja strona działa w potoku fastcgi i musisz uważać, co robisz, np. Nie możesz używać HTTP 1.1 podczas przesyłania plików.
W przeciwnym razie pliki zostaną zniekształcone w miejscu docelowym.
Zobacz także tutaj i tutaj .
Podsumowując:
.NET Core obecnie (28.09.2016) nie jest tak naprawdę przenośny, ani nie jest tak naprawdę wieloplatformowy (w szczególności narzędzia do debugowania).
Kompilacja natywna nie jest łatwa, szczególnie dla ARM.
I dla mnie nie wygląda jeszcze na to, żeby jego rozwój był „naprawdę skończony”.
Na przykład brakuje System.Data.DataTable / DataAdaper.Update ...
(już nie w .NET Core 2.0)
Wraz z interfejsami System.Data.Common.IDB *.(już nie z .NET Core 1.1)
jeśli kiedykolwiek była jedna klasa, która jest często używana, DataTable / DataAdapter to byłaby ...
Także instalator Linuksa (.deb) zawodzi, przynajmniej na moim komputerze, a ja ' Jestem pewien, że nie tylko ja mam ten problem.
Debuguj, być może za pomocą Visual Studio Code, jeśli możesz zbudować go na ARM (udało mi się to - NIE postępuj zgodnie z postem Scotta Hanselmana, jeśli to zrobisz - na wiki VS-Code znajduje się howto), ponieważ nie oferują plików wykonywalnych.
Yeoman też zawodzi. (Wydaje mi się, że ma to coś wspólnego z zainstalowaną wersją nodejs - VS Code wymaga jednej wersji, Yeoman innej ... ale powinien działać na tym samym komputerze. Dość kiepski
Nieważne, że powinien działać na domyślnej wersji węzła dostarczanej domyślnie w systemie operacyjnym.
Nieważne, że w pierwszej kolejności nie powinno być zależności od NodeJS.
Serwer Kestell również trwa.
Sądząc z mojego doświadczenia z monoprojektem, bardzo wątpię, czy kiedykolwiek testowali .NET Core na FastCGI, czy też mają jakieś pojęcie, co oznacza wsparcie FastCGI dla ich frameworka, nie mówiąc już o tym, że przetestowali go, aby upewnić się, że „wszystko działa” „. W rzeczywistości właśnie próbowałem stworzyć aplikację fastcgi z .NET Core i po prostu zdałem sobie sprawę, że nie ma biblioteki FastCGI dla .NET Core „RTM” ...
Więc jeśli zamierzasz uruchomić .NET Core „RTM” za nginx, możesz to zrobić tylko przez proxy zapytań do Kestrella (tego półproduktu serwera WWW pochodzącego z węzła JS) - w .NET Core nie ma obecnie obsługi fastcgi „RTM”, AFAIK. Ponieważ nie ma biblioteki fastcgi z rdzeniem .net i nie ma próbek, jest bardzo mało prawdopodobne, aby ktokolwiek przeprowadzał jakiekolwiek testy w ramach, aby upewnić się, że fastcgi działa zgodnie z oczekiwaniami.
Kwestionuję również wydajność.
W (wstępnym) techempower-benchmarku (runda 13) aspnetcore-linux plasuje się na 25% w stosunku do najlepszej wydajności, podczas gdy porównywalne frameworki, takie jak Go (golang), osiągają 96,9% maksymalnej wydajności (i to w przypadku zwracania tekstu jawnego bez pliku - tylko dostęp do systemu). .NET Core radzi sobie nieco lepiej w serializacji JSON, ale też nie wygląda przekonująco (go osiąga 98,5% wartości szczytowej, .NET core 65%). To powiedziawszy, nie może być gorsze niż „mono właściwe”.
Ponadto, ponieważ wciąż jest stosunkowo nowy, nie wszystkie główne biblioteki zostały już przeniesione (jeszcze) i wątpię, aby niektóre z nich kiedykolwiek zostały przeniesione.
Obsługa obrazowania jest również w najlepszym razie wątpliwa.
Do dowolnego szyfrowania użyj zamiast tego BouncyCastle.
Czy możesz mi pomóc zrozumieć wszystkie te warunki i czy moje oczekiwania są realistyczne ?
Mam nadzieję, że pomogłem Ci w zrozumieniu tych wszystkich warunków.
Jeśli chodzi o twoje oczekiwania:
opracowanie aplikacji dla Linuksa bez wiedzy na temat Linuksa to przede wszystkim naprawdę głupi pomysł, ale w jakiś sposób może zawieść w jakiś okropny sposób. To powiedziawszy, ponieważ Linux nie wiąże się z żadnymi kosztami licencyjnymi, jest to zasadniczo dobry pomysł, ALE TYLKO JEŚLI WIESZ, CO ROBISZ.
Opracowanie aplikacji na platformę, na której nie można debugować aplikacji, to kolejny naprawdę zły pomysł.
Rozwój dla fastcgi bez wiedzy o konsekwencjach to kolejny naprawdę zły pomysł.
Robienie tych wszystkich rzeczy na „eksperymentalnej” platformie bez znajomości specyfiki tej platformy i bez wsparcia debugowania jest samobójstwem, jeśli twój projekt jest czymś więcej niż tylko osobistą stroną główną. Z drugiej strony, myślę, że robienie tego z osobistą stroną główną w celach edukacyjnych byłoby prawdopodobnie bardzo dobrym doświadczeniem - wtedy dowiesz się, jakie są ramy i jakie są problemy niezwiązane z ramami.
Możesz na przykład (programowo) zamontować w pętli niewymagający wielkości liter fat32, hfs lub JFS dla swojej aplikacji, aby obejść problemy z rozróżnianiem wielkości liter (montowanie w pętli nie jest zalecane w produkcji).
Podsumowując
Obecnie (2016-09-28) trzymałbym się z dala od .NET Core (do użytku produkcyjnego). Być może za rok lub dwa możesz rzucić okiem, ale prawdopodobnie nie wcześniej.
Jeśli masz nowy projekt internetowy, który opracowujesz, uruchom go w .NET Core, a nie mono.
Jeśli potrzebujesz frameworka działającego w systemie Linux (x86 / AMD64 / ARMhf) oraz Windows i Mac, który nie ma żadnych zależności, tj. Tylko statyczne łączenie i brak zależności od .NET, Java lub Windows, użyj zamiast niego Golanga. Jest bardziej dojrzały, a jego wydajność została udowodniona (Baidu używa go z 1 milionem równoczesnych użytkowników), a golang ma znacznie mniejszą pamięć. Również golang znajduje się w repozytoriach, .deb instaluje się bez problemów, kod źródłowy kompiluje - bez konieczności zmian - a golang (w międzyczasie) obsługuje debugowanie z Delve i JetBrainsGogland w systemie Linux (oraz Windows i Mac). Proces kompilacji Golanga (i środowisko wykonawcze) również nie zależy od NodeJS, co jest kolejnym plusem.
Jeśli chodzi o mono, trzymaj się od niego z daleka.
Niesamowite jest to, jak daleko zaszedł mono, ale niestety nie zastąpi to problemów z wydajnością / skalowalnością i stabilnością aplikacji produkcyjnych.
Co więcej, mono-rozwój jest dość martwy, w dużej mierze rozwijają już tylko części istotne dla Androida i iOS, ponieważ tam Xamarin zarabia pieniądze.
Nie oczekuj, że Web-Development będzie pierwszorzędnym obywatelem Xamarin / mono.
.NET Core może być tego wart, jeśli rozpoczniesz nowy projekt, ale w przypadku istniejących dużych projektów formularzy internetowych przenoszenie jest w dużej mierze wykluczone, wymagane zmiany są ogromne. Jeśli masz projekt MVC, ilość zmian może być zarządzalna, jeśli oryginalny projekt aplikacji był rozsądny, co w większości przypadków nie dotyczy większości tak zwanych aplikacji „historycznie hodowanych”.
Aktualizacja z grudnia 2016 r .:
Kompilacja natywna została usunięta z podglądu .NET Core, ponieważ nie jest jeszcze gotowa ...
Wygląda na to, że uległy znacznej poprawie w teście porównawczym plików tekstowych, ale z drugiej strony stało się dość błędne. Ponadto pogorszyło się to w testach porównawczych JSON. Ciekawe, że ten szkielet bytu będzie szybszy dla aktualizacji niż Dapper - chociaż oba z rekordową powolnością. Jest to bardzo mało prawdopodobne. Wygląda na to, że jest jeszcze więcej niż kilka błędów, na które można polować.
Wydaje się, że na froncie Linux IDE pojawia się ulga.
JetBrains wydało „Project Rider”, wczesny podgląd C # / .NET Core IDE dla Linux (oraz Mac i Windows), który może obsługiwać pliki Visual Studio Project. Wreszcie C # IDE, które jest użyteczne i które nie jest powolne jak diabli.
Wniosek: .NET Core nadal jest oprogramowaniem jakości przedpremierowej, gdy wkraczamy w 2017 r. Przenieś swoje biblioteki, ale trzymaj się z dala od niego do użytku produkcyjnego, dopóki jakość frameworku nie ustabilizuje się.
I miej oko na Project Rider.
Aktualizacja 2017 Na razie
dokonałem migracji mojej strony głównej (brata) do .NET Core.
Jak dotąd środowisko uruchomieniowe w Linuksie wydaje się być wystarczająco stabilne (przynajmniej w przypadku małych projektów) - z łatwością przetrwało test obciążenia - mono nigdy tego nie zrobiło.
Wygląda też na to, że pomieszałem wdrożenie .NET-Core-native i .NET-Core-self-samodzielne wdrożenie. Samodzielne wdrażanie działa, ale jest nieco niedokumentowane, chociaż jest bardzo łatwe (narzędzia do kompilowania / publikowania są nieco niestabilne, ale - jeśli pojawi się komunikat „Wymagana liczba dodatnia. - Kompilacja NIE powiodła się” - ponownie uruchom to samo polecenie, i to działa).
Możesz biegać
dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64
Uwaga: zgodnie z .NET Core 3 możesz opublikować wszystko zminimalizowane jako pojedynczy plik :
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true
Jednak w przeciwieństwie do go, nie jest to plik wykonywalny z łączeniem statycznym, ale samorozpakowujący się plik zip, więc podczas wdrażania możesz napotkać problemy, zwłaszcza jeśli katalog tymczasowy jest zablokowany przez zasady grupy lub inne problemy . Jednak działa dobrze w programie hello-world. A jeśli nie zminimalizujesz, rozmiar pliku wykonywalnego osiągnie wartość około 100 MB.
Otrzymujesz samodzielny plik .exe (w katalogu publikowania), który możesz przenieść na komputer z systemem Windows 8.1 bez zainstalowanej platformy .NET i pozwolić mu działać. Miły. To właśnie tutaj zaczyna się interesować dotNET-Core. (pamiętaj o lukach, SkiaSharp nie działa na Windows 8.1 / Windows Server 2012 R2, [jeszcze] - ekosystem musi najpierw nadrobić zaległości - ale co ciekawe, Skia-dll-load-fail nie powoduje awarii całego serwera / aplikacja - więc wszystko inne działa)
(Uwaga: SkiaSharp w systemie Windows 8.1 brakuje odpowiednich plików środowiska wykonawczego VC - msvcp140.dll i vcruntime140.dll. Skopiuj je do katalogu publikowania, a Skia będzie działać w systemie Windows 8.1.)
Wydano aktualizację .NET Core 2.0 z sierpnia 2017 r .
Bądź ostrożny - przychodzi z (ogromnymi przełomami) zmianami w uwierzytelnianiu ...
Z drugiej strony przywrócił klasy DataTable / DataAdaper / DataSet i wiele innych.
Zrealizowany .NET Core wciąż nie obsługuje Apache SparkSQL, ponieważ Mobius nie jest jeszcze przeniesiony. To źle, ponieważ oznacza to brak obsługi SparkSQL dla mojego klastra IoT Cassandra, więc brak dołączeń ...
Eksperymentalna obsługa ARM (tylko środowisko wykonawcze, a nie SDK - szkoda na Devwork na moim Chromebooku - nie mogę się doczekać wersji 2.1 lub 3.0).
PdfSharp jest teraz eksperymentalnie przenoszony do .NET Core.
JetBrains Rideropuścił EAP. Teraz możesz go używać do programowania i debugowania platformy .NET Core w systemie Linux - choć do tej pory tylko .NET Core 1.1, dopóki aktualizacja obsługi .NET Core 2.0 nie zostanie uruchomiona.
Aktualizacja
2018.NET Core 2.1 już wkrótce. Może to naprawi uwierzytelnianie NTLM w systemie Linux (uwierzytelnianie NTLM nie działa w systemie Linux {i prawdopodobnie Mac} w .NET-Core 2.0 z wieloma nagłówkami uwierzytelniającymi, takimi jak negocjacje, zwykle wysyłane z wymianą ms i najwyraźniej są one tylko naprawienie go w wersji 2.1, brak wydania poprawki dla 2.0).
Ale nie instaluję wersji zapoznawczych na moim komputerze. Więc czekam.
Mówi się również, że wersja 2.1 znacznie skraca czas kompilacji. To by było dobre.
Należy również pamiętać, że w systemie Linux .NET Core jest tylko 64-bitowy !
Nie ma i nie będzie wersji .NET Core x86-32 w systemie Linux .
A port ARM to tylko ARM-32. Nie ma jeszcze ARM-64.
A w ARM masz (obecnie) tylko środowisko wykonawcze, a nie pakiet dotnet-SDK.
I jeszcze jedno:
Ponieważ .NET-Core używa OpenSSL 1.0, .NET Core w systemie Linux nie działa na Arch Linux, a na zasadzie pochodnej nie na Manjaro (najpopularniejsza dystrybucja Linuksa w tej chwili), ponieważ Arch Linux używa OpenSSL 1.1. Więc jeśli korzystasz z Arch Linux, nie masz szczęścia (także z Gentoo).
Edytować:
Najnowsza wersja .NET Core 2.2+ obsługuje OpenSSL 1.1. Możesz więc używać go w Arch lub (k) Ubuntu 19.04+. Być może będziesz musiał użyć skryptu instalacyjnego .NET-Core , ponieważ nie ma jeszcze żadnych pakietów.
Z drugiej strony wydajność zdecydowanie się poprawiła:
.NET Core 3:
Mówi się, że .NET-Core v 3.0 wprowadza WinForms i WPF do .NET-Core.
Jednak podczas gdy WinForms i WPF będą .NET Core, WinForms i WPF w .NET-Core będą działały tylko w systemie Windows, ponieważ WinForms / WPF będą korzystać z Windows-API.
Uwaga:
.NET Core 3.0 jest już dostępny (RTM), a WinForms i obsługa WPF są dostępne, ale tylko dla C # (w systemie Windows). Nie ma WinForms-Core-Designer . Ostatecznie projektant otrzyma aktualizację programu Visual Studio. Obsługa WinForm dla VB.NET nie jest obsługiwana , ale planowana jest na .NET 5.0 gdzieś w 2020 roku .
PS:
echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1
Jeśli używałeś go w systemie Windows, prawdopodobnie nigdy nie widziałeś tego:
Narzędzia .NET Core zbierają dane o użytkowaniu w celu poprawy komfortu użytkowania.
Dane są anonimowe i nie zawierają argumentów wiersza polecenia.
Dane są gromadzone przez Microsoft i udostępniane społeczności.
Możesz zrezygnować z telemetrii, ustawiając zmienną środowiskową DOTNET_CLI_TELEMETRY_OPTOUT na 1, używając swojej ulubionej powłoki.
Możesz przeczytać więcej o telemetrii narzędzi .NET Core @
https://aka.ms/dotnet-cli-telemetry .
Pomyślałem, że wspomnę, że uważam, że monodevelop (aka Xamarin Studio, Mono IDE lub Visual Studio Mac, jak się teraz nazywa na Macu) ewoluował całkiem nieźle i jest w międzyczasie w dużej mierze użyteczny.
Jednak JetBrains Rider (w tym momencie EAP 2018) jest zdecydowanie o wiele ładniejszy i bardziej niezawodny (a dołączony dekompilator jest bezpieczniejszy dla życia), to znaczy, jeśli rozwijasz platformę .NET-Core w systemie Linux lub Mac. MonoDevelop nie obsługuje Debug-StepThrough w systemie Linux w .NET Core, ponieważ MS nie udziela licencji na swoją bibliotekę DLL debugowania API (z wyjątkiem VisualStudio Mac ...). Można jednak użyć debugera Samsung dla platformy .NET Core za pośrednictwem rozszerzenia .NET Core debugera dla programu Samsung Debugger dla MonoDevelop
Oświadczenie:
Nie używam Maca, więc nie mogę powiedzieć, czy to, co tu napisałem, dotyczy również Maca opartego na FreeBSD-Unix. Mam na myśli wersję JetBrains Rider dla systemu Linux (Debian / Ubuntu / Mint), mono, MonoDevelop / VisualStudioMac / XamarinStudio i .NET-Core. Apple rozważa także przejście z procesorów Intel na procesory ARM (ARM-64?) Własnej produkcji, więc wiele z tego, co obecnie dotyczy komputerów Mac, może nie mieć zastosowania w przyszłości w komputerach Mac (2020+).
Ponadto, gdy piszę „mono jest dość niestabilny i wolny”, niestabilny dotyczy aplikacji WinFrom i WebForms, w szczególności wykonywania aplikacji internetowych za pomocą fastcgi lub XSP (w wersji mono 4.x), a także serializacji XML -obsługuje osobliwości, a dość powolny dotyczy WinForm, aw szczególności wyrażeń regularnych (ASP.NET-MVC używa również wyrażeń regularnych do routingu).
Kiedy piszę o moich doświadczeniach z mono 2.x, 3.x i 4.x, nie musi to również koniecznie oznaczać, że problemy te nie zostały do tej pory rozwiązane ani do czasu, gdy je czytasz, ani że jeśli są naprawiono teraz, że później nie może być regresji, która przywróciłaby którekolwiek z tych błędów / funkcji. Nie oznacza to również, że jeśli osadzisz mono-środowisko uruchomieniowe, uzyskasz takie same wyniki, jak podczas korzystania z mono środowiska uruchomieniowego (dewelopera). Nie oznacza to również, że osadzanie mono-runtime (gdziekolwiek) jest koniecznie darmowe.
Wszystko to niekoniecznie oznacza, że mono jest nieodpowiedni dla iOS lub Androida lub że ma tam te same problemy. Nie używam mono na Androidzie ani na iOS, więc nie mogę powiedzieć nic o stabilności, użyteczności, kosztach i wydajności na tych platformach. Oczywiście, jeśli używasz platformy .NET na Androidzie, musisz również wziąć pod uwagę inne koszty, takie jak wyważenie kosztów xamarin w porównaniu do kosztów i czasu potrzebnego do przeniesienia istniejącego kodu na Javę. Słysząc mono na Androidzie i IOS będzie całkiem niezły. Dodaj szczyptę soli. Po pierwsze, nie oczekuj, że domyślne kodowanie systemu będzie takie samo na Androidzie / iOS i Windows, i nie oczekuj, że system plików Android nie rozróżnia wielkości liter i nie oczekuj, że jakieś czcionki Windows będą obecne .