.NET Core vs Mono

Apa perbedaan antara .NET Core dan Mono?

Saya menemukan pernyataan di situs resmi yang mengatakan: "Kode yang ditulis untuk itu juga portabel di tumpukan aplikasi, seperti Mono."

Tujuan saya adalah menggunakan C #, LINQ, EF7 dan Visual Studio untuk membuat situs web yang dapat dijalankan / dihosting di Linux.

Seseorang mengatakan kepada saya bahwa dia ingin "di Mono", tetapi saya tidak tahu apa artinya itu. Saya tahu saya ingin menggunakan .NET Core 1.0 dengan teknologi yang saya sebutkan di atas. Dia juga mengatakan ingin menggunakan "fast CGI". Saya juga tidak tahu apa artinya itu.

Dapatkah Anda membantu saya memahami semua persyaratan ini dan jika harapan saya realistis?

Necromancing.
Memberikan jawaban aktual.

Apa perbedaan antara .Net Core dan Mono?

.NET Core sekarang secara resmi adalah masa depan .NET. Itu sebagian besar dimulai dengan menulis ulang kerangka kerja ASP.NET MVC dan aplikasi konsol, yang tentu saja termasuk aplikasi server. (Karena Turing-complete dan mendukung interop dengan C dll, Anda dapat, jika Anda benar-benar ingin, juga menulis aplikasi desktop Anda sendiri dengannya, misalnya melalui perpustakaan pihak ketiga seperti Avalonia, yang agak sangat mendasar pada saat saya pertama kali menulis ini, yang berarti Anda cukup banyak terbatas pada hal-hal web atau server.) Seiring waktu, banyak API telah ditambahkan ke .NET Core, sedemikian rupa sehingga setelah versi 3.1, .NET Core akan melompat ke versi 5.0, dikenal sebagai .NET 5.0 tanpa "Core", dan itu akan menjadi masa depan .NET Framework. Apa yang dulunya adalah .NET Framework penuh akan tetap ada dalam mode pemeliharaan sebagai Full .NET Framework 4.8.x selama beberapa dekade, sampai ia akan mati (mungkin masih akan ada beberapa upgrade, tapi saya ragu). Dengan kata lain, .NET Core adalah masa depan .NET, dan Full .NET Framework akan mengikuti cara Dodo / Silverlight / WindowsPhone .

