Necromancing.
Gerçek bir cevap vermek.
.Net Core ve Mono arasındaki fark nedir?
.NET Core artık resmi olarak .NET'in geleceğidir. Çoğunlukla ASP.NET MVC çerçevesinin ve elbette sunucu uygulamalarını içeren konsol uygulamalarının yeniden yazılmasıyla başladı . (Turing tamamlandı ve C dll'lerle birlikte çalışmayı desteklediğinden, kesinlikle isterseniz, örneğin kendi masaüstü uygulamalarınızı da yazabilirsiniz, örneğin Avalonia gibi üçüncü taraf kütüphaneleri aracılığıyla, bunu ilk kez yazdığım sırada biraz çok temeldi, bu da web veya sunucu öğeleriyle neredeyse sınırlı olduğunuz anlamına geliyordu.) Zamanla, .NET Core'a birçok API eklendi, böylece 3.1 sürümünden sonra, .NET Core, 5.0 sürümüne atlayacak, "Core" olmadan .NET 5.0 olarak bilinecek ve daha sonra .NET Framework'ün geleceği olacaktır. Tam .NET Framework olan şey, bakım modunda, birkaç yıl boyunca Full .NET Framework 4.8.x olarak ölecektir (belki de bazı yükseltmeler olacak, ancak şüpheliyim). Başka bir deyişle, .NET Core, .NET'in geleceğidir ve Full .NET Framework, Dodo / Silverlight / WindowsPhone'un yoluna gidecektir .
.NET Core'un ana noktası, çoklu platform desteğinin yanı sıra, performansı artırmak ve "yerel derleme" / bağımsız dağıtım (etkinleştirmek için hedef makinede .NET framework / VM'ye ihtiyacınız yok) .
bir yandan, bu araçlar Linux üzerinde destek docker.io ve sonra sadece sizin gibi dotnet-CORE çerçevesinin ne olursa olsun sürümünü kullanabilirsiniz çünkü diğer, kendine yeten görevlendirilmesine, "bulut bilişim" faydalıdır, ve sysadmin'in gerçekte hangi .NET framework sürümlerini yüklediği konusunda endişelenmenize gerek yoktur.
.NET Core çalışma zamanı birden çok işletim sistemini ve işlemciyi desteklese de, SDK farklı bir hikaye. SDK birden fazla işletim sistemini desteklerken, SDK için ARM desteği hala devam ediyordu. .NET Core, Microsoft tarafından desteklenmektedir. Dotnet-Core WinForms veya WPF veya bunun gibi bir şeyle gelmedi.
- Sürüm 3.0 itibariyle, WinForms ve WPF de .NET Core tarafından desteklenmektedir, ancak yalnızca Windows ve yalnızca C # tarafından desteklenmektedir. VB.NET tarafından değil (VB.NET desteği 2020'de v5 için planlanmıştır). Ve .NET Core'da hiçbir Form Tasarımcısı yoktur: daha sonra belirtilmemiş bir zamanda bir Visual Studio güncellemesi ile gönderilir.
- WebForms hala .NET Core tarafından desteklenmemektedir ve bunları destekleyecek hiçbir plan yoktur ( Blazor bunun için şehirdeki yeni çocuktur).
- .NET Core, mscorelib'in yerini alan System.Runtime ile birlikte gelir.
- Genellikle .NET Core, System.Runtime / mscorelib (ve bazı diğerleri) etrafında bir paket olan NetStandard ile karıştırılır ve .NET Core, Full .NET Framework ve Xamarin'i (iOS) hedefleyen kütüphaneler yazmanıza olanak tanır / Android).
- .NET Core SDK, ARM üzerinde çalışmadı / çalışmadı, en azından son kontrol ettiğimde.
" Mono Projesi" .NET Core'dan çok daha eskidir.
Mono İspanyolcadır ve Maymun anlamına gelir ve bir yan açıklama olarak, adın mononükleoz ile ilgisi yoktur (ipucu: http://primates.ximian.com /) altındaki bir personel listesi alabilirsiniz .
Mono, 2005 yılında , Linux için .NET Framework'ün (Ximian / SuSe / Novell) bir uygulaması olarak Miguel de Icaza ( GNOME'u başlatan adam - ve birkaçı) tarafından başlatıldı . Mono, Web Formları, Winforms, MVC, Olive ve MonoDevelop adlı bir IDE içerir(Xamarin Studio veya Visual Studio Mac olarak da bilinir). Temel olarak (OpenJDK) JVM ve (OpenJDK) JDK / JRE (SUN / Oracle JDK yerine) eşdeğeri. ASP.NET-WebForms + WinForms + ASP.NET-MVC uygulamalarının Linux üzerinde çalışmasını sağlamak için kullanabilirsiniz.
Mono, Microsoft tarafından değil, Xamarin (Linux pazarı yerine Mobil pazarına odaklandıklarında Ximian olarak kullanılan şirketin yeni şirket adı) tarafından destekleniyor.
(Xamarin Microsoft tarafından satın alındığından, teknik olarak [ancak kültürel olarak değil] Microsoft'tur.)
Genellikle C # öğelerinizi mono üzerinde derlemek için alırsınız, ancak VB.NET öğelerini almazsınız.
Mono, WSE / WCF ve WebParts gibi bazı gelişmiş özellikleri kaçırır.
Mono uygulamalarının çoğu eksiktir (örneğin, ECDSA şifrelemesinde NotImplementedException'ı atmak), buggy (örneğin Firebird ile ODBC / ADO.NET), .NET (örneğin XML serileştirme) veya başka bir şekilde kararsız (ASP.NET MVC) ve kabul edilemez derecede yavaş (Regex). Üstte, Mono alet zinciri ARM üzerinde de çalışıyor.
.NET Core söz konusu olduğunda, çapraz platform dedikleri zaman, çapraz platformun, aslında ARM-Linux'ta .NET Core'u .NET Framework'te olduğu gibi kurabileceğiniz anlamına gelmesini beklemeyin. Çerçevenin tamamını kaynaktan derlemeniz gerekir.
Yani, bu alana sahipseniz (örneğin, 16 ila 32 GB toplam HD'ye sahip bir Chromebook'ta).
Ayrıca OpenSSL 1.1 ve libcurl ile uyumsuzluk sorunları yaşıyordu.
Bunlar .NET Core Sürüm 2.2'nin en son sürümünde düzeltildi.
Çapraz platform için çok fazla.
Resmi sitede "Bunun için yazılmış kod Mono gibi uygulama yığınlarında da taşınabilir" diyen bir açıklama buldum.
Bu kod WinAPI çağrılarına dayanmadığı sürece, Windows-dll-pinvokes, COM-Components, büyük / küçük harfe duyarlı olmayan bir dosya sistemi, varsayılan sistem kodlaması (kod sayfası) ve dizin ayırıcı sorunları yoktur. doğru. Ancak, .NET Core kodu Mono'da değil, .NET Core'da çalışır. Bu yüzden ikisini karıştırmak zor olacak. Ve Mono oldukça kararsız ve yavaş olduğu için (web uygulamaları için), yine de tavsiye etmem. .NET çekirdeğinde görüntü işlemeyi deneyin, örneğin WebP veya GIF taşıma veya multage-tiff veya bir görüntüye metin yazma, çok şaşırırsınız.
Not:
.NET Core 2.0'dan itibaren, System.Drawing işlevlerinin çoğunu içeren System.Drawing.Common (NuGet) vardır. .NET-Core 2.1'de az ya da çok tam özellikli olmalıdır. Ancak, System.Drawing.Common nedenle GDI + kullanır ve irade Azure üzerinde değil işi (System.Drawing kütüphaneleri Azure Cloud Service [temelde sadece VM] mevcuttur, ancak Azure Web App [temelde barındırma paylaşılan?] Değil)
Yani uzakta, System.Drawing.Common Linux / Mac üzerinde iyi çalışıyor, ancak iOS / Android'de sorunları var - eğer çalışıyorsa, orada.
.NET Core 2.0'dan önce, yani Şubat 2017'nin ortalarında, görüntüleme için SkiaSharp'ı kullanabilirsiniz (örnek) (yine de yapabilirsiniz).
.Net-core 2.0 yayınlayın , SixLabors ImageSharp'ınSystem.Drawing mutlaka güvenli olmadığından ve çok fazla potansiyel veya gerçek bellek sızıntısına sahip olduğundan, GDI'yı web uygulamalarında kullanmamalısınız; SkiaSharp'ın ImageSharp'den çok daha hızlı olduğuna dikkat edin, çünkü yerel kütüphaneler kullanır (bu da bir dezavantaj olabilir). Ayrıca, GDI + Linux ve Mac'te çalışırken, bunun iOS / Android'de çalıştığı anlamına gelmediğini unutmayın.
.NET (Çekirdek olmayan) için yazılmayan kodlar .NET Core için taşınabilir değildir.
Yani PDFSharp gibi GPL olmayan bir C # kütüphanesinin PDF belgeleri (çok sıradan) oluşturmasını istiyorsanız, şansınız kalmaz(Şu an)( artık değil ). Windows-pInvokes kullanan ReportViewer denetimini göz önünde bulundurmayın (COM aracılığıyla mcdf belgeleri şifrelemek, oluşturmak ve yazı tipi, karakter, karakter aralığı, yazı tipi gömme bilgileri almak, dizeleri ölçmek ve satır kesimi yapmak ve gerçekten kabul edilebilir kalitede tiffler çizmek için) ve Linux'ta Mono üzerinde bile çalışmıyor
( bunun üzerinde çalışıyorum ).
Ayrıca, .NET Core'da yazılan kod Mono için taşınabilir değildir, çünkü Mono .NET Core çalışma zamanı kitaplıklarına sahip değildir (şimdiye kadar).
Amacım, linux'da çalıştırılabilen / barındırılabilecek bir web sitesi oluşturmak için C #, LINQ, EF7, visual studio kullanmak.
Şimdiye kadar denedim herhangi bir sürümde EF çok lanet yavaş (hatta bir sol-birleştirme ile bir tablo gibi basit şeylerde), ben hiç tavsiye etmem - Windows üzerinde de.
Benzersiz kısıtlamalar veya varbinary / filestream / hierarchyid sütunları olan bir veritabanınız varsa özellikle EF'i tavsiye etmem. (Şema güncellemesi için
de değil .) Ayrıca DB performansının kritik olduğu bir durumda da (örneğin 10+ ila 100+ eşzamanlı kullanıcı).
Ayrıca, Linux'ta bir web sitesi / web uygulaması çalıştırmak er ya da geç hata ayıklamak zorunda kalacağınız anlamına gelir.
Linux'ta .NET Core için hata ayıklama desteği yoktur.(Artık değil, ancak JetBrains Rider gerektirir.)
MonoDevelop, (henüz) hata ayıklama .NET Core projelerini desteklemez.
Sorunlarınız varsa, kendi başınızasınız. Kapsamlı günlük kaydı kullanmanız gerekir.
Dikkatli olun, özellikle programınız sonsuz bir döngüye veya özyinelemeye girerse, kapsamlı kayıt işleminin diskinizi hiçbir zaman doldurmayacağını unutmayın.
Bu, web uygulamanız kök olarak çalışıyorsa özellikle tehlikelidir, çünkü oturum açmak için günlük dosyası alanı gerekir - boş alan kalmazsa, artık giriş yapamazsınız.
(Normal olarak, disk alanının yaklaşık% 5'i kullanıcı kökü [Windows'ta yönetici olarak adlandırılır) için ayrılmıştır, bu nedenle en azından yönetici disk doluysa yine de oturum açabilir. Ancak uygulamalarınız kök olarak çalışıyorsa, bu kısıtlama geçerli değildir. ve böylece günlük dosyaları kalan boş alanın% 100'ünü kullanabilir, böylece yönetici daha fazla oturum açamaz.)
Bu nedenle, bu diski şifrelememek daha iyidir, yani verilerinize / sisteminize değer veriyorsanız.
Birisi bana "Mono'da" olmasını istediğini söyledi, ama bunun ne anlama geldiğini bilmiyorum.
Ya .NET Core kullanmak istemediği ya da sadece Linux / Mac üzerinde C # kullanmak istediği anlamına gelir. Benim tahminim sadece Linux'ta bir Web Uygulaması için C # kullanmak istiyor. Eğer kesinlikle C # yapmak istiyorsanız, .NET Core bunun için bir yoldur. "Mono uygun" ile gitmeyin; yüzeyde, ilk başta çalışıyor gibi görünüyor - ama bana inanın ki pişman olacağınıza inanın çünkü Mono'nun ASP.NET MVC'si sunucunuz uzun süreli (1 günden daha uzun) çalıştığında kararlı değil - artık uyarıldınız. Ayrıca, teknoloji iş gücü kriterlerinde Mono performansını ölçerken "tamamlanmadı" referanslarına da bakın.
.Net Core 1.0 çerçevesini yukarıda listelediğim teknolojilerle kullanmak istediğimi biliyorum. Ayrıca "hızlı cgi" kullanmak istediğini söyledi. Bunun ne anlama geldiğini de bilmiyorum.
Nginx (Engine-X), muhtemelen Apache gibi yüksek performanslı tam özellikli bir WebServer kullanmak istediği anlamına gelir.
Ardından mono / dotnetCore'u sanal ad tabanlı barındırma (aynı IP üzerinde birden fazla alan adı) ve / veya yük dengeleme ile çalıştırabilir. Ayrıca, web sunucusunda farklı bir bağlantı noktası numarasına ihtiyaç duymadan başka teknolojilerle başka web siteleri de çalıştırabilir. Bu, web sitenizin bir fastcgi sunucusunda çalıştığı ve nginx'in, belirli bir etki alanı için tüm web isteklerini fastcgi protokolü aracılığıyla bu sunucuya ilettiği anlamına gelir. Ayrıca, web sitenizin bir fastcgi kanalında çalıştığı ve ne yaptığınıza dikkat etmeniz gerektiği anlamına gelir; örneğin, dosyaları aktarırken HTTP 1.1'i kullanamazsınız.
Aksi takdirde, dosyalar hedefe karışacaktır. Buraya ve buraya
da bakınız .
Sonuç olarak: Şu anda
.NET Core (2016-09-28) gerçekten taşınabilir değil, aynı zamanda gerçekten de çapraz platform (özellikle hata ayıklama araçları) değildir.
Özellikle ARM için yerel derleme de kolay değildir.
Ve bana göre, henüz gelişimi gerçekten bitmiş gibi görünmüyor.
Örneğin, System.Data.DataTable / DataAdaper.Update eksik ...
(artık .NET Core 2.0 ile değil)
System.Data.Common.IDB * arabirimleri ile birlikte.(artık .NET Core 1.1 ile değil)
Sık kullanılan bir sınıf olsaydı, DataTable / DataAdapter olurdu ...
Ayrıca, Linux yükleyicisi (.deb) başarısız olur, en azından makinemde ve ben ' Eminim ki bu sorunu yaşayan tek kişi ben değilim.
Hata ayıklama, belki Visual Studio Code ile, eğer ARM üzerine inşa edebilirseniz (bunu yapmayı başardım - bunu yapıyorsanız Scott Hanselman'ın blog yazısını takip etmeyin - github'da VS-Code'un wiki'sinde bir howto var, çünkü) yürütülebilir dosyayı sunmazlar.
Yeoman da başarısız olur. (Sanırım yüklediğiniz nodejs sürümü ile ilgili bir şey var - VS Kodu bir sürüm, Yeoman başka bir gerektirir ... ama aynı bilgisayarda çalışması gerekir. Oldukça topal
Varsayılan olarak gönderilen düğüm sürümü üzerinde çalışması gerektiğini unutmayın işletim sisteminde.
İlk olarak NodeJS'e bağımlılık olmaması gerektiğini unutmayın.
Kestell sunucusu da devam ediyor.
Mono projedeki tecrübelerime göre, FastCGI üzerinde .NET Core'u test ettiklerinden veya FastCGI desteğinin kendi çerçevesi için ne anlama geldiğine dair herhangi bir fikre sahip olduklarından şüphe duyuyorum. ". Aslında, .NET Core ile bir fastcgi uygulaması yapmaya çalıştım ve .NET Core "RTM" için FastCGI kütüphanesi olmadığını fark ettim ...
Yani nginx'in arkasında .NET Core "RTM" çalıştıracağınız zaman, sadece kestrell (bu yarı-mamul nodeJS'den türetilmiş web sunucusu) isteklerini proxy ile yapabilirsiniz - şu anda .NET Core'da fastcgi desteği yoktur "RTM", AFAIK. Net çekirdek fastcgi kütüphanesi ve örnek olmadığı için fastcgi'nin beklendiği gibi çalıştığından emin olmak için herkesin çerçeve üzerinde herhangi bir test yapması pek olası değildir.
Ben de performansı sorgularım.
In (ön) techempower-kriter (yuvarlak 13) , en iyi performans için% 25 oranla üzerinde aspnetcore-linux sıralarında iken karşılaştırılabilir zirve performansı 96.9% olarak Git (golang) rütbesine gibi çerçeveler (ve dosyası olmadan şifresiz döndürürken olmasıdır -sistem erişimi). .NET Core, JSON serileştirmede biraz daha iyi sonuç verir, ancak ikna edici de görünmez (en yüksek% 98,5'e, .NET çekirdeği% 65'e ulaşır). Bununla birlikte, "mono uygun" dan daha kötü olamaz dedi.
Ayrıca, hala nispeten yeni olduğu için, büyük kütüphanelerin tümü taşınmamıştır (henüz) ve bazılarının taşınacağından şüpheliyim.
Görüntüleme desteği de en iyi ihtimalle şüphelidir.
Şifreleme için bunun yerine BouncyCastle kullanın.
Tüm bu terimleri anlamama ve beklentilerimin gerçekçi olup olmamasına yardımcı olabilir misiniz ?
Umarım tüm bu terimlerle daha anlamlı olmana yardımcı oldum.
Beklentileriniz söz konusu olduğunda:
Linux hakkında hiçbir şey bilmeden bir Linux uygulaması geliştirmek, ilk etapta gerçekten aptalca bir fikirdir ve şu ya da bu şekilde korkunç bir şekilde başarısızlığa uğramak zorundadır. Bununla birlikte, Linux'un lisanslama maliyeti olmadığı için, prensipte iyi bir fikirdir, ancak SADECE NE YAPTIĞINIZI BİLİYORSANIZ.
Uygulamanızda hata ayıklayamayacağınız bir platform için uygulama geliştirmek gerçekten kötü bir fikir.
Hangi sonuçların olduğunu bilmeden fastcgi için geliştirmek başka bir gerçekten kötü bir fikir.
Projenizin yalnızca kişisel bir ana sayfadan fazlası olması durumunda, tüm bunları "deneysel" bir platformda, o platformun özellikleri hakkında bilgi sahibi olmadan ve hata ayıklama desteği olmadan yapmak intihardır. Öte yandan, öğrenme amacıyla kişisel ana sayfanızla yapmak muhtemelen çok iyi bir deneyim olacaktır - o zaman çerçevenin ne olduğunu ve çerçeve dışı sorunların ne olduğunu öğreneceksiniz.
Örneğin, büyük / küçük harfe duyarlılık sorunlarını gidermek için (programlı olarak) büyük / küçük harfe duyarlı olmayan bir yağ32, hfs veya JFS'yi döngü montajı yapabilirsiniz (döngü montajı üretimde önerilmez).
Özetlemek gerekirse
(2016-09-28), .NET Core'dan uzak dururum (üretim kullanımı için). Belki bir ila iki yıl içinde, başka bir göz atabilirsiniz, ama muhtemelen daha önce değil.
Geliştirdiğiniz yeni bir web projeniz varsa, mono olarak değil .NET Core'da başlatın.
Linux (x86 / AMD64 / ARMhf) ile Windows ve Mac üzerinde çalışan, sadece statik bağlantı ve .NET, Java veya Windows bağımlılığı olmayan bir çerçeve istiyorsanız, bunun yerine Golang kullanın. Daha olgun ve performansı kanıtlanmış (Baidu bunu 1 milyon eşzamanlı kullanıcıyla kullanıyor) ve golang önemli ölçüde daha düşük bir bellek alanına sahip. Ayrıca golang depolarda, .deb sorunsuz yüklenir, kaynak kodu - değişiklik gerektirmeden derlenir - ve golang (bu arada) delve ve JetBrains ile hata ayıklama desteğine sahiptirLinux'ta Gogland (ve Windows ve Mac). Golang'ın oluşturma süreci (ve çalışma zamanı) da başka bir artı olan NodeJS'ye bağlı değildir.
Mono kadarıyla uzak durun.
Mono'nun ne kadar uzağa geldiği şaşırtıcı değildir, ancak maalesef bu, üretim uygulamaları için performans / ölçeklenebilirlik ve kararlılık sorunlarının yerini tutmaz.
Ayrıca, mono-geliştirme oldukça öldü, artık sadece Android ve iOS ile ilgili parçaları geliştiriyorlar, çünkü Xamarin paralarını burada kazanıyor.
Web-Development'ın birinci sınıf Xamarin / mono vatandaş olmasını beklemeyin.
Yeni bir projeye başlarsanız .NET Core buna değebilir, ancak mevcut büyük web form projeleri için, taşıma büyük ölçüde söz konusu değildir, gerekli değişiklikler çok büyük. Bir MVC projeniz varsa, orijinal uygulama tasarımınız aklı başındaysa, değişikliklerin miktarı yönetilebilir olabilir; bu, çoğunlukla "tarihsel olarak yetiştirilen" uygulamaların çoğu için geçerli değildir.
Aralık 2016 Güncellemesi:
Yerel derleme henüz hazır olmadığı için .NET Core önizlemesinden kaldırıldı ...
Ham metin dosyası karşılaştırmasında oldukça yoğun bir şekilde iyileşmiş gibi görünüyor, ancak diğer taraftan oldukça buggy oldu. Ayrıca, JSON kriterlerinde daha da kötüleşti. Ayrıca, varlık çerçevesinin, her ikisi de kayıt yavaşlığında olmasına rağmen, güncellemeler için Dapper'den daha hızlı olması gerektiğine inanıyoruz. Bunun doğru olması pek olası değildir. Görünüşe göre hala avlanacak birkaç hatadan daha fazlası var.
Ayrıca, Linux IDE cephesinde bir rahatlama var gibi görünüyor.
JetBrains, Linux (ve Mac ve Windows) için Visual Studio Project dosyalarını işleyebilen C # /. NET Core IDE'nin erken erişim önizlemesi olan "Project Rider" ı yayınladı. Sonunda kullanılabilir bir C # IDE ve bu cehennem kadar yavaş değil.
Sonuç: .NET Core, 2017'ye yürüdüğümüz için hala yayın öncesi kaliteli bir yazılımdır. Kütüphanelerinizi taşıyın, ancak çerçeve kalitesi dengelenene kadar üretim kullanımı için uzak durun.
Ve Project Rider'ı takip edin.
2017 Güncellemesi
Şimdilik (erkek kardeşimin) ana sayfamı .NET Core'a taşıdım.
Şimdiye kadar, Linux'taki çalışma süresi yeterince kararlı görünüyor (en azından küçük projeler için) - bir yük testinden kolayca kurtuldu - mono hiç olmadı.
Ayrıca, .NET-Core-native ve .NET-Core-kendi kendine yeten dağıtımı karıştırdım. Bağımsız dağıtım çalışıyor, ancak biraz basit olmasına rağmen, çok kolay olmasına rağmen (derleme / yayınlama araçları biraz dengesiz, ancak "Pozitif sayı gerekli. - Derleme HATALI" ile karşılaşırsanız - aynı komutu tekrar çalıştırın, ve çalışıyor).
Koşabilirsin
dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64
Not: .NET Core 3 uyarınca, küçültülmüş her şeyi tek bir dosya olarak yayınlayabilirsiniz :
dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true
Bununla birlikte, go'nun aksine, statik olarak bağlı bir yürütülebilir dosya değil, kendi kendine ayıklanan bir zip dosyasıdır, bu nedenle dağıtırken, özellikle temp dizini grup ilkesi veya diğer bazı sorunlar tarafından kilitlenmişse sorun yaşayabilirsiniz . Yine de, bir merhaba dünya programı için iyi çalışıyor. Ve küçültmezseniz, yürütülebilir boyut 100 MB civarında bir saatte çalışacaktır.
Ve .NET framework yüklü olmadan bir Windows 8.1 makinesine taşıyabileceğiniz ve çalışmasına izin verebileceğiniz bağımsız bir .exe dosyası (yayınlama dizininde) alırsınız. Güzel. DotNET-Core'un ilgi çekmeye başladığı yer burası. (boşluklara dikkat edin, SkiaSharp Windows 8.1 / Windows Server 2012 R2'de çalışmaz , [henüz] - ekosistem ilk önce yetişmek zorundadır - ancak ilginç bir şekilde, Skia-dll-load-fail tüm sunucuyu / uygulama - böylece her şey çalışır)
(Not: Windows 8.1'deki SkiaSharp'da uygun VC çalışma zamanı dosyaları eksik - msvcp140.dll ve vcruntime140.dll. Bunları yayın dizinine kopyalayın ve Skia Windows 8.1'de çalışacaktır.)
Ağustos 2017 Güncellemesi
.NET Core 2.0 çıktı.
Dikkatli olun - kimlik doğrulamasında (büyük kırılma) değişikliklerle birlikte gelir ...
Üstte, DataTable / DataAdaper / DataSet sınıflarını ve daha fazlasını geri getirdi.
Gerçekleştirilmiş .NET Core hala Apache SparkSQL için destek eksik, çünkü Mobius henüz taşınmadı. Bu kötü, çünkü bu, IoT Cassandra Kümem için hiçbir SparkSQL desteği anlamına gelmiyor, bu yüzden katılmıyor ...
Deneysel ARM desteği (yalnızca çalışma zamanı, SDK değil - Chromebook'umdaki devwork için çok kötü - 2.1 veya 3.0'ı bekliyor).
PdfSharp şimdi deneysel olarak .NET Core'a taşındı.
JetBrains Ridersol EAP. Artık Linux üzerinde .NET Core geliştirmek ve hatalarını ayıklamak için kullanabilirsiniz - şimdiye kadar .NET Core 2.0 desteği güncellemesi yayınlanana kadar yalnızca .NET Core 1.1.
Mayıs 2018
.NET Core 2.1 sürümünü güncelleyin . Belki bu, Linux'ta NTLM kimlik doğrulamasını düzeltir (NTLM kimlik doğrulaması, Linux-{ve muhtemelen Mac} 'de .NET-Core 2.0'da, pazarlık gibi, genellikle ms-exchange ile gönderilen çoklu kimlik doğrulama başlıklarıyla çalışmaz ve görünüşe göre sadece v2.1'de düzeltiliyor, 2.0 için hata düzeltme sürümü yok).
Ancak makineme önizleme sürümleri yüklemiyorum. Yani bekliyorum.
v2.1'in derleme sürelerini de büyük ölçüde azalttığı söyleniyor. Bu iyi olurdu.
Ayrıca, Linux'ta .NET Core'un sadece 64 Bit olduğunu unutmayın !
Linux'ta .NET Core'un x86-32 sürümü yoktur ve olmayacaktır .
Ve ARM portu sadece ARM-32'dir. Henüz ARM-64 yok.
Ve ARM'de (şu anda) sadece çalışma süresine sahipsiniz, dotnet-SDK'ya değil.
Ve bir şey daha var:
.NET-Core OpenSSL 1.0 kullandığından, Linux üzerinde .NET Core, Arch Linux'ta ve Manjaro'da (bu noktada bugüne kadarki en popüler Linux dağıtımı) türetilmeyerek çalışmaz, çünkü Arch Linux OpenSSL 1.1 kullanıyor. Arch Linux kullanıyorsanız şansınız kalmaz (Gentoo ile de).
Düzenle:
En son .NET Core 2.2+ sürümü OpenSSL 1.1'i destekler. Böylece Arch veya (k) Ubuntu 19.04+ üzerinde kullanabilirsiniz. Henüz paket olmadığı için .NET-Core kurulum komut dosyasını kullanmanız gerekebilir .
Artan yönde, performans kesinlikle iyileşti:
.NET Core 3:
.NET-Core v 3.0'ın WinForms ve WPF'yi .NET-Core'a getirdiği söyleniyor.
Ancak, WinForms ve WPF .NET Core olurken, WinForms / WPF Windows-API'yi kullanacağı için .NET Core'daki WinForms ve WPF yalnızca Windows üzerinde çalışır.
Not:
.NET Core 3.0 çıktı (RTM) ve WinForms ve WPF desteği var, ancak yalnızca C # (Windows'ta) için. Orada hiçbir WinForms Çekirdekli-Tasarımcı . Tasarımcı sonunda bir Visual Studio güncellemesi ile gelecek. VB.NET için WinForms desteği desteklenmez , ancak 2020'de .NET 5.0 için planlanmıştır .
Not:
echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1
Pencerelerde kullandıysanız, muhtemelen bunu hiç görmediniz:
.NET Core araçları, deneyiminizi geliştirmek için kullanım verilerini toplar.
Veriler anonimdir ve komut satırı bağımsız değişkenleri içermez.
Veriler Microsoft tarafından toplanır ve toplulukla paylaşılır.
En sevdiğiniz kabuğu kullanarak bir DOTNET_CLI_TELEMETRY_OPTOUT ortam değişkeni 1 olarak ayarlayarak telemetriyi devre dışı bırakabilirsiniz.
.NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry hakkında daha fazla bilgi edinebilirsiniz
.
Monogelişimin (şu anda Mac'te çağrıldığı gibi Xamarin Studio, Mono IDE veya Visual Studio Mac) oldukça güzel bir şekilde geliştiğini ve bu arada büyük ölçüde kullanılabilir olduğunu düşündüğümü düşündüm.
Bununla birlikte, JetBrains Rider (bu zamanda 2018 EAP) kesinlikle çok daha güzel ve daha güvenilirdir (ve dahil edilen dekomiler hayat kurtarıcıdır), yani Linux veya Mac'te .NET-Core geliştirirseniz. MS, hata ayıklama API dll (VisualStudio Mac ... hariç) lisans vermediğinden MonoDevelop .NET Core Linux'ta Debug-StepThrough'u desteklemez. Ancak, kullanabileceğiniz .NET Çekirdek Samsung ayıklayıcısını aracılığıyla MonoDevelop için Samsung Debugger NET Çekirdek ayıklayıcı uzantısı
Yasal Uyarı:
Mac kullanmıyorum, bu yüzden burada yazdıklarım FreeBSD-Unix tabanlı Mac için de geçerliyse söyleyemem. JetBrains Rider, mono, MonoDevelop / VisualStudioMac / XamarinStudio ve .NET-Core'un Linux (Debian / Ubuntu / Mint) sürümüne atıfta bulunuyorum. Ayrıca Apple, Intel işlemcilerden kendi kendine üretilen ARM (ARM-64?) Tabanlı işlemcilere geçiş yapmayı düşünüyor, şu anda Mac için geçerli olanların çoğu gelecekte Mac için geçerli olmayabilir (2020+).
Ayrıca, "mono oldukça kararsız ve yavaştır" yazdığımda, kararsız WinFroms & WebForms uygulamaları ile ilgilidir, özellikle web uygulamalarını fastcgi veya XSP (mono'nun 4.x sürümünde) ve XML serileştirme ile yürütür - tuhaflıkları ele almak ve oldukça yavaş WinForms ve özellikle düzenli ifadeler ile ilgilidir (ASP.NET-MVC, yönlendirme için de normal ifadeler kullanır).
Mono 2.x, 3.x ve 4.x ile ilgili deneyimlerim hakkında yazdığımda, bu aynı zamanda bu sorunların şu ana kadar veya bunu okuduğunuz zamana kadar çözülmediği anlamına gelmez. düzeltildi, daha sonra bu hataların / özelliklerin herhangi birini yeniden üreten bir gerileme olamaz. Bu, mono çalışma zamanını gömdüğünüzde, (dev) sisteminin mono çalışma zamanını kullandığınızda aynı sonuçları alacağınız anlamına da gelmez. Ayrıca, mono çalışma zamanının (herhangi bir yerde) gömülmesinin mutlaka ücretsiz olduğu anlamına gelmez.
Mono anlamına gelmeyen her şey iOS veya Android için uygun değildir veya orada aynı sorunları vardır. Android veya IOS'ta mono kullanmıyorum, bu nedenle bu platformlardaki kararlılık, kullanılabilirlik, maliyetler ve performans hakkında hiçbir şey söyleyemiyorum . Açıkçası, Android'de .NET kullanıyorsanız, xamarin maliyetlerini ve mevcut kodu Java'ya taşımak için maliyetleri ve zamanı ağırlıklandırmak gibi başka maliyet faktörleri de vardır. Biri Android'de mono duyar ve IOS oldukça iyi olur. Bir tuz tanesi ile alın. Birincisi, varsayılan sistem kodlamasının Android / ios ve Windows'da aynı olmasını beklemeyin ve android dosya sisteminin büyük / küçük harfe duyarlı olmadığını ve herhangi bir Windows yazı tipinin mevcut olmasını beklemeyin .