Poin utama .NET Core, selain dari dukungan multi-platform, adalah untuk meningkatkan kinerja, dan untuk mengaktifkan "kompilasi asli" / penyebaran mandiri (sehingga Anda tidak perlu .NET framework / VM diinstal pada mesin target. .
di satu sisi, ini berarti docker.io dukungan pada Linux, dan di sisi lain penyebaran, mandiri berguna dalam "cloud computing", karena maka Anda hanya dapat menggunakan apa pun versi kerangka dotnet-CORE Anda suka, dan Anda tidak perlu khawatir tentang versi .NET framework mana sysadmin sebenarnya telah diinstal.

Sementara .NET Core runtime mendukung beberapa sistem operasi dan prosesor, SDK adalah cerita yang berbeda. Dan sementara SDK mendukung banyak OS, dukungan ARM untuk SDK sedang / sedang berjalan. .NET Core didukung oleh Microsoft. Dotnet-Core tidak datang dengan WinForms atau WPF atau semacamnya.

• Pada versi 3.0, WinForms dan WPF juga didukung oleh .NET Core, tetapi hanya pada Windows, dan hanya oleh C #. Bukan oleh VB.NET (Dukungan VB.NET direncanakan untuk v5 pada tahun 2020). Dan tidak ada Formulir Designer di. NET Core: itu sedang dikirim dengan pembaruan Visual Studio nanti, pada waktu yang tidak ditentukan.
• WebForms masih belum didukung oleh .NET Core, dan tidak ada rencana untuk mendukungnya, ( Blazor adalah anak baru di kota untuk itu).
• .NET Core juga dilengkapi dengan System.Runtime, yang menggantikan mscorelib.
• Seringkali, .NET Core dicampur dengan NetStandard , yang merupakan sedikit pembungkus di sekitar System.Runtime / mscorelib (dan beberapa yang lain), yang memungkinkan Anda untuk menulis perpustakaan yang menargetkan .NET Core, Full .NET Framework dan Xamarin (iOS / Android), semuanya pada saat bersamaan.
• .NET Core SDK tidak / tidak bekerja pada ARM, setidaknya tidak terakhir kali saya periksa.

" Proyek Mono " jauh lebih tua dari .NET Core.
Mono adalah bahasa Spanyol dan berarti Monyet, dan sebagai kata sampingan, nama itu tidak ada hubungannya dengan mononukleosis (petunjuk: Anda bisa mendapatkan daftar staf di http://primates.ximian.com /).
Mono dimulai pada 2005 oleh Miguel de Icaza (orang yang memulai GNOME - dan beberapa lainnya) sebagai implementasi dari .NET Framework untuk Linux (Ximian / SuSe / Novell). Mono termasuk Web-Forms, Winforms, MVC, Olive, dan IDE yang disebut MonoDevelop(Juga dikenal sebagai Xamarin Studio atau Visual Studio Mac). Pada dasarnya setara dengan (OpenJDK) JVM dan (OpenJDK) JDK / JRE (sebagai lawan dari SUN / Oracle JDK). Anda dapat menggunakannya untuk mendapatkan aplikasi ASP.NET-WebForms + WinForms + ASP.NET-MVC untuk bekerja di Linux.

Mono didukung oleh Xamarin (nama perusahaan baru yang dulunya Ximian, ketika mereka berfokus pada pasar Seluler, bukan pada pasar Linux), dan bukan oleh Microsoft.
(sejak Xamarin dibeli oleh Microsoft, itu secara teknis [tetapi tidak secara budaya] Microsoft.)
Anda biasanya akan mendapatkan barang C # Anda untuk dikompilasi pada mono, tetapi bukan barang VB.NET.
Mono kehilangan beberapa fitur canggih, seperti WSE / WCF dan WebParts.
Banyak implementasi Mono tidak lengkap (misalnya melempar NotImplementedException dalam enkripsi ECDSA), buggy (misalnya ODBC / ADO.NET dengan Firebird), berperilaku berbeda dari pada .NET (misalnya serialisasi XML) atau sebaliknya tidak stabil (ASP.NET MVC) dan lambat (Regex). Sisi baiknya, toolchain Mono juga berfungsi pada ARM.

Sejauh menyangkut .NET Core, ketika mereka mengatakan cross-platform, jangan berharap bahwa cross-platform berarti bahwa Anda benar-benar hanya bisa menginstal. NET Core di ARM-Linux, seperti yang Anda bisa dengan ElasticSearch. Anda harus mengkompilasi seluruh kerangka kerja dari sumber.
Yaitu, jika Anda memiliki ruang tersebut (mis. Pada Chromebook, yang memiliki total HD 16 hingga 32 GB).
Ini juga digunakan untuk memiliki masalah ketidakcocokan dengan OpenSSL 1.1 dan libcurl.
Itu telah diperbaiki dalam versi terbaru .NET Core Version 2.2.
Begitu banyak untuk cross-platform.

Saya menemukan pernyataan di situs resmi yang mengatakan, "Kode yang ditulis untuk itu juga portabel di tumpukan aplikasi, seperti Mono".

Selama kode itu tidak bergantung pada WinAPI-calls, Windows-dll-pinvoke, COM-Components, sistem file case-insensitive, pengkodean sistem default (codepage) dan tidak memiliki masalah pemisah direktori, itu benar. Namun, kode .NET Core berjalan pada .NET Core, dan bukan pada Mono. Jadi mencampurkan keduanya akan sulit. Dan karena Mono sangat tidak stabil dan lambat (untuk aplikasi web), saya tidak akan merekomendasikannya. Coba pemrosesan gambar pada .NET core, mis. WebP atau memindahkan GIF atau multipage-tiff atau menulis teks pada gambar, Anda akan terkejut.

Catatan:
Pada .NET Core 2.0, ada System.Drawing.Common (NuGet), yang berisi sebagian besar fungsionalitas System.Drawing. Itu harus lebih atau kurang fitur-lengkap di .NET-Core 2.1. Namun, System.Drawing.Common menggunakan GDI +, dan karenanya tidak akan berfungsi pada Azure (pustaka System.Drawing tersedia di Azure Cloud Service [pada dasarnya hanya VM], tetapi tidak di Azure Web App [pada dasarnya shared hosting?])
Jadi sejauh ini, System.Drawing.Common berfungsi dengan baik di Linux / Mac, tetapi memiliki masalah pada iOS / Android - jika bekerja sama sekali, di sana.
Sebelum .NET Core 2.0, yaitu sekitar pertengahan Februari 2017, Anda dapat menggunakan SkiaSharp untuk pencitraan (contoh) (Anda masih bisa).
Posting .net-core 2.0, Anda akan melihat bahwa SixLabors ImageSharpadalah cara untuk maju, karena System.Drawing tidak perlu aman, dan memiliki banyak kebocoran memori potensial atau nyata, itulah sebabnya Anda tidak boleh menggunakan GDI dalam aplikasi web; Perhatikan bahwa SkiaSharp jauh lebih cepat daripada ImageSharp, karena menggunakan pustaka asli (yang juga bisa menjadi kelemahan). Juga, perhatikan bahwa sementara GDI + bekerja di Linux & Mac, itu tidak berarti itu berfungsi di iOS / Android.

Kode tidak ditulis untuk .NET (non-Core) tidak portabel untuk .NET Core.
Artinya, jika Anda menginginkan pustaka non-GPL C # seperti PDFSharp untuk membuat dokumen-PDF (sangat umum), Anda kurang beruntung(saat ini)( tidak lagi ). Jangankan kontrol ReportViewer, yang menggunakan Windows-pInvokes (untuk mengenkripsi, membuat dokumen mcdf melalui COM, dan untuk mendapatkan font, karakter, kerning, informasi penyematan font, mengukur string dan melakukan pemecahan garis, dan untuk benar-benar menggambar tiff dengan kualitas yang dapat diterima) , dan bahkan tidak berjalan di Mono di Linux
( saya sedang mengerjakannya ).

Juga, kode yang ditulis dalam .NET Core tidak portabel untuk Mono, karena Mono tidak memiliki perpustakaan .NET Core runtime (sejauh ini).

Tujuan saya adalah menggunakan C #, LINQ, EF7, studio visual untuk membuat situs web yang dapat dijalankan / dihosting di linux.

EF dalam versi apa pun yang saya coba sejauh ini sangat lambat (bahkan pada hal-hal sederhana seperti satu meja dengan satu kiri-gabung), saya tidak akan merekomendasikan itu pernah - tidak pada Windows juga.
Saya khususnya tidak akan merekomendasikan EF jika Anda memiliki basis data dengan batasan unik, atau kolom varbinary / filestream / hierarchyid. (Tidak untuk pembaruan skema.)
Dan juga tidak dalam situasi di mana kinerja-DB sangat penting (katakanlah 10+ hingga 100+ pengguna bersamaan).
Juga, menjalankan situs web / aplikasi web di Linux cepat atau lambat berarti Anda harus men-debug itu.
Tidak ada dukungan debugging untuk .NET Core di Linux.(Tidak lagi, tetapi membutuhkan JetBrains Rider.)
MonoDevelop belum (belum) mendukung debugging .NET Core projects.
Jika Anda memiliki masalah, Anda sendirian. Anda harus menggunakan pencatatan yang ekstensif.
Hati-hati, maklum logging yang luas akan mengisi disk Anda dalam waktu singkat, terutama jika program Anda memasuki loop atau rekursi yang tak terbatas.
Ini sangat berbahaya jika aplikasi web Anda berjalan sebagai root, karena masuk memerlukan ruang-logfile - jika tidak ada ruang kosong yang tersisa, Anda tidak akan bisa masuk lagi.
(Biasanya, sekitar 5% dari ruang disk dicadangkan untuk root pengguna [alias administrator di Windows], jadi setidaknya administrator masih dapat masuk jika disk hampir penuh. Tetapi jika aplikasi Anda berjalan sebagai root, pembatasan itu tidak berlaku untuk penggunaan disk mereka, dan file log mereka dapat menggunakan 100% dari ruang kosong yang tersisa, sehingga bahkan administrator tidak dapat login lagi.)
Oleh karena itu lebih baik untuk tidak mengenkripsi disk itu, yaitu, jika Anda menghargai data / sistem Anda.

Seseorang mengatakan kepada saya bahwa dia ingin "di Mono", tetapi saya tidak tahu apa artinya itu.

Itu artinya dia tidak ingin menggunakan .NET Core, atau dia hanya ingin menggunakan C # di Linux / Mac. Dugaan saya adalah dia hanya ingin menggunakan C # untuk Web-App di Linux. .NET Core adalah cara untuk melakukannya, jika Anda benar-benar ingin melakukannya dalam C #. Jangan menggunakan "Mono proper"; di permukaan, tampaknya akan bekerja pada awalnya - tetapi percayalah Anda akan menyesal karena ASP.NET MVC Mono tidak stabil ketika server Anda berjalan jangka panjang (lebih dari 1 hari) - Anda sekarang telah diperingatkan Lihat juga referensi "tidak lengkap" saat mengukur kinerja Mono pada tolok ukur tenaga teknologi.

Saya tahu saya ingin menggunakan .Net Core 1.0 framework dengan teknologi yang saya sebutkan di atas. Dia juga mengatakan ingin menggunakan "cgi cepat". Saya juga tidak tahu apa artinya itu.

Itu berarti dia ingin menggunakan WebServer berfitur lengkap berkinerja tinggi seperti nginx (Engine-X), mungkin Apache.
Kemudian ia dapat menjalankan mono / dotnetCore dengan hosting berbasis nama virtual (beberapa nama domain pada IP yang sama) dan / atau load-balancing. Dia juga dapat menjalankan situs web lain dengan teknologi lain, tanpa memerlukan nomor port yang berbeda di server web. Ini berarti situs web Anda berjalan pada server fastcgi, dan nginx meneruskan semua permintaan web untuk domain tertentu melalui protokol fastcgi ke server itu. Ini juga berarti situs web Anda berjalan dalam jalur pipa fastcgi, dan Anda harus berhati-hati dengan apa yang Anda lakukan, misalnya Anda tidak dapat menggunakan HTTP 1.1 ketika mengirim file.
Jika tidak, file akan kacau di tempat tujuan.
Lihat juga di sini dan di sini .

Untuk menyimpulkan:
.NET Core saat ini (2016-09-28) tidak benar-benar portabel, juga tidak benar-benar cross-platform (khususnya alat debug).
Kompilasi asli juga tidak mudah, terutama untuk ARM.
Dan bagi saya, itu juga tidak terlihat seperti pengembangannya "benar-benar selesai".
Misalnya, System.Data.DataTable / DataAdaper.Update hilang ... (tidak lagi dengan .NET Core 2.0)
Bersama dengan antarmuka System.Data.Common.IDB *.(tidak lagi dengan .NET Core 1.1)
jika ada satu kelas yang sering digunakan, DataTable / DataAdapter akan menjadi ...
Juga, installer Linux (.deb) gagal, setidaknya pada mesin saya, dan saya ' Saya yakin saya bukan satu-satunya yang memiliki masalah itu.
Debug, mungkin dengan Visual Studio Code, jika Anda dapat membangunnya di ARM (saya berhasil melakukannya - JANGAN mengikuti posting blog Scott Hanselman jika Anda melakukannya - ada howto di wiki VS-Code di github), karena mereka tidak menawarkan yang dapat dieksekusi.
Yeoman juga gagal. (Saya kira itu ada hubungannya dengan versi nodejs yang Anda instal - VS Code membutuhkan satu versi, Yeoman yang lain ... tetapi harus dijalankan pada komputer yang sama. Cukup lemah.
Jangan pedulikan bahwa itu harus dijalankan pada versi node yang dikirimkan secara default di OS.
Sudahlah seharusnya tidak ada ketergantungan pada NodeJS sejak awal.
Server kestell juga sedang bekerja.
Dan menilai dari pengalaman saya dengan proyek-mono, saya sangat ragu mereka pernah menguji .NET Core di FastCGI, atau bahwa mereka tahu apa arti dukungan FastCGI untuk kerangka kerja mereka, apalagi bahwa mereka mengujinya untuk memastikan "semuanya berfungsi ". Bahkan, saya baru saja mencoba membuat aplikasi fastcgi dengan .NET Core dan baru menyadari bahwa tidak ada perpustakaan FastCGI untuk .NET Core "RTM" ...

Jadi, ketika Anda akan menjalankan .NET Core "RTM" di belakang nginx, Anda hanya dapat melakukannya dengan mem-proxy permintaan ke kestrell (server web yang diturunkan nodeJS yang diturunkan) - tidak ada dukungan fastcgi saat ini di .NET Core "RTM", AFAIK. Karena tidak ada .net core fastcgi library, dan tidak ada sampel, itu juga sangat tidak mungkin bahwa siapa pun melakukan pengujian pada kerangka kerja untuk memastikan fastcgi bekerja seperti yang diharapkan.

Saya juga mempertanyakan kinerja.
Dalam benchmark (pendahuluan) techempower-tech (putaran 13) , aspnetcore-linux peringkat 25% relatif terhadap kinerja terbaik, sementara kerangka kerja yang sebanding seperti Go (golang) peringkat di 96,9% dari kinerja puncak (dan itu adalah ketika mengembalikan plaintext tanpa file -Sistem akses saja). .NET Core melakukan sedikit lebih baik pada JSON-serialisasi, tetapi juga tidak terlihat menarik (mencapai 98,5% dari puncak, .NET inti 65%). Yang mengatakan, itu tidak mungkin lebih buruk daripada "mono proper".

Juga, karena masih relatif baru, tidak semua perpustakaan utama telah porting (belum), dan saya ragu beberapa dari mereka akan pernah porting.
Dukungan pencitraan juga patut dipertanyakan.
Untuk enkripsi apa pun, gunakan BouncyCastle sebagai gantinya.

Dapatkah Anda membantu saya memahami semua persyaratan ini dan jika harapan saya realistis ?

Saya harap saya membantu Anda lebih memahami semua istilah ini.
Sejauh harapan Anda pergi:
Mengembangkan aplikasi Linux tanpa mengetahui apa-apa tentang Linux adalah ide yang sangat bodoh, dan itu juga pasti gagal dalam beberapa cara yang mengerikan. Yang mengatakan, karena Linux datang tanpa biaya lisensi, itu ide yang baik pada prinsipnya, TAPI HANYA JIKA ANDA TAHU APA YANG ANDA LAKUKAN.
Mengembangkan aplikasi untuk platform di mana Anda tidak dapat men-debug aplikasi Anda adalah ide yang sangat buruk.
Berkembang untuk fastcgi tanpa mengetahui konsekuensi apa yang ada adalah ide buruk lainnya.

Melakukan semua hal ini pada platform "eksperimental" tanpa sepengetahuan spesifik platform itu dan tanpa dukungan debug adalah bunuh diri, jika proyek Anda lebih dari sekadar beranda pribadi. Di sisi lain, saya kira melakukannya dengan beranda pribadi Anda untuk tujuan pembelajaran mungkin akan menjadi pengalaman yang sangat baik - maka Anda akan tahu apa kerangka kerja dan apa masalah non-kerangka kerja.
Anda dapat misalnya (secara terprogram) loop-mount fat32 case-insensitive, hfs atau JFS untuk aplikasi Anda, untuk mengatasi masalah sensitivitas case (loop-mount tidak direkomendasikan dalam produksi).

Untuk meringkas
Saat ini (2016-09-28), saya akan tinggal jauh dari .NET Core (untuk penggunaan produksi). Mungkin dalam satu atau dua tahun, Anda dapat melihat lagi, tetapi mungkin tidak sebelumnya.
Jika Anda memiliki proyek web baru yang Anda kembangkan, mulailah dengan .NET Core, bukan mono.

Jika Anda menginginkan kerangka kerja yang berfungsi di Linux (x86 / AMD64 / ARMhf) dan Windows dan Mac, yang tidak memiliki dependensi, yaitu hanya penghubung statis dan tidak ada ketergantungan pada. NET, Java atau Windows, gunakan Golang sebagai gantinya. Ini lebih matang, dan kinerjanya terbukti (Baidu menggunakannya dengan 1 juta pengguna bersamaan), dan golang memiliki jejak memori yang jauh lebih rendah. Juga golang ada di repositori, .deb menginstal tanpa masalah, kompilasi kode sumber - tanpa memerlukan perubahan - dan golang (sementara itu) memiliki dukungan debug dengan delve dan JetBrainsGogland di Linux (dan Windows dan Mac). Proses pembangunan Golang (dan runtime) juga tidak bergantung pada NodeJS, yang merupakan nilai tambah lainnya.

Sejauh mono pergi, jauhi itu.
Tidaklah mengherankan seberapa jauh mono telah datang, tetapi sayangnya itu bukan pengganti untuk kinerja / skalabilitas dan masalah stabilitas untuk aplikasi produksi.
Juga, pengembangan mono cukup mati, mereka sebagian besar hanya mengembangkan bagian-bagian yang relevan dengan Android dan iOS lagi, karena di situlah Xamarin menghasilkan uang.
Jangan berharap Pengembangan Web menjadi warga negara Xamarin / mono kelas satu.
NET Core mungkin sepadan, jika Anda memulai proyek baru, tetapi untuk proyek web-bentuk besar yang ada, porting sebagian besar keluar dari pertanyaan, perubahan yang diperlukan sangat besar. Jika Anda memiliki proyek MVC, jumlah perubahan mungkin dapat dikelola, jika desain aplikasi asli Anda waras, yang sebagian besar tidak terjadi pada sebagian besar aplikasi yang disebut "secara historis tumbuh".

Pembaruan Desember 2016:
Kompilasi asli telah dihapus dari pratinjau .NET Core, karena belum siap ...

Sepertinya mereka telah meningkatkan cukup banyak pada patokan file teks mentah, tetapi di sisi lain, sudah cukup bermasalah. Selain itu, semakin memburuk dalam tolok ukur JSON. Penasaran juga bahwa kerangka kerja entitas akan lebih cepat untuk pembaruan daripada Dapper - meskipun keduanya lambat. Ini sangat tidak mungkin benar. Sepertinya masih ada lebih dari beberapa bug untuk diburu.

Juga, tampaknya ada bantuan datang di depan IDE Linux.
JetBrains merilis "Project Rider", pratinjau akses awal dari IDE Inti C # / .NET untuk Linux (dan Mac dan Windows), yang dapat menangani file Proyek Visual Studio. Akhirnya C # IDE yang dapat digunakan & yang tidak lambat sekali.

Kesimpulan: .NET Core masih merupakan perangkat lunak berkualitas pra-rilis saat kami berjalan menuju 2017. Port perpustakaan Anda, tetapi tinggal jauh dari itu untuk penggunaan produksi, sampai kualitas kerangka kerja stabil.
Dan awasi Project Rider.

Pembaruan 2017
Telah memigrasikan beranda (saudara lelaki saya) ke .NET Core untuk saat ini.
Sejauh ini, runtime di Linux tampaknya cukup stabil (setidaknya untuk proyek-proyek kecil) - ia selamat dari uji beban dengan mudah - mono tidak pernah melakukannya.
Juga, sepertinya saya mencampuradukkan .NET-Core-asli dan .NET-Core-mandiri-penyebaran. Penyebaran mandiri berfungsi, tetapi sedikit tidak terdokumentasi, meskipun sangat mudah (alat build / publish agak tidak stabil, namun - jika Anda menemukan "Nomor positif diperlukan. - Bangun GAGAL." - jalankan perintah yang sama lagi, dan itu bekerja).

Anda bisa lari

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

Catatan: Sesuai .NET Core 3, Anda dapat mempublikasikan semuanya yang diperkecil sebagai satu file :

dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true

Namun, tidak seperti go, ini bukan executable yang terhubung secara statis, tetapi merupakan file zip yang dapat diekstraksi sendiri, jadi ketika digunakan, Anda mungkin mengalami masalah, terutama jika direktori temp dikunci oleh kebijakan grup, atau beberapa masalah lainnya . Bekerja dengan baik untuk program halo-dunia. Dan jika Anda tidak mengecilkan, ukuran yang dapat dieksekusi akan masuk dengan kecepatan sekitar 100 MB.

Dan Anda mendapatkan file .exe mandiri (di direktori publikasikan), yang dapat Anda pindahkan ke mesin Windows 8.1 tanpa .NET framework diinstal dan biarkan dijalankan. Bagus. Di sinilah dotNET-Core baru mulai menarik. (perhatikan celahnya, SkiaSharp tidak berfungsi di Windows 8.1 / Windows Server 2012 R2, [belum] - ekosistem harus mengejar ketinggalan terlebih dahulu - tetapi yang menarik, kegagalan-beban-kegagalan Skia-dll tidak menghancurkan seluruh server / aplikasi - jadi semuanya berfungsi)

(Catatan: SkiaSharp pada Windows 8.1 tidak memiliki file runtime VC yang sesuai - msvcp140.dll dan vcruntime140.dll. Salin ke direktori publish, dan Skia akan bekerja pada Windows 8.1.)

Pembaruan Agustus 2017
.NET Core 2.0 dirilis.
Hati-hati - hadir dengan perubahan (pemecahan besar) dalam otentikasi ...
Di sisi baiknya, ini membawa kelas DataTable / DataAdaper / DataSet kembali, dan banyak lagi.
Realisasi .NET Core masih belum memiliki dukungan untuk Apache SparkSQL, karena Mobius belum porting. Itu buruk, karena itu berarti tidak ada dukungan SparkSQL untuk IoT Cassandra Cluster saya, jadi tidak ada yang bergabung ...
Dukungan ARM eksperimental (hanya runtime, bukan SDK - terlalu buruk untuk dikerjakan di Chromebook - berharap untuk 2.1 atau 3.0).
PdfSharp sekarang secara eksperimental dipindahkan ke .NET Core.
JetBrains Ridermeninggalkan EAP. Anda sekarang dapat menggunakannya untuk mengembangkan & men-debug .NET Core di Linux - meskipun sejauh ini .NET Core 1.1 hingga pembaruan untuk dukungan .NET Core 2.0 berjalan langsung.

Mei 2018 Pembaruan
.NET Core 2.1 rilis sudah dekat. Mungkin ini akan memperbaiki otentikasi NTLM di Linux (otentikasi NTLM tidak berfungsi di Linux {dan mungkin Mac} di .NET-Core 2.0 dengan beberapa header autentikasi, seperti bernegosiasi, umumnya dikirim dengan pertukaran-ms, dan tampaknya hanya memperbaikinya di v2.1, tidak ada rilis bugfix untuk 2.0).
Tapi saya tidak menginstal rilis pratinjau di mesin saya. Jadi menunggu.
v2.1 juga dikatakan sangat mengurangi waktu kompilasi. Itu bagus.

Juga, perhatikan bahwa di Linux, .NET Core hanya 64-Bit !
Tidak ada, dan tidak akan ada, versi x86-32 .NET Core di Linux .
Dan port ARM adalah ARM-32 saja. Belum ada ARM-64.
Dan pada ARM, Anda (saat ini) hanya memiliki runtime, bukan dotnet-SDK.

Dan satu hal lagi:
Karena .NET-Core menggunakan OpenSSL 1.0, .NET Core di Linux tidak berjalan di Arch Linux, dan bukan derivasi pada Manjaro (distro Linux paling populer sejauh ini pada saat ini), karena Arch Linux menggunakan OpenSSL 1.1. Jadi jika Anda menggunakan Arch Linux, Anda kurang beruntung (dengan Gentoo juga).

Edit:

Versi terbaru dari .NET Core 2.2+ mendukung OpenSSL 1.1. Jadi Anda dapat menggunakannya di Arch atau (k) Ubuntu 19.04+. Anda mungkin harus menggunakan skrip instalasi .NET-Core , karena belum ada paket.

Pada sisi positifnya, kinerja pasti meningkat:

.NET Core 3:
.NET-Core v 3.0 dikatakan membawa WinForms dan WPF ke .NET-Core.
Namun, sementara WinForms dan WPF akan menjadi .NET Core, WinForms dan WPF di .NET-Core akan berjalan pada Windows saja, karena WinForms / WPF akan menggunakan Windows-API.

Catatan:
.NET Core 3.0 sekarang keluar (RTM), dan ada dukungan WinForms dan WPF, tetapi hanya untuk C # (pada Windows). Tidak ada WinForms-Core-Designer . Perancang akhirnya akan datang dengan pembaruan Visual Studio, kapan saja. Dukungan WinForms untuk VB.NET tidak didukung , tetapi direncanakan untuk .NET 5.0 sekitar tahun 2020 .

PS:

echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1 

Jika Anda menggunakannya di windows, Anda mungkin tidak pernah melihat ini:

Alat .NET Core mengumpulkan data penggunaan untuk meningkatkan pengalaman Anda.
Data anonim dan tidak termasuk argumen baris perintah.
Data dikumpulkan oleh Microsoft dan dibagikan dengan komunitas.
Anda dapat memilih keluar dari telemetri dengan menetapkan variabel lingkungan DOTNET_CLI_TELEMETRY_OPTOUT ke 1 menggunakan shell favorit Anda.
Anda dapat membaca lebih lanjut tentang .NET Core tools telemetry @ https://aka.ms/dotnet-cli-telemetry .

Saya pikir saya akan menyebutkan bahwa saya pikir monodevelop (alias Xamarin Studio, IDE Mono, atau Visual Studio Mac seperti yang sekarang disebut di Mac) telah berkembang dengan cukup baik, dan - sementara itu - sebagian besar dapat digunakan.
Namun, JetBrains Rider (EAP 2018 pada saat ini) jelas jauh lebih baik dan lebih dapat diandalkan (dan dekompiler yang disertakan adalah lebih aman), artinya, jika Anda mengembangkan .NET-Core di Linux atau Mac. MonoDevelop tidak mendukung Debug-StepThrough di Linux di .NET Core, karena MS tidak melisensikan debugging API dll (kecuali untuk VisualStudio Mac ...). Namun, Anda dapat menggunakan debugger Samsung untuk .NET Core melalui ekstensi .NET Core debugger untuk Samsung Debugger untuk MonoDevelop

Penafian:
Saya tidak menggunakan Mac, jadi saya tidak bisa mengatakan apakah yang saya tulis di sini juga berlaku untuk Mac berbasis FreeBSD-Unix. Saya merujuk pada versi Linux (Debian / Ubuntu / Mint) versi JetBrains Rider, mono, MonoDevelop / VisualStudioMac / XamarinStudio dan .NET-Core. Selain itu, Apple sedang mempertimbangkan perpindahan dari prosesor Intel ke ARM yang diproduksi sendiri (ARM-64?), Sehingga banyak dari apa yang berlaku untuk Mac saat ini mungkin tidak berlaku untuk Mac di masa depan (2020+).

Juga, ketika saya menulis "mono sangat tidak stabil dan lambat", tidak stabil tersebut berkaitan dengan aplikasi WinFroms & WebForms, khususnya menjalankan aplikasi web melalui fastcgi atau dengan XSP (pada versi 4.x mono), serta serialisasi XML -menangani kekhasan, dan yang cukup lambat berhubungan dengan WinForms, dan ekspresi reguler pada khususnya (ASP.NET-MVC menggunakan ekspresi reguler untuk routing juga).

Ketika saya menulis tentang pengalaman saya tentang mono 2.x, 3.x dan 4.x, itu juga tidak berarti bahwa masalah-masalah ini belum diselesaikan sekarang, atau pada saat Anda membaca ini, atau jika itu adalah diperbaiki sekarang, bahwa tidak mungkin ada regresi nanti yang memperkenalkan kembali bug / fitur ini. Juga tidak berarti bahwa jika Anda menyematkan mono-runtime, Anda akan mendapatkan hasil yang sama seperti ketika Anda menggunakan runtime mono sistem (dev). Ini juga tidak berarti bahwa menanamkan mono-runtime (di mana saja) harus gratis.

Semua itu tidak berarti mono tidak cocok untuk iOS atau Android, atau memiliki masalah yang sama di sana. Saya tidak menggunakan mono di Android atau iOS, jadi saya tidak dapat mengatakan apa pun tentang stabilitas, kegunaan, biaya , dan kinerja pada platform ini. Jelas, jika Anda menggunakan .NET di Android, Anda memiliki beberapa pertimbangan biaya lain yang harus dilakukan juga, seperti pembobotan xamarin-biaya vs biaya dan waktu untuk porting kode yang ada ke Jawa. Seseorang mendengar mono di Android dan iOS akan cukup bagus. Ambillah dengan sebutir garam. Pertama, jangan berharap penyandian sistem default sama pada android / ios vs Windows, dan jangan berharap sistem file android peka terhadap huruf besar-kecil, dan jangan berharap ada font windows yang ada .

Di dunia .NET ada dua jenis CLR, "penuh" CLR dan Core CLR, dan ini adalah hal yang sangat berbeda.

Ada dua implementasi CLR "penuh", Microsoft. NET CLR asli (untuk Windows) dan Mono CLR (yang sendiri memiliki implementasi untuk Windows, linux dan unix (Mac OS X dan FreeBSD)). CLR lengkap persis seperti itu - semuanya, cukup banyak, yang Anda butuhkan. Dengan demikian, CLR "penuh" cenderung berukuran besar.

Core CLRs di sisi lain ditebang, dan jauh lebih kecil. Karena mereka hanya implementasi inti, mereka tidak mungkin memiliki semua yang Anda butuhkan di dalamnya, jadi dengan Core CLR Anda menambahkan set fitur ke CLR yang digunakan produk perangkat lunak spesifik Anda, menggunakan NuGet. Ada implementasi Core CLR untuk Windows, linux (berbagai) dan unix (Mac OS X dan FreeBSD) dalam campuran. Microsoft memiliki atau sedang refactoring .NET framework libraries untuk Core CLR juga, untuk membuatnya lebih portabel untuk konteks inti. Mengingat kehadiran mono di OS * nix, akan mengejutkan jika Core CLRs untuk * nix tidak menyertakan beberapa basis kode mono, tetapi hanya komunitas Mono dan Microsoft yang dapat memberi tahu kami dengan pasti.

Juga, saya setuju dengan Nico bahwa Core CLR baru - ini di RC2 saat ini saya pikir. Saya tidak akan bergantung padanya untuk kode produksi.

Untuk menjawab pertanyaan Anda, Anda dapat mengirimkan situs Anda di linux menggunakan Core CLR atau Mono, dan ini adalah dua cara berbeda untuk melakukannya. Jika Anda menginginkan taruhan yang aman sekarang saya akan menggunakan mono di linux, lalu port jika Anda ingin nanti, ke Core.

Anda telah memilih tidak hanya jalur yang realistis, tetapi bisa dibilang salah satu ekosistem terbaik yang didukung kuat (juga platform X) oleh MS. Anda tetap harus mempertimbangkan poin-poin berikut:

• Pembaruan: Dok utama tentang standar platform .Net ada di sini: https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md
• Pembaruan: Mono 4.4.1 saat ini tidak dapat menjalankan Asp.Net core 1.0 RTM terbaru
• Meskipun mono lebih lengkap fitur, masa depannya tidak jelas, karena MS memilikinya selama beberapa bulan sekarang dan ini merupakan duplikat bagi mereka untuk mendukungnya. Tapi MS pasti berkomitmen untuk Net Core dan bertaruh besar untuk itu.
• Meskipun .Net inti dirilis, ekosistem pihak ke-3 tidak cukup di sana. Misalnya Nhibernate, Umbraco dll tidak dapat menjalankan Net core. Tapi mereka punya rencana.
• Ada beberapa fitur yang hilang di .Net Core seperti System.Drawing, Anda harus mencari perpustakaan pihak ke-3
• Anda harus menggunakan nginx sebagai server depan dengan kestrelserver untuk aplikasi asp.net, karena kestrelserver tidak cukup siap untuk diproduksi. Misalnya HTTP / 2 tidak diterapkan.

Saya harap ini membantu

.Net Core tidak memerlukan mono dalam arti kerangka mono. .Net Core adalah kerangka kerja yang akan bekerja pada banyak platform termasuk Linux. Referensi https://dotnet.github.io/ .

Namun inti .Net dapat menggunakan kerangka kerja mono. Referensi https://docs.asp.net/en/1.0.0-rc1/getting-started/choosing-the-right-dotnet.html (catatan rc1 documentatiopn tidak ada rc2 tersedia), namun mono bukan kerangka kerja yang didukung Microsoft dan akan merekomendasikan menggunakan kerangka kerja yang didukung

Sekarang entitas framework 7 sekarang dipanggil Entity Framework Coredan tersedia di berbagai platform termasuk Linux. Referensi https://github.com/aspnet/EntityFramework (tinjau peta jalan)

Saya saat ini menggunakan kedua kerangka kerja ini tetapi Anda harus memahami bahwa itu masih dalam tahap kandidat rilis ( RC2adalah versi saat ini) dan selama beta & rilis kandidat ada perubahan besar yang biasanya berakhir dengan Anda menggaruk-garuk kepala.

Berikut ini adalah tutorial tentang cara menginstal MVC .Net Core ke Linux. https://docs.asp.net/en/1.0.0-rc1/getting-started/installing-on-linux.html

Akhirnya Anda memiliki pilihan Server Web (tempat saya mengasumsikan fast cgireferensi berasal) untuk meng-host aplikasi Anda di Linux. Berikut ini adalah titik referensi untuk menginstal ke lingkungan Linux. https://docs.asp.net/en/1.0.0-rc1/publishing/linuxproduction.html

Saya menyadari posting ini pada akhirnya sebagian besar merupakan tautan ke dokumentasi tetapi pada titik ini mereka adalah sumber informasi terbaik Anda. Inti .Net masih relatif baru di komunitas .Net dan sampai dirilis sepenuhnya, saya akan ragu untuk menggunakannya dalam lingkungan produk mengingat perubahan yang melanggar antara versi yang dirilis.

Pertanyaan ini sangat aktual karena kemarin Microsoft secara resmi mengumumkan rilis .NET Core 1.0 . Dengan asumsi bahwa Mono mengimplementasikan sebagian besar pustaka .NET standar, perbedaan antara inti Mono dan .NET dapat dilihat melalui perbedaan antara .NET Framework dan .NET Core:

• API - .NET Core berisi banyak API yang sama, tetapi lebih sedikit , sebagai .NET Framework, dan dengan anjak piutang yang berbeda (nama majelis
  berbeda; bentuk tipe berbeda dalam kasus-kasus utama). Perbedaan-perbedaan
  ini saat ini biasanya memerlukan perubahan sumber port ke .NET Core. .NET Core mengimplementasikan .NET Standard Library API, yang akan tumbuh dengan
  memasukkan lebih banyak .NET Framework BCL API seiring waktu.
• Subsistem - .NET Core mengimplementasikan subset dari subsistem dalam .NET Framework, dengan tujuan implementasi yang lebih sederhana dan
  model pemrograman. Misalnya, Keamanan Akses Kode (CAS) tidak
  didukung, sementara refleksi didukung.

Jika Anda perlu meluncurkan sesuatu dengan cepat, gunakan Mono karena saat ini (Juni 2016) produk yang lebih matang, tetapi jika Anda sedang membangun situs web jangka panjang, saya sarankan .NET Core. Secara resmi didukung oleh Microsoft dan perbedaan dalam API yang didukung mungkin akan segera menghilang, dengan mempertimbangkan upaya yang dilakukan Microsoft dalam pengembangan .NET Core.

Tujuan saya adalah menggunakan C #, LINQ, EF7, studio visual untuk membuat situs web yang dapat dijalankan / dihosting di linux.

Kerangka kerja Linq dan Entity termasuk dalam .NET Core , sehingga Anda aman untuk mengambil bidikan.

Sederhananya,

Mono adalah implementasi pihak ketiga .Net framework untuk Linux / Android / iOs

.Net Core adalah implementasi microsoft sendiri untuk hal yang sama.

.Net Core adalah masa depan. dan Mono akhirnya akan mati. Karena itu. Net Core tidak cukup matang. Saya sedang berjuang untuk mengimplementasikannya dengan IBM Bluemix dan kemudian membuang idenya. Down the time (mungkin 1-2 tahun), itu harus lebih baik.

Pendeknya:

Mono = Kompiler untuk C #

Mono Develop = Compiler + IDE

.Net Core = Kompiler ASP

Kasus saat ini untuk .Net Core adalah web hanya setelah mengadopsi beberapa standar winform terbuka dan adopsi bahasa yang lebih luas, akhirnya bisa menjadi pembangkit tenaga listrik Microsoft killer dev. Mempertimbangkan langkah lisensi Java dari Oracle baru-baru ini, Microsoft memiliki waktu yang sangat baik untuk bersinar.