Aspnetcore: Diskusi: ASP.NET Core 3.0 hanya akan berjalan di .NET Core

Saya pikir ini sangat masuk akal dalam gambaran keseluruhan sekarang. Baik .NET Core dan ASP.NET Core telah ada cukup lama sekarang sehingga orang sudah atau masih memiliki kesempatan untuk beralih ke sana, tanpa menyebabkan masalah besar (dibandingkan dengan saat dukungan pertama kali turun di masa lalu dengan 2.0) .

Namun, saya sedih tentang implikasinya meskipun untuk komponen tertentu dari ASP.NET Core yang saat ini dapat ada sebagai dependensi terpisah. Karena ini mungkin berarti bahwa masing-masing komponen akan kehilangan dukungan netstandard, membutuhkan netcoreapp3.0 sebagai gantinya; dan terutama dengan # 3756 komponen tersebut tidak dapat digunakan di luar konteks ASP.NET Core.

Misalnya, proyek seperti RazorLight kemudian akan secara efektif dipaksa untuk melepaskan .NET Framework dan yang lebih penting dukungan .NET Standard secara umum.

Ini akan membuat banyak orang yang telah menjual pindah ke model pemrograman ASP.NET Core baru di organisasi mereka untuk tetap berada di platform yang didukung dan dikembangkan secara aktif dalam cuaca dingin di platform yang tidak didukung dalam waktu kurang dari 3 tahun (. NET Core 2.1 LTS).

Saya tidak yakin analitik apa yang Anda gunakan untuk membenarkan langkah ini, tetapi untuk Menjalankan Aplikasi Inti ASP.NET ServiceStack di .NET Framework kami melihat bahwa templat web-corefx paling populer untuk menjalankan proyek Inti ASP.NET di .NET Framework lebih dari 1/3 (33,8%) berbagi template web kosong yang sama yang merupakan template proyek kami yang paling populer untuk dijalankan di .NET Core.

IMO 3 tahun tidak cukup waktu untuk meninggalkan Pelanggan yang telah mulai atau telah pindah ke model pemrograman ASP.NET baru (untuk keluar dari platform ASP.NET Framework yang stagnan) hanya untuk mengetahui sekarang bahwa platform yang mereka jual ke organisasi mereka untuk pindah telah ditinggalkan.

Untuk alasan apa pun ada Pelanggan yang tidak dapat pindah ke .NET Core karena hanya mengandalkan dependensi .NET Framework, jika MS tidak ingin mempertahankan dukungan untuk .NET Framework di ASP.NET Core 3.0 di IMO mendatang, Anda harus memperluas dukungan untuk ASP.NET Core 2.1 di .NET Framework untuk periode yang diperpanjang seperti 7 tahun. Migrasi sistem produksi yang ada dapat memakan waktu bertahun-tahun, sejak memulai .NET Core jelas ASP.NET Framework telah dibiarkan stagnan dengan pendirian resmi bahwa ASP.NET Core adalah model pemrograman masa depan untuk .NET, sekarang Pelanggan yang sama akan melakukannya segera mulai mengetahui bahwa model pemrograman baru yang mereka pindahkan / pindahkan tidak akan didukung dalam beberapa tahun. Cara terbaik untuk mengakomodasi Pelanggan .NET yang ada ini adalah dengan mendukung .NET 2.1 untuk periode LTS tambahan, setidaknya untuk patch keamanan (idealnya untuk mengatasi bug juga).

"membunuh .NET Framework", episode 2: cerita yang sama, karakter yang sama : rofl:

Sayangnya, ini hanya menyoroti satu hal: Anda benar-benar gagal menjadikan .NET Standard sebagai mobil depan ekosistem .NET . Itu tidak bergerak secepat yang seharusnya dan tidak lebih dari penyebut umum terendah yang selalu diperbarui di saat-saat terakhir, ketika semua platform menyertakan (atau akan menyertakan) API baru.

Mungkin itu hanya saya, tetapi saya tidak pernah mengerti mengapa itu tidak bergerak secepat netcoreapp (yang merupakan yang pertama mendapatkan API baru, menurut definisi).

Anda adalah pembuat paket NuGet dan ingin mereka menggunakan barang terbaru? Targetkan versi netstandard terbaru: tentu, awalnya, hanya aplikasi berbasis netcoreapp dapat menggunakannya, tetapi pada akhirnya platform lain - seperti Xamarin, Mono, atau .NET Framework - akan menyusul dan orang-orang akan dapat menggunakan paket Anda tanpa mengharuskan Anda mengubah apa pun. Begitulah cara kerja seharusnya.

Tentu saja, mungkin perlu beberapa saat untuk platform non-.NET Core seperti .NET Framework untuk mengejar ketinggalan karena rilisnya lebih jarang dan bilah stabilitas jauh lebih tinggi, tetapi bahkan jika itu membutuhkan 6, 12 atau bahkan 18 bulan, saya tidak ' Saya tidak berpikir itu masalah, karena itulah yang diinginkan orang saat menggunakan .NET Framework: kerangka kerja yang stabil, bukan target yang bergerak cepat.

IMHO, itu akan menjadi pendekatan yang jauh lebih baik untuk membuat ASP.NET Core 3.0 menargetkan netstandard TFM baru yang mengekspos semua .NET Core API yang Anda butuhkan. Setelah Anda yakin API baru cukup stabil, lakukan backport ke .NET Framework agar kompatibel dengan standar terbaru.

Saya yakin orang lebih suka menunggu beberapa bulan sebelum dapat memindahkan aplikasi .NET Framework mereka ke versi ASP.NET Core terbaru daripada diblokir selamanya pada versi lama dengan dukungan 3 tahun yang sangat singkat.

Lakukan apa yang Anda janjikan: jadikan .NET Framework kerangka kerja stabil yang berkembang lebih lambat, bukan jalan buntu bagi orang-orang yang mempercayai Anda saat bermigrasi ke ASP.NET Core.

Saya tidak suka ini. Pada awal .net core, Microsoft tidak memilih mono atau .net framework sebagai cross platform, dan Anda mengatakan ada beberapa runtime .net di sana jadi Anda mendesain .netstandard , sekarang masih banyak paket nuget yang tidak mendukung .net core (maksudnya alasan). Banyak developer yang akan meninggalkan model pemrograman inti asp.net yang lama jika inti asp.net hanya berjalan pada inti .net. maka .net standard akan ada dalam nama (setidaknya untuk inti asp.net, orang-orang mulai membangun paket khusus netcoreapp ).
Mungkin suatu saat nanti, .net core bisa menggantikan .net framework di window, tapi bagaimana dengan mono, dan platform lain yang mengandalkan mono (xamarin, unity3d).
dan alasan lain mengapa saya lebih suka .net framework adalah karena framework .net core share sangat besar, seberapa besar folder C:/program file/dotnet jika Anda mengupgrade aplikasi dari .net core 2.0 ke .net core 2.1 terbaru? Ada file GBs di folder saya, dan itu tumbuh ketika saya memperbarui runtime inti .net. tapi .net framework hanya akan menggantikan versi lama.

Lakukan apa yang Anda janjikan: jadikan .NET Framework kerangka kerja stabil yang berkembang lebih lambat, bukan jalan buntu bagi orang-orang yang mempercayai Anda saat bermigrasi ke ASP.NET Core.

FWIW ini akan menjadi strategi yang optimal, saran saya untuk memperpanjang LTS adalah batasan minimum untuk memberikan lebih banyak waktu kepada Pelanggan yang ada yang telah dipasarkan secara agresif untuk bermigrasi ke ASP.NET Core yang sekarang telah ditinggalkan di platform yang tidak didukung di masa depan dengan ini pengumuman.

Jadi. Standar bersih adalah lelucon? Berharap tim mono akan membagi repo aspnetcore dan mengganti namanya menjadi aspnetmono, jika tidak, saya dapat meninggalkan .net stack.😔

Saya rasa ini berarti bahwa dalam pekerjaan saya, kami tidak akan pernah menggunakan ASP.NET Core. Kami akan tetap di ASP.NET selamanya apalagi mem-porting aplikasi ke Core karena itu sekarang akan melibatkan lebih banyak perubahan.

Tentu, jika tujuan Anda adalah tidak ada perubahan maka Anda bisa terus melakukan hal yang sama selamanya. Tempat saya bekerja, kami mulai menggunakan ASP.NET Core beberapa tahun yang lalu, awalnya berjalan di .NET Framework. Seiring waktu, karena platform .NET Core semakin matang dan memperoleh fitur, kami mengalihkan proyek kami ke netcoreapp. Satu atau dua proyek lama masih menggunakan ASP.NET, dan kami tidak berencana untuk menulis ulang itu - ini adalah kode yang berfungsi. Tetapi untuk hal-hal yang lebih baru, kami menantikan fitur seperti Span.

Perubahan dapat ditunda, tetapi itu bukanlah sesuatu yang dapat atau harus Anda hindari selamanya - teknologi _adalah_ perubahan dan pekerjaan pengembang akan selalu membutuhkan pembelajaran hal-hal baru. Jika Anda menggunakan ASP.NET Core di .NET Framework saat ini, kemungkinan tidak perlu waktu tiga tahun untuk memindahkannya ke .NET Core.

Kunjungi .NET Core, airnya hangat ...

Untuk alasan apa pun ada Pelanggan yang tidak dapat pindah ke .NET Core karena hanya mengandalkan dependensi .NET Framework ...

Lebih serius lagi, Anda dapat menggunakan pustaka .NET 4.x pada .NET Core 2.0 sejak .NET Standard 2.0 ; meskipun ada kemungkinan mereka mungkin menggunakan beberapa fitur yang tidak dimiliki .NET Core; meskipun ada Paket Kompatibilitas Windows untuk .NET Core yang menyumbat banyak lubang ini dan banyak lagi fitur yang didukung di .NET Core 3.0 termasuk interop COM dan model aplikasi lain seperti WinForms dan WPF dll.

Semua pemblokir yang mencegah aplikasi ASP.NET Core pindah ke .NET Core dari .NET Framework mungkin harus dimunculkan di dotnet / corefx .

Untuk Xamarin; Saya bisa saja salah, tetapi saya berasumsi bahwa Anda tidak akan menggunakannya untuk menjalankan server web di iOS atau Android.

Untuk aplikasi klien Mono, server web dapat kehabisan proses dan berjalan di .NET Core sementara UI berjalan di Mono. Kestrel tidak pernah dapat berjalan pada platform Big Endian yang memotong beberapa platform lain Mono meskipun rasa BSD saat ini merupakan celah .NET Core.

Untuk Unity; game melakukan berbagai hal aneh, jadi mungkin itu skenario yang tidak tercakup; jika game menggunakan server web di klien; daripada di server atau di luar proc; ketika .NET Core dapat menjalankan bagian itu.

Di luar model aplikasi ASP.NET Core; misalnya untuk pustaka .NET Standard lebih penting karena ASP.NET Core memiliki semua jenis fitur yang berguna, Razor menjadi contoh khusus.

Tidak semua pustaka pindah ke .NET Core saja (mis. Microsoft.Extensions.* tetap sebagai .NET Standard) dan kemungkinan akan membantu untuk menyediakan skenario khusus yang akan terpengaruh seperti yang telah dilakukan @daveaglick di https: // github.com/aspnet/AspNetCore/issues/3757#issuecomment -434140416 sehingga dapat dipertimbangkan; tentang pustaka dan / atau fitur tertentu yang dapat tetap tersedia di .NET Standard daripada hanya "semuanya" yang samar.

ASP.NET Core mendorong banyak perubahan dan API baru di .NET Core dan saya dapat memahami keinginan untuk kemudian menggunakan fitur tersebut (karena itu adalah salah satu kasus penggunaan mereka); jika tidak, itu sedikit merugikan diri sendiri.

Di sisi lain, alangkah baiknya jika mereka juga dalam versi .NET Standard sehingga runtime lain kemudian dapat mendukung ASP.NET Core 3.0 ketika mereka mulai mengimplementasikannya. Secara realistis, itu tidak akan segera terjadi (karena .NET Standard 2.1 belum diselesaikan dan itu perlu versi yang lebih dari itu).

Mungkin model aplikasi ASP.NET Core akan kembali ke .NET Standard di kemudian hari ketika hal-hal telah menyusul? Meskipun mungkin selalu bergerak terlalu cepat untuk proses .NET Standard seperti saat ini berfungsi?

@gulbanana bagaimana jika inti asp.net Anda pada kerangka .net menggunakan com? atau ada paket nuget yang hanya mendukung framework .net?

Saya percaya itu tidak pernah menjadi pertanyaan apakah pemindahan harus dilakukan atau tidak, tetapi hanya kapan.
Terakhir kali ini menyebabkan ~ diskusi ~ shitstorm, ekosistem tidak siap untuk memungkinkan porting aplikasi yang sudah ada.
Sekarang ada paket kompatibilitas windows dan WinForms dan WPF akan datang ke .NET Core.

Saya pikir paket 2.1 yang ada untuk .NET Framework menyediakan jalur migrasi yang baik: Migrasi ke 2.1 di netfx dan kemudian ke .NET Core.

Ini mirip dengan AngularJS vs Angular: Migrasikan kode yang ada ke komponen (hard) di versi terbaru 1. *, lalu pindah ke versi Angular terbaru. Ini sangat sulit tetapi bisa dilakukan.

Dengan fitur baru yang menarik yang ditambahkan ke CoreCLR dan mono (mis. Metode antarmuka default atau hanya Span cepats) yang tidak akan pernah berhasil mencapai .NET Framework, tampaknya masuk akal untuk meninggalkan .NET Framework di beberapa titik.
Itu tidak selalu berarti "tidak mendukung" .NET Framework, melainkan membiarkannya apa adanya.

Masih ada beberapa situs di sekitar yang menggunakan ASP klasik (bukan ASP.NET, tetapi barang yang sangat lama). Ini masih berfungsi dan dikirimkan di Windows, Anda tidak akan membuat aplikasi baru dengannya.
Saya percaya bahwa dalam <10 tahun, ini mungkin situasi dengan .NET Framework.

Saya setuju dengan dukungan tambahan yang diminta untuk 2.1, tetapi saya ingin tim memantau unduhan paket 2.1 untuk membuat keputusan dalam 2-3 tahun jika mereka perlu mendukung (= memperbaiki masalah keamanan penting) sebentar sedikit lebih lama.

@ John0King COM akan didukung di .NET Core 3.0.

Juga: Kami memiliki aplikasi lama yang menggunakan hal-hal seperti .NET Remoting.
Tapi itu sudah warisan.

Dunia pada dasarnya berjalan pada kode lama dan akan terus melakukannya. Ini adalah keputusan bisnis apakah akan mentransfer sesuatu ke hal yang "didukung" atau bahkan "baru", tetapi sampai saat itu, seperti yang dikatakan

Ya, perlu disebutkan bahwa apakah sesuatu "didukung" tidak semuanya relevan - aplikasi lama sebenarnya tidak harus di-porting ke kerangka kerja baru hanya karena sudah tersedia. Server web adalah kasus khusus meskipun karena ancaman keamanan. Dukungan patch keamanan jangka panjang untuk LTS akan membantu banyak orang.

@gulbanana Ini hanya menambahkan baris yang lebih tinggi ke aplikasi porting dari System.Web ke ASP.NET Core, karena Anda perlu mengubah kerangka kerja web, kerangka aplikasi yang mendasari dan kemudian meningkatkan atau menukar dependensi yang tidak kompatibel (yang mungkin melibatkan pembelian baru lisensi).

Jika Anda akan melakukan analisis biaya / manfaat, saya tidak yakin itu akan menguntungkan ASP.NET Core.

Hal ini terutama berlaku ketika Anda mengembangkan perangkat lunak berdasarkan proyek, dan tentu saja setiap proyek memiliki anggaran yang cukup ketat, jadi meskipun pemeliharaan rutin tentu saja memungkinkan, sulit untuk membenarkan penukaran seluruh kerangka kerja tanpa manfaat nyata yang terlihat. .

Jika Anda akan melakukan analisis biaya / manfaat, saya tidak yakin itu akan menguntungkan ASP.NET Core.

Jadi .. baiklah .. biarkan saja? Jika Anda tidak perlu bermigrasi ke ASP.NET Core, jangan lakukan itu ..
Bukan mencoba terdengar sarkastik atau apa pun, tetapi jika tidak ada keperluan bisnis untuk menyimpan aplikasi pada "hal-hal terbaru" maka jangan mem-portingnya. Manfaatnya adalah .NETFramework / ASP.NET classic masih didukung dan aplikasi Anda akan berjalan sebagaimana mestinya.

Porting sering kali tidak diperlukan, saya setuju - ASP.NET ke ASP.NET Core adalah perubahan besar, dan bagian dari perubahan itu adalah bahwa Core bergerak lebih cepat (3.0 juga akan memiliki perubahan yang merusak api, seperti halnya 2.0). Masalah diskusi ini adalah tentang perubahan netfx ke corefx, dan untuk sebagian besar aplikasi ASP.NET Core yang bukan merupakan perubahan besar lagi,

Ini tampaknya menghapus titik perantara "ASP.NET Core on .NET Framework" yang akan membuat migrasi jauh lebih bertahap dan lebih mudah. Setelah ini, migrasi ASP.NET MVC / WebAPI / etc. Penerapan ke ASP.NET Core akan menjadi perubahan yang sangat besar, mengubah kerangka web dan runtime yang mendasarinya sekaligus.

Untuk aplikasi perusahaan besar, saya berharap ini cukup menyakitkan. Tim saya telah mengamati hal ini dengan cermat selama satu atau dua tahun, tetapi:

• EntityFrameworkCore tidak melakukan semua yang kami butuhkan, dan hanya sekarang dengan .NET Core 3.0 adalah EntityFramework itu sendiri datang ke .NET Core. Berapa banyak dari itu dan platform apa yang akan dijalankannya, saya tidak percaya telah dikomunikasikan dengan jelas, dan saya mungkin perlu benar-benar menguji pratinjau build untuk melihatnya.

• Kisah OData tampaknya masih mengudara dalam hal aplikasi skala besar. Ada sejumlah _substantial_ pekerjaan (ulang) yang diperlukan untuk berpindah dari OData 3 / System.Data.Services ke OData 4 / WebAPI dan seterusnya. Ini adalah sesuatu yang belum terselesaikan selama beberapa tahun sekarang, dan sejujurnya saya tidak yakin itu akan pernah terjadi.

Selain itu, sekarang kita harus memangkas semua teknologi yang tidak didukung lainnya (AppDomains, Remoting, dll.) _First_, alih-alih dapat melakukan pekerjaan itu secara paralel atau pada tahap selanjutnya.

Selain itu, sekarang kita harus memangkas semua teknologi yang tidak didukung lainnya (AppDomains, Remoting, dll.) Terlebih dahulu, alih-alih dapat melakukan pekerjaan itu secara paralel atau pada tahap selanjutnya.

Mengapa Anda tidak dapat bermigrasi ke 2.1 dulu?

@davidfowl Kami mungkin dapat menggunakannya sebagai perantara, kecuali kami menemukan beberapa fitur baru di 3.0 / 3.1 / dll. yang kami butuhkan untuk bermigrasi. Saya belum melakukan analisis lengkap, sejauh ini kami sebagian besar diblokir di EF dan OData.

Fitur baru di ASP.NET Core 2.1 yang diperlukan untuk bermigrasi? Maksud saya ASP.NET Core 2.1 di .NET Framework.

Ketika masalah ini muncul beberapa tahun yang lalu, saya ingat pernah mengeluh bahwa terlalu sulit untuk memindahkan semuanya. Berikut kutipan dari komentar github lama yang saya buat saat itu:

bayangkan aplikasi web yang menggunakan Active Directory, atau otomatisasi Office COM, atau yang melakukan thumbnail menggunakan beberapa pustaka berbasis System.Drawing, atau berbagi kode dengan aplikasi WPF

Yang keren adalah pada .NET Core 3.0, semua skenario itu didukung. Sejumlah besar pekerjaan telah dilakukan untuk membuatnya lebih mudah.

@Vidahhh begitu juga aku

Secara hipotesis mungkin ada beberapa fitur yang kami gunakan di ASP.NET/MVC/WebAPI yang tidak diterapkan di 2.1 tetapi tiba di versi yang lebih baru. Dalam hal ini, 2.1 tidak akan menjadi batu loncatan yang bisa diterapkan.

Saya harus melakukan analisis yang lebih menyeluruh, untuk melihat apakah sebenarnya ada sesuatu yang penting yang kita butuhkan yang tidak ada di 2.1.

@Tokopedia

Sayangnya, ini hanya menyoroti satu hal: Anda benar-benar gagal menjadikan .NET Standard sebagai mobil depan ekosistem .NET . Itu tidak bergerak secepat yang seharusnya dan tidak lebih dari penyebut umum terendah yang selalu diperbarui di saat-saat terakhir, ketika semua platform menyertakan (atau akan menyertakan) API baru.

Anda tidak salah, tetapi Anda agak mengabaikan tujuan dari .NET Standard. Sasaran standar tidak pernah untuk mendorong inovasi, tetapi untuk mendorong konvergensi. Jika Anda mendekatinya dari sudut itu, dengan desain itu sesuatu yang harus tertinggal karena kita harus memikirkan konsep mana yang bisa universal atau bahkan harus universal. Jika Anda penasaran seperti apa tampilannya, saya mengundang Anda untuk melihat 35+ PR yang saya gabungkan selama tiga minggu terakhir setelah ditinjau oleh semua pemilik implementasi .NET.

Kami melihat .NET Core sebagai platform terdepan tempat inovasi terjadi. Kami telah membangun beberapa kemampuan yang memungkinkan kami untuk menangani churn dan risiko yang menyertainya, jauh lebih baik daripada yang dimiliki .NET Framework. Namun, tidak semua kemampuan yang penting bagi ekosistem .NET adalah bagian dari pengalaman Inti .NET. Misalnya, kompilasi sebelumnya jauh lebih menonjol di Xamarin dan Unity. Dan ketika kita mengambil fitur .NET Core dan menambahkannya ke standar, kita perlu mempertimbangkan lingkungan runtime, sistem operasi, dan batasan perangkat kerasnya.

Mungkin itu hanya saya, tetapi saya tidak pernah mengerti mengapa itu tidak bergerak secepat netcoreapp (yang merupakan yang pertama mendapatkan API baru, menurut definisi).

Kenyataannya adalah bahwa "bergerak cepat & melanggar" bukanlah sesuatu yang dihargai oleh seluruh audiens kita. Sudah cukup buruk jika kita harus menghapus API di versi utama .NET Core tetapi hampir tidak mungkin dilakukan dengan .NET Standard. Jadi kami harus bergerak lebih lambat dan hanya memasukkan konsep yang kami yakini cukup matang untuk penambahan.

Lakukan apa yang Anda janjikan: jadikan .NET Framework kerangka kerja stabil yang berkembang lebih lambat, bukan jalan buntu bagi orang-orang yang mempercayai Anda saat bermigrasi ke ASP.NET Core.

Itu masih membuat asumsi bahwa .NET Framework pada akhirnya akan mendapatkan semua fitur yang dimiliki .NET Core, tetapi dengan jeda waktu. Kami belajar bahwa itu tidak realistis. Kami dapat memutuskan untuk tidak berinovasi secara drastis di .NET Core atau menerima kenyataan teknis bahwa sebagian besar fitur baru tidak akan pernah berhasil kembali ke .NET Framework. Kami percaya bahwa kami melayani pelanggan kami dengan sebaik-baiknya untuk mempertahankan prop nilai inti .NET Framework (platform pengembangan yang matang & kaya) sementara juga memungkinkan pelanggan untuk mengeksploitasi kemampuan baru di .NET Core. Ke depannya, saya berharap kita akan lebih berkeinginan untuk berinovasi di area yang membutuhkan runtime, perpustakaan, dan perubahan bahasa seperti yang kita lakukan untuk Span<T> . Meskipun mahal, hal ini juga memungkinkan kami mengubah cara orang menulis kode. Contoh yang baik dari ini adalah implementasi default antarmuka, kemampuan untuk membuat kode generik yang melibatkan aritmatika, dapat menggunakan perangkat keras intrinsik, dll. Dan fitur-fitur tersebut kemungkinan persis seperti yang tidak akan kami backport ke .NET Framework karena risiko. .

Saya pikir sangat masuk akal jika web stack kami dapat memanfaatkan kemampuan ini; dan satu-satunya cara untuk melakukannya adalah dengan menghapus batasan untuk ASP.NET Core agar dapat berjalan di .NET Framework juga. Perlu diingat bahwa alasan asli kami membuat ASP.NET Core berjalan di .NET Framework adalah karena .NET Core tidak memiliki cukup API. Pada .NET Core 3.0 kami akan memiliki lebih dari 120k API yang ada . Itu lebih dari setengah dari keseluruhan .NET Framework dan bahkan menyertakan WinForms dan WPF. Ya, masih ada sejumlah besar API yang hilang, tetapi kami telah membuat terobosan besar ke dalam ekor panjang. Meskipun kami tidak akan pernah memiliki paritas 100%, saya berharap kami dapat menutup celah ini lebih jauh lagi, berdasarkan data pelanggan.

@ Yaakov-h Saya akan terkejut jika itu yang terjadi. Saat Anda melakukan analisis, beri tahu saya.

Anda tidak salah, tetapi Anda agak mengabaikan tujuan dari .NET Standard. Sasaran standar tidak pernah untuk mendorong inovasi, tetapi untuk mendorong konvergensi.

Dan Anda sedang menuju ke arah yang berlawanan: meninggalkan .NET Standard untuk ASP.NET Core karena tidak bergerak cukup cepat, memaksa paket NuGet yang menargetkan ASP.NET Core untuk meninggalkannya juga. Jangan buat saya berpikir itu konvergensi, saya tidak sebodoh itu: rofl:

Jika Anda mendekatinya dari sudut itu, dengan desain itu sesuatu yang harus tertinggal karena kita harus memikirkan konsep mana yang bisa universal atau bahkan harus universal.

Ini adalah pilihan, bukan masalah teknis: tidak ada yang menghalangi Anda untuk menentukan apakah API tertentu harus disertakan dalam versi baru .NET Standard saat meninjaunya untuk dimasukkan dalam corefx / coreclr.

Jika Anda penasaran seperti apa tampilannya, saya mengundang Anda untuk melihat 35+ PR yang saya gabungkan selama tiga minggu terakhir setelah ditinjau oleh semua pemilik implementasi .NET.

Saya tidak mengatakan ini adalah tugas yang mudah dan ini membuktikan maksud saya: Anda menunggu terlalu lama untuk membuat versi netstandard baru dan jarang sekali Anda melakukannya, ini adalah proses yang menyakitkan karena disertai dengan banyak API baru pada saat bersamaan.

Kenyataannya adalah bahwa "bergerak cepat & melanggar" bukanlah sesuatu yang dihargai oleh seluruh audiens kita.

Namun begitulah cara kerja setiap iterasi ASP.NET Core: ia datang dengan (terkadang besar) perubahan yang merusak yang membuat paket yang ditulis untuk versi tidak kompatibel dengan yang berikutnya. Namun, Anda tidak memberi kami banyak opsi: memperbarui atau tetap menggunakan versi lama selamanya, dengan kebijakan dukungan yang tidak ada hubungannya dengan apa yang dulu kami miliki (bukan hanya ASP.NET/.NET, siklus hidup Windows juga banyak. lebih pendek hari ini).

Ke depannya, saya berharap kita akan lebih berkeinginan untuk berinovasi di area yang membutuhkan runtime, perpustakaan, dan perubahan bahasa seperti yang kami lakukan untuk Span. Meskipun mahal, hal ini juga memungkinkan kami mengubah cara orang menulis kode. Contoh yang baik dari ini adalah implementasi default antarmuka, kemampuan untuk membuat kode generik yang melibatkan aritmatika, dapat menggunakan perangkat keras intrinsik, dll. Dan fitur-fitur tersebut kemungkinan persis seperti yang tidak akan kami backport ke .NET Framework karena risiko. .

Apa yang mencegah Anda untuk memperkenalkan versi .NET Framework berdampingan baru (katakanlah .NET Framework 5) yang menyertakan perubahan "berisiko" tersebut? Sekali lagi, ini bukan masalah teknis.

Adakah kesempatan untuk mempromosikan Microsoft.AspNetCore.Razor.Language dan Microsoft.AspNetCore.Razor luar aspnet atau menyimpannya di gelombang netstandard ? Meskipun pisau cukur hanya untuk html, ada beberapa pustaka yang menggunakannya untuk templat email dan akan sangat bagus jika kita dapat terus menggunakannya sebagaimana adanya.

Langkah ini menunjukkan kurangnya dukungan untuk standar bersih di peta jalan .NET, bertentangan dengan apa yang diberitahukan sebelumnya. Jika salah satu pustaka baru utama meninggalkan standar bersih, itu bukan pertanda baik untuk penerapannya.

Apakah ini langkah yang sekarang harus diantisipasi oleh pengembang .NET untuk semua pustaka baru lainnya yang dikembangkan oleh Microsoft di tempat terbuka? Bisakah komunitas mendapatkan pernyataan yang lebih resmi tentang masa depan netstandard dan penerapannya?

@terrajobst Saya benar-benar mengerti maksud Anda tentang tidak menambah .netstandard API tersebut yang tampaknya tidak siap untuk menjangkau semua platform (dan kemungkinan besar tidak akan pernah). Namun, itu tidak menghalangi Anda (MS) untuk memperkenalkan netstandard2.0 ketika, misalnya, UWP belum siap untuk mendukungnya. Seperti yang saya pahami, butuh upaya nyata untuk menambahkan dukungan itu beberapa waktu kemudian, tetapi Anda berhasil. Apakah itu cerita yang berbeda?

Dan Anda sedang menuju ke arah yang berlawanan: meninggalkan .NET Standard untuk ASP.NET Core karena tidak bergerak cukup cepat.

ASP.NET Core hanya masuk akal pada .NET Framework dan .NET Core, tetapi Standar .NET harus diterapkan oleh semua orang. Ini tidak masuk akal, misalnya, membuat Xamarin / Unity menyediakan API yang sebagian besar digunakan oleh beberapa web stack.

Ini adalah pilihan, bukan masalah teknis: tidak ada yang menghalangi Anda untuk menentukan apakah API tertentu harus disertakan dalam versi baru .NET Standard saat meninjaunya untuk dimasukkan dalam corefx / coreclr.

Itulah yang kami lakukan dalam .NET Core v1 hari. Kami telah memisahkan standar dari .NET Core dengan v2. Jadi ya, itu adalah pilihan tetapi itu tidak sembarangan. Tujuannya adalah agar dapat bergerak lebih cepat dengan .NET Core. Ini hanya membutuhkan lebih banyak waktu untuk mempertimbangkan bagaimana fitur bekerja dalam konteks N runtime selain runtime tunggal.

ini adalah proses yang menyakitkan karena dilengkapi dengan banyak API baru pada saat yang bersamaan.

Tidak, ini adalah proses yang menyakitkan karena Anda harus meninjau desain dengan beberapa pelaksana dan beberapa waktu proses yang berbeda. Namun, melakukannya setelah sebuah fakta, dikumpulkan & digabungkan jauh lebih murah daripada harus mengoordinasikannya saat kita pergi. Repo CoreFx adalah repo bervolume tinggi. Jauh lebih mudah bagi Xamarin dan Unity untuk meninjau fitur yang dibundel bersama daripada minum dari firehose dan berlangganan semua diskusi API di CoreFx.

Namun begitulah cara kerja setiap iterasi ASP.NET Core: ia datang dengan (terkadang besar) perubahan yang merusak yang membuat paket yang ditulis untuk versi tidak kompatibel dengan yang berikutnya.

Dan karena Anda tidak menyukai ini, Anda ingin memaksakannya pada semua orang dengan membuat .NET Standard cocok dengan .NET Core? Maaf, tapi argumen ini tidak masuk akal bagi saya.

Apa yang mencegah Anda untuk memperkenalkan versi .NET Framework berdampingan baru (katakanlah .NET Framework 5) yang menyertakan perubahan "berisiko" tersebut? Sekali lagi, ini bukan masalah teknis.

Apa yang membuat Anda berpikir ini bukan masalah teknis? Pengiriman versi .NET Framework secara berdampingan bukanlah solusi yang bisa diterapkan. Pertama-tama, ini cukup mahal karena fakta bahwa ini adalah komponen OS dan karenanya perlu diservis. Anda tidak tahu betapa rumitnya strategi percabangan / layanan / patching kami untuk .NET Framework 3.5 dan 4.x. Menambahkan yang ketiga hampir tidak praktis. Kedua, hanya melakukan itu juga memiliki risiko, karena kita perlu melakukan perubahan pada aktivasi untuk memilih runtime yang benar untuk hal-hal seperti komponen terkelola yang diaktifkan COM. Dan itu menimbulkan pertanyaan apakah kami mendukung in-proc secara berdampingan juga dan dengan berapa banyak kombinasi. Ini bukan tugas yang sederhana dan juga tidak bebas risiko.

Jangan buat saya berpikir itu konvergensi

@PinpointTownes Ini adalah konvergensi ... di .NET Core 😉

Ini tidak masuk akal, misalnya, membuat Xamarin / Unity menyediakan API yang sebagian besar digunakan oleh beberapa web stack.

Ada orang yang ingin menggunakan ASP.NET Core tidak hanya di .NET Core, tetapi juga di UWP, jadi mengapa tidak juga di Xamarin? https://aspnet.uservoice.com/forums/41199-general-asp-net/suggestions/32626766-support-for-asp-net-core-running-on-uwp-as-windows

Ada perbedaan antara sesuatu yang tidak masuk akal - untuk Anda - dan sesuatu yang tidak ingin Anda dukung.

Repo CoreFx adalah repo bervolume tinggi. Jauh lebih mudah bagi Xamarin dan Unity untuk meninjau fitur yang dibundel bersama daripada minum dari firehose dan berlangganan semua diskusi API di CoreFx.

Apakah saya menyarankan pendekatan ekstrim seperti itu? Saya yakin ada kompromi yang dapat Anda temukan, seperti membahas API standar baru segera (yaitu beberapa minggu) setelah diperkenalkan di .NET Core, setelah debu sedikit mengendap.

Dan karena Anda tidak menyukai ini, Anda ingin memaksakannya pada semua orang dengan membuat .NET Standard cocok dengan .NET Core? Maaf, tapi argumen ini tidak masuk akal bagi saya.

Anda berasumsi saya tidak suka itu tetapi Anda salah: Saya suka hal-hal yang bergerak cepat - meskipun sebagai pengelola 60 paket NuGet terkadang cukup menyakitkan. Yang tidak saya sukai adalah memaksa semua orang untuk bergerak dengan kecepatan yang sama, meninggalkan orang di tengah jalan karena mereka tidak bisa mengikutinya.

Saya tidak yakin bagaimana membuat .NET Standard bergerak secepat .NET Core dapat dilihat sebagai hukuman: tidak ada yang memaksa Anda untuk menargetkan netstandard TFM terbaru. Anda hanya akan melakukannya jika Anda membutuhkan set API terbaru. Jika Anda tidak membutuhkannya, targetkan versi yang lebih lama sehingga paket Anda dapat digunakan oleh kumpulan platform yang lebih luas.

Dari perspektif pengembang rata-rata, ini adalah kemenangan total: Anda dapat menulis paket menggunakan API mengkilap terbaru yang dapat digunakan oleh runtime .NET Core terbaru. Ketika platform lain menyusul, paket Anda juga dapat digunakan di sana: Anda tidak perlu menggunakan paket multi-penargetan atau publikasi ulang.

Pertama-tama, ini cukup mahal karena fakta bahwa ini adalah komponen OS dan karenanya perlu diservis. Anda tidak tahu betapa rumitnya strategi percabangan / layanan / patching kami untuk .NET Framework 3.5 dan 4.x. Menambahkan yang ketiga hampir tidak praktis.

Saya pasti bisa membayangkan itu tidak ideal untuk Anda, seperti menghapus dukungan .NET Framework untuk ASP.NET Core 3.0 tidak akan ideal untuk orang-orang yang tidak dapat pindah ke .NET Core. Tetapi apakah saya benar-benar salah mengira Anda - Microsoft - memiliki lebih banyak sumber daya untuk mengatasinya daripada rata-rata perusahaan harus pindah ke .NET Core? (Saya bahkan tidak berbicara tentang dependensi eksternal yang tidak Anda miliki dan kendalikan).

Kedua, hanya melakukan itu juga memiliki risiko, karena kita perlu melakukan perubahan pada aktivasi untuk memilih runtime yang benar untuk hal-hal seperti komponen terkelola yang diaktifkan COM. Dan itu menimbulkan pertanyaan apakah kami mendukung in-proc secara berdampingan juga dan dengan berapa banyak kombinasi. Ini bukan tugas yang sederhana dan juga tidak bebas risiko.

Tentu, itu tidak mudah. Dan itu berisiko. Tapi itulah yang ditunjukkan oleh versi utama: ada risiko hal-hal bisa rusak. Sekarang, antara dipaksa untuk tetap selamanya di ASP.NET Core 2.2 dan mengambil risiko untuk pindah ke .NET Framework 5 untuk menggunakan ASP.NET Core 3.0, menurut Anda apa yang akan dipilih orang?

Tetapi apakah saya benar-benar salah mengira Anda - Microsoft - memiliki lebih banyak sumber daya untuk mengatasinya daripada rata-rata perusahaan harus pindah ke .NET Core?

Dalam pengalaman saya, orang secara konsisten melebih-lebihkan berapa banyak sumber daya yang kita miliki dan berapa banyak pekerjaan yang harus kita lakukan untuk mendukung status quo saja.

Tapi dalam kasus ini, ini bukan masalah sumber daya. Kita bisa saja membuka .NET Framework dan kemudian semua PR akan langsung masuk ke .NET Framework. Ini ada hubungannya dengan kompleksitas mesin dan risiko compat. Ini adalah kerangka kerja terpusat dan bahkan rilis berdampingan berbagi sekumpulan sumber daya yang sama, seperti aktivasi. Kami telah membuktikan berkali-kali bahwa kami hanya dapat menugaskan orang pintar untuk melakukannya dengan benar.

Sekarang, antara dipaksa untuk tetap selamanya di ASP.NET Core 2.2 dan mengambil risiko untuk pindah ke .NET Framework 5 untuk menggunakan ASP.NET Core 3.0, menurut Anda apa yang akan dipilih orang?

Dalam pandangan saya, jauh lebih praktis untuk mendorong amplop API yang didukung di .NET Core untuk memungkinkan lebih banyak orang bermigrasi dengan lancar ke .NET Core daripada mencoba mem-backport fitur .NET Core ke .NET Framework. Yang bisa kita lakukan di sana adalah menyebabkan kesedihan. Perlu diingat bahwa rilis berdampingan datang dengan tantangan lain, seperti meminta TI untuk memungkinkan Anda menginstalnya, merangkainya ke installer, atau menunggu penghosting Anda menyediakan mesin, dll.

Apakah ini berlaku untuk semua bagian ASP.NET Core, atau akankah beberapa bagian berguna yang umumnya dapat digunakan kembali (seperti Microsoft.AspNetCore.Http.Extensions ) tetap berada di .NET Standard?

@tokopedia

@terrajobst Saya benar-benar mengerti maksud Anda tentang tidak menambah .netstandard API tersebut yang tampaknya tidak siap untuk menjangkau semua platform (dan kemungkinan besar tidak akan pernah). Namun, itu tidak menghalangi Anda (MS) untuk memperkenalkan netstandard2.0 ketika, misalnya, UWP belum siap untuk mendukungnya. Seperti yang saya pahami, butuh upaya nyata untuk menambahkan dukungan itu beberapa waktu kemudian, tetapi Anda berhasil. Apakah itu cerita yang berbeda?

Iya. .NET Standard 2.0 tidak memiliki API baru bersih. Itu didefinisikan sebagai persimpangan .NET Framework dan Xamarin. Apa pun delta-nya, kami hanya membutuhkannya untuk mendapatkan bilah kompatibilitas yang wajar dengan kode yang ada. Satu-satunya pekerjaan adalah di UWP dan .NET Core. Dan basis kode tersebut pada awalnya dirancang untuk menjadi penyetelan ulang modern .NET, yang kami pelajari menjadi tidak layak. Karena API / teknologi yang akan ditambahkan sebagian besar sudah matang dan didukung dalam lingkungan terbatas (Xamarin iOS), kompleksitasnya rendah - hanya satu ton pekerjaan porting.

Tapi sekarang kita berbicara tentang menambahkan kapabilitas dan konsep baru dan itu adalah binatang yang berbeda untuk dikendarai.

Dalam pengalaman saya, orang secara konsisten melebih-lebihkan berapa banyak sumber daya yang kita miliki dan berapa banyak pekerjaan yang harus kita lakukan untuk mendukung status quo saja.

Dalam pengalaman saya, Microsofties secara konsisten menilai terlalu tinggi berapa banyak sumber daya yang kita miliki dan berapa banyak pekerjaan yang harus kita lakukan untuk mendukung status quo saja. Argumen Anda benar-benar berfungsi di kedua arah: sweat_smile:

Dalam pandangan saya, jauh lebih praktis untuk mendorong amplop API yang didukung di .NET Core untuk memungkinkan lebih banyak orang bermigrasi dengan lancar ke .NET Core daripada mencoba mem-backport fitur .NET Core ke .NET Framework.

Mari kita perjelas: Saya mendukung itu , tetapi itu tidak akan berfungsi sampai .NET Core menangkap dan menerapkan sebagian besar / semua fitur yang dimiliki .NET Framework. Sampai itu terjadi, Anda masih akan melihat orang-orang diblokir oleh fitur yang hilang atau API yang hilang. Ada begitu banyak hal yang hilang sehingga tidak masuk akal untuk berpikir bahwa aplikasi monolitik warisan besar akan dapat dipindahkan ke .NET Core tanpa menimbulkan masalah.

Saya pasti mengerti kekhawatiran Anda. Namun pada akhirnya, apa yang membuat hidup Anda lebih mudah memiliki peluang untuk membuat hidup kami lebih menyakitkan: tidak mendukung .NET Framework akan menjadi PITA bagi kami.

Saya pasti mengerti kekhawatiran Anda. Namun pada akhirnya, apa yang membuat hidup Anda lebih mudah memiliki peluang untuk membuat hidup kami lebih menyakitkan: tidak mendukung .NET Framework akan menjadi PITA bagi kami.

Bagian itu yang saya mengerti. Tetapi alternatifnya tidak akan menjadi lebih banyak fitur di .NET Framework tetapi hanya ASP.NET Core yang kurang kuat.

Kami telah mencoba mengembangkan .NET Framework dan .NET Core bersama selama beberapa tahun terakhir. Ini tidak seperti kami mencoba untuk menghindari pekerjaan. Saya pribadi telah menghabiskan miliaran jam berbicara dengan teknisi runtime kami untuk mencoba memperbaiki, misalnya, mimpi buruk pengalihan yang mengikat. Atau dukungan .NET Standard 2.0 yang rusak di 4.6.1. Kami sudah mencoba. Ini bukan masalah kemauan, ini masalah kepraktisan.

itu tidak akan bekerja sampai .NET Core menangkap dan menerapkan sebagian besar / semua fitur yang dimiliki .NET Framework

Dalam pengalaman saya, ketersediaan beberapa API ini bahkan tidak relevan. Yang paling penting dalam lingkungan perusahaan adalah dukungan dan kompleksitas penerapan. Dan "didukung, dikirim, dan diperbarui secara otomatis dengan sistem operasi" jauh lebih menarik daripada dukungan 3 tahun yang kami dapatkan dari rilis .NET Core LTS dan penerapan rumit yang saat ini masih melibatkannya. Dan jujur ​​saja di sini: Masih belum ada perkakas yang stabil untuk .NET Core dan ASP.NET Core Saya yakin dapat mengatakan bahwa ini akan tetap menjadi status quo dalam satu tahun. Kami memiliki perubahan pada setiap rilis dan siapa yang tahu apakah referensi kerangka kerja baru dengan 3.0 akan menjadi solusi yang tepat. Jadi itu jelas merupakan titik sakit yang sangat besar ketika berhadapan dengan perusahaan di mana Anda tidak bisa hanya memperbarui sesuatu atau melakukannya dengan cara yang seharusnya; biasanya, mereka menginginkannya dilakukan dengan cara yang telah mereka lakukan selama 5+ tahun terakhir. Mereka dimanjakan oleh kerangka kerja dan apa pun yang tidak senyaman bagi mereka hampir menjadi penghenti.

Tetapi alternatifnya tidak akan menjadi lebih banyak fitur di .NET Framework tetapi hanya ASP.NET Core yang kurang kuat.

Itu cukup banyak yang saya sarankan tahun lalu: paket ASP.NET Core yang masih berfungsi pada .NET Framework (misalnya dengan menargetkan netstandard20 dan netcoreapp30 ) tetapi menawarkan set fitur yang lebih terbatas, dengan lebih sedikit kinerja yang menarik. Terkadang yang diinginkan orang adalah hal-hal yang berhasil. Bukan hal-hal baru yang berkilau. Bukan barang super cepat.

Kami telah mencoba mengembangkan .NET Framework dan .NET Core bersama selama beberapa tahun terakhir. Ini tidak seperti kami mencoba untuk menghindari pekerjaan. Saya pribadi telah menghabiskan miliaran jam berbicara dengan teknisi runtime kami untuk mencoba memperbaiki, misalnya, mimpi buruk pengalihan yang mengikat. Atau dukungan .NET Standard 2.0 yang rusak di 4.6.1. Kami sudah mencoba. Ini bukan masalah kemauan, ini masalah kepraktisan.

Kami jelas tidak setuju dalam segala hal tetapi tidak perlu dikatakan, saya sangat terkesan dengan apa yang kalian lakukan (ya, bahkan jika hal-hal seperti cegukan HttpClient cukup menyakitkan untuk dihadapi).

Saya sangat menyesal menjadi pria itu: sweat_smile:

Sejauh ini di bagian depan ASP.NET Core, saya telah melihat Razor muncul sebagai sesuatu yang konkret bahwa orang ingin tersedia di luar ASP.NET Core secara umum. Saya pikir itu masuk akal dan kita harus mengidentifikasi lebih banyak area seperti itu (ini akan menjadi diskusi yang lebih berguna). ASP.NET Core 2.1 dan 2.2 masih akan mendukung .NET framework tetapi menurut saya tidak masuk akal untuk mendukung .NET Framework selamanya.

@terrajin

Contoh yang bagus dari ini adalah implementasi default antarmuka, ... Dan fitur-fitur itu kemungkinan besar persis seperti yang tidak akan kita backport ke .NET Framework karena risiko.

Dan dengan pernyataan itu meninggal DIM. Intinya adalah evolusi warisan. Jika tidak berlaku untuk warisan, dan bahkan tidak dapat diterapkan pada perpustakaan yang mencoba menjembatani warisan dan yang baru, maka itu tidak membantu siapa pun.

Sejauh ini di bagian depan ASP.NET Core, saya telah melihat Razor muncul sebagai sesuatu yang konkret bahwa orang ingin tersedia di luar ASP.NET Core secara umum.

Anda dapat menambahkan paket Microsoft.Owin.Security.Interop backcompat ', ASP.NET Core Data Protection, dan dependensi yang mendasari ke daftar.

Itu cukup banyak yang saya sarankan tahun lalu: paket ASP.NET Core yang masih berfungsi pada .NET Framework (misalnya dengan menargetkan netstandard20 dan netcoreapp30 ) tetapi menawarkan set fitur yang lebih terbatas, dengan lebih sedikit kinerja yang menarik. Terkadang yang diinginkan orang adalah hal-hal yang berhasil. Bukan hal-hal baru yang berkilau. Bukan barang super cepat.

Kami juga telah membahas ini. Tantangannya adalah kami tidak dapat merangkumnya sepenuhnya karena beberapa API dan kapabilitas platform yang mendasarinya harus dimasukkan ke dalam API publik. Itu berarti pustaka yang terintegrasi ke dalam perangkat tengah ASP.NET Core juga harus menyediakan banyak implementasi. Tetapi lebih buruk, itu bahkan mungkin tidak mungkin tanpa membuat perpecahan karena tipe pertukaran publik mungkin hanya inti yang akan membuat dua versi ASP.NET Core yang tidak kompatibel lagi.

@Halo

Dan dengan pernyataan itu meninggal DIM. Inti dari evolusi warisan. Jika tidak berlaku untuk warisan, dan bahkan tidak dapat diterapkan pada perpustakaan yang mencoba menjembatani warisan dan yang baru, maka itu tidak membantu siapa pun.

Saya pikir Anda menggabungkan kode lama dengan instalasi yang sudah ada . Bahkan jika kami mem-port DIM ke .NET Framework, Anda masih harus meningkatkan ke versi yang lebih baru untuk menggunakan fitur tersebut. Meskipun ini kemungkinan merupakan fitur .NET Core-only, ia memungkinkan kita untuk mengembangkan .NET Core sambil tetap dapat menggunakan kode yang telah dikompilasi terhadap .NET Framework.

@terrajob Anda terus menyebut Unity. Apakah mereka memiliki implementasi CLR sendiri? Saya mendapat kesan mereka menggunakan Mono.

Unity memiliki beberapa implementasi .NET, termasuk versi AOT non-mono mereka sendiri, IL2CPP. Pustaka kelas dan API yang didukung juga berbeda dari Mono standar.

@terrajin

Saya pikir Anda menggabungkan kode lama dengan instalasi yang ada.

Tidak banyak perbedaan dalam hal aplikasi "lama" yang masih dipertahankan dan dikembangkan secara aktif. Ada perbedaan besar antara meningkatkan kerangka kerja vs. harus bermigrasi ke .NET Core.

Meskipun ini kemungkinan merupakan fitur .NET Core-only, ia memungkinkan kita untuk mengembangkan .NET Core sambil tetap dapat menggunakan kode yang telah dikompilasi terhadap .NET Framework.

Ke ujung Apa? Tak satu pun dari API yang "berevolusi" di .NET Core akan pernah berlaku untuk .NET Standard. Dan tidak ada penulis perpustakaan yang akan menyentuhnya mengingat bagaimana hal itu akan membuat divergensi yang tidak kompatibel di API mereka sendiri.

Saya setuju dengan @HaloFour. Satu-satunya orang yang dapat menggunakan DIM adalah penulis pustaka yang menargetkan .NET Core saja ... jadi pada dasarnya hanya corefx dan aspnetcore. Saya tidak bisa membayangkan ada orang lain yang mau mendekatinya.

Satu-satunya orang yang dapat menggunakan DIM adalah penulis pustaka yang menargetkan .NET Core saja ... jadi pada dasarnya hanya corefx dan aspnetcore.

Nah, cara lain pengungkapannya adalah bahwa satu-satunya platform di mana Anda tidak dapat menggunakannya adalah .NET Framework sementara Anda dapat menggunakan .NET Core, Xamarin, Mono, dan Unity.

Saya tidak bisa membayangkan ada orang lain yang mau mendekatinya.

Saya akan membayangkan fitur seperti ini akan memiliki pola adopsi tongkat hoki di perpustakaan, yang masuk akal. Di perpustakaan akhir, penulis akan selalu mempertimbangkan rangkaian fitur vs jangkauan. Untuk aplikasi, lebih mudah untuk memutuskan, karena Anda tahu (dan sering mengontrol) lingkungan target Anda.

@ yaakov-h

Apakah ini berlaku untuk semua bagian ASP.NET Core ...

Daftar tentatif tentang apa yang terjadi dengan paket apa ada di sini: https://github.com/aspnet/AspNetCore/issues/3756

@terrajobst Saya berpikir bahwa implementasi antarmuka default akan menjadi fitur bahasa C #. Mengatakan bahwa .NET Framework tidak mendukungnya, Anda secara praktis mengatakan bahwa .Net Framework akan selamanya macet dengan C # versi 7.3 atau paling banyak berikutnya. Perbedaan itu bukanlah sesuatu yang diinginkan siapa pun di ekosistem.

Kami menjalankan beberapa beban kerja .NET Core tetapi juga menjalankan proyek multi-tahun .NET FX.

Mengupgrade ke .NET Core (bahkan pada .NET Framework untuk memulai) dengan aman adalah tugas yang sangat besar.

Apakah ada rencana bagi Microsoft untuk merilis beberapa perkakas untuk membantu "meningkatkan" proyek dari setidaknya ASP.NET di .NET FX ke ASP.NET Core ke .NET FX?

Ada artikel MSDN tentang membuat Proyek VS baru dan mengimpor tampilan dan mengatur ulang proyek tetapi ada begitu banyak hal warisan (Asaks global, perutean, ....) sehingga saya berharap ada tempat sentral yang mendokumentasikan cara lama vs cara baru untuk membantu porting semuanya.

Apa yang mencegah Anda untuk memperkenalkan versi .NET Framework berdampingan baru (katakanlah .NET Framework 5) yang menyertakan perubahan "berisiko" tersebut?

Pada titik itu, apakah ada keuntungan jika tidak menggunakan .NET Core 3.0? Ini sudah berdampingan dan memiliki perubahan "berisiko". Akankah rangkaian fitur berikutnya untuk .NET Core memerlukan .NET Framework 6 dll.?

Dengan API yang sudah ada di .NET Core 2.0 dan set fitur baru yang datang ke .NET Core 3.0 tidak .NET Core memenuhi ".NET Framework 5" dengan Framework 4.x menjadi versi LTS yang sangat panjang?

Di tebakan; pada titik ini, itu akan menjadi tantangan teknik yang lebih kecil untuk menutupi setiap celah teridentifikasi tertentu yang dimiliki .NET Core 3.0 dari .NET Framework 4.x daripada mengubah .NET Framework untuk berperilaku sebagai .NET Core.

Saran praktis: Apakah ada kemungkinan ASP.NET Core 2.2 akan menjadi LTS dengan durasi dukungan _extended_ di atas 3 tahun umum?

Saya yakin itu akan memuaskan mereka yang harus tetap menggunakan kerangka kerja penuh untuk saat ini, sementara juga memberi mereka (1) cukup waktu untuk benar-benar bermigrasi ke .NET Core dan (2) motivasi yang cukup untuk bermigrasi dari ASP.NET MVC ke ASP .NET Core (ketika mereka tidak dapat pindah ke .NET Core _yet_).

Saya masih tidak berpikir ini jelas, apakah ASP.NET Core di .NET Framework mengikuti .NET Core 2.1 LTS atau apakah itu mengikuti siklus dukungan .NET Framework v4.6.1 + (yaitu karena berjalan di .NET FX) di mana itu didukung dalam waktu dekat?

@mythz ASP.NET Core tercakup dalam siklus hidup dukungan .NET Core , apa pun platform tempat Anda menjalankannya.

Saya pikir langkah terbaik di sini adalah benar-benar menjaga standar .net diperbarui setidaknya untuk 3.0, 4.0 dan 5.0 dan benar-benar menyampaikan bahwa pada titik tertentu kerangka kerja .net akan sepenuhnya bermigrasi ke inti .net.
yang lainnya hanya setengah matang.

Apakah Anda memiliki pelanggan yang sudah membayar untuk dukungan LTS hari ini? (Hanya pertanyaan yang menyelidik). Berapa lama waktu yang cukup?

@terrajobst Sepertinya masalah sebenarnya adalah standar bersih itu monolitik. Kedengarannya seperti kita tidak membutuhkan netstandard tetapi set API berversi sebagai gantinya. Itu juga akan menjadi TFM, misalnya base2.0 + span akan menjadi dua set API.

Anda kemudian dapat mengembangkan standar berdasarkan set API dan mungkin hanya mengimplementasikan beberapa set API dalam kerangka penuh. (Ini juga akan mempermudah platform lain untuk mengimplementasikan netstandard, karena beberapa set API dapat ditinggalkan).

Dengan set API di tempat, build terpisah dari ASP.NET Core akan dibuat untuk target yang kurang mendukung seperti kerangka kerja penuh.

@Sebazzz itu

@davidfowl Saya tidak berpikir itu "aneh" atau "tergelincir" sama sekali. Kedengarannya persis seperti yang kita butuhkan, jika sedikit kurang halus daripada cara dia mengusulkannya. Jika masalah dengan semua ini adalah bahwa kami akhirnya harus memasukkan semua server web ini ke dalam implementasi seperti Xamarin dan Unity yang tidak peduli dengan server web, maka IMO membuat grup API ".NET Web Server Standard" terpisah akan menjadi solusi yang ideal.

@masonwheeler @Sebazzz

@terrajobst Sepertinya masalah sebenarnya adalah standar bersih itu monolitik. Kedengarannya seperti kita tidak membutuhkan netstandard tetapi set API berversi sebagai gantinya. Itu juga akan menjadi TFM, misalnya base2.0 + span akan menjadi dua set API.

Kami mencoba ini dalam berbagai bentuk (profil, PCL, kontrak longgar, dan kemudian kumpulan kontrak berversi yang menjadi .NET Standard 1.x). Terlalu sulit untuk menggunakan alat dan memahami aturan kompatibilitas dari waktu ke waktu (saat versi platform dan set API berkembang). Standar .NET seperti saat ini adalah yang paling dekat yang pernah kami kunjungi dengan model yang bisa diterapkan. Meskipun tidak sempurna, setidaknya itu adalah sesuatu yang bisa saya jelaskan dalam beberapa menit dan tidak membuat kepala orang meledak.

Saya senang membahas .NET Standard lebih detail, tetapi saya setuju dengan @davidfowl bahwa ini bukan milik di sini. Jika Anda ingin, ajukan masalah di https://github.com/dotnet/standard.

Sunting Saya telah menandai komentar Standar .NET kami sebagai di luar topik.

@ Shayan-To

@terrajobst Saya berpikir bahwa implementasi antarmuka default akan menjadi fitur bahasa C #. Mengatakan bahwa .NET Framework tidak mendukungnya, Anda secara praktis mengatakan bahwa .Net Framework akan selamanya macet dengan C # versi 7.3 atau paling banyak berikutnya. Perbedaan itu bukanlah sesuatu yang diinginkan siapa pun di ekosistem.

Ini adalah fitur yang membutuhkan perubahan bahasa serta perubahan waktu proses. Ini mirip dengan obat generik karena mengubah aturan sistem tipe. Secara umum, C # tidak tahu framework mana yang Anda kompilasi (C # baru saja melewati satu set rakitan referensi yang mendeskripsikan API yang ditawarkan framework). Fitur C # apa pun yang tidak memerlukan perubahan API (misalnya operator penggabung-nol ?. atau _ untuk membuang ekspresi) akan didukung. Itu identik dengan bagaimana kompilator selalu bekerja ketika Anda menggunakan kompilator & versi bahasa terbaru dan menargetkan versi lama .NET Framework yang tidak memiliki API yang sesuai. Misalnya, async / await tidak akan berfungsi jika Anda menargetkan .NET Framework 3.5 atau 4.0 - Anda harus berada di 4.5 atau lebih tinggi untuk menggunakan Task .

Man yang saya rasakan untuk kalian .. Pindah penuh ke .net core, imo, adalah hal yang benar untuk dilakukan dalam jangka panjang dan saya lebih suka kecepatan inovasi yang lebih tinggi yang akan memberikan.

Bagaimanapun orang _akan_ marah tentang hal ini .. Sebagian besar dari itu adalah komunikasi. Ketika LTS 2,1 3 tahun diumumkan, orang-orang di fullfx diharapkan dapat beralih ke 3.0 dan masih menjalankan fullfx, mereka akan menjual inti asp.net kepada pemberi kerja dan klien dengan mempertaruhkan reputasi mereka sendiri, dan sekarang mereka akan merasa seperti permadani telah ditarik di bawah mereka. Apa yang mereka jual sebagai solusi jangka panjang, masa depan asp.net, sekarang (perseptual) dibatasi pada 3 tahun dukungan

Tidak masalah bahwa sekarang lebih mudah untuk bermigrasi, beralih platform akan selalu berisiko, dan itu akan menjadi risiko dan upaya pengembangan yang tidak diharapkan, direncanakan, atau dianggarkan oleh orang-orang ini.

Sebagian besar pengembang akan _ ingin_ pindah ke .net core 3, tetapi selain berpotensi memiliki dependensi, mereka tidak dapat mengubah (atau melibatkan perubahan risiko) mereka sekarang harus melakukan migrasi _again_ dan berjanji bahwa _waktu ini_ akan menjadi investasi jangka panjang. . ini bisa menjadi penjualan yang sulit, tetapi mereka akan merasa terdorong untuk melakukannya karena siklus dukungan 3 tahun ..

Sekali lagi, saya menolak fullfx, tetapi saya benar-benar berpikir Anda harus mempertimbangkan untuk memperpanjang LTS untuk versi terakhir yang mendukungnya dengan jumlah yang cukup besar. Juga berkomunikasi dengan sangat jelas, seperti di blog, konferensi / sesi, dan sebagainya, bagian mana yang masih standar bersih dan bagaimana orang yang masih menggunakan kerangka kerja 2.1 / penuh masih dapat memanfaatkannya.

Jika tidak, Anda memiliki risiko besar narasi menjadi "Microsoft meninggalkan pengembangnya yang berdedikasi lagi" Tidak mengatakan itu adil , hanya mencoba memperingatkan Anda tentang apa yang mungkin terjadi.

Apa yang masuk akal tentang waktu untuk LTS?

6 tahun mungkin? Saya pikir perpesanan akan memainkan peran besar dalam resepsi .. Pada akhirnya, beberapa orang akan kesal tidak peduli apa: /

@davidfowl @ aL3891

Sebagai referensi, Java LTS "Premier Support" adalah 5 tahun dengan "Extended Support" (berbayar) dari tiga tahun tambahan. Java 11, yang merupakan rilis LTS dan dirilis bulan lalu, akan didukung masing-masing hingga September 2023 dan September 2026

Kami sedang menyelidiki penawaran LTS "dukungan tambahan" dan akan memberikan detail lebih lanjut saat kami memilikinya. Ini berpotensi menawarkan pelanggan yang membutuhkan ASP.NET Core yang didukung pada versi .NET Framework (2.1.x) opsi yang lebih lama daripada periode dukungan LTS saat ini.

FYI juga, saya mengobrol sedikit tentang pengumuman hari ini di Standup Komunitas ASP.NET: https://www.youtube.com/watch?v=-b59KvkWBUo&list=PL1rZQsJPBU2StolNg0aqvQswETPcYnNKL&index=0

Target standar .net, silakan. inti asp.net dapat menargetkan .netstandard2.1 atau 3.0 dan membiarkan mono dan .netframework menyusul nanti, tetapi jika inti asp.net menargetkan netcoreapp , maka perpustakaan apa pun mencoba mengakses tipe dari pustaka aspnetcore itu haruslah pustaka .netcoreapp .

dan .net core akan selalu dirilis lebih cepat dari .net framework dan mono ,
mono dan .netframework pada akhirnya akan menghabiskan .netcoreapp assemblies jika microsoft mulai menargetkan lebih banyak kerangka kerja / pustaka ke netcoreapp (itu akan menyebabkan lebih banyak pustaka pada target nuget .netcoreapp juga).

jika demikian, .netstandard akan menjadi .netcoreapp 😂

@ John0King tolong berikan contoh jenis yang Anda butuhkan di luar ASP.NET Core.

1. Razor seperti yang disebutkan @poke
2. Filter MVC Antarmuka / Atribut (Saya memiliki perpustakaan kelas pembantu yang berisi beberapa ActionFilters dan TagHelpers dan metode statis / ekstensi umum untuk string, int, panjang dll. Saya menggunakan PrivateAssert="All" untuk referensi paket MVC jadi ketika saya menggunakan ini perpustakaan beberapa di mana lagi, proyek itu tidak harus merujuk rakitan MVC, saya kira saya harus memisahkan perpustakaan menjadi dua, satu adalah .netstandard dan .netcoreapp )

pertanyaan lainnya adalah: Apakah akan menjadi masalah untuk jenis perpustakaan kelas yang harus saya buat? ( .netstandard vs .netcoreapp ). Hari ini cukup sederhana di asp.net core 2.1. pilih .netstandard untuk perpustakaan kelas, pilih .netcoreapp atau net461 untuk proyek web.

mono dan .netframework pada akhirnya akan menggunakan rakitan .netcoreapp jika microsoft mulai menargetkan lebih banyak kerangka kerja / pustaka ke netcoreapp (itu akan menyebabkan lebih banyak pustaka pada target nuget .netcoreapp juga)

Ini akan terjadi jika orang tidak berusaha lebih keras untuk memisahkan apa yang harus datang ke perpustakaan .netstandard dan apa yang datang ke perpustakaan .netcoreapp

Filter MVC Antarmuka / Atribut (Saya memiliki perpustakaan kelas pembantu yang berisi beberapa ActionFilters dan TagHelpers dan metode statis / ekstensi umum untuk string, int, panjang dll. Saya menggunakan PrivateAssert = "Semua" untuk mereferensikan paket MVC jadi ketika saya menggunakan perpustakaan ini) beberapa di mana lagi, proyek itu tidak harus mereferensikan rakitan MVC, saya kira saya harus memisahkan pustaka menjadi dua, satu adalah .netstandard dan lainnya .netcoreapp)

Bisakah Anda menjelaskannya? Ini tidak masuk akal. MVC adalah kerangka kerja ASP.NET Core dan tidak dapat digunakan secara mandiri.

@davidfowl pustaka ini adalah pustaka kelas pembantu, saya dapat menggunakan filter tersebut ketika saya bekerja di proyek MVC inti asp.net dan hanya menggunakan metode ekstensinya di aplikasi konsol.

@davidfowl pustaka ini adalah pustaka kelas pembantu, saya dapat menggunakan filter tersebut ketika saya bekerja di proyek MVC inti asp.net dan hanya menggunakan metode ekstensinya di aplikasi konsol.

Saya masih tidak mengerti. Apakah Anda berbicara tentang perpustakaan yang memiliki hal-hal MVC dan hal-hal acak lainnya?

Sayangnya, hal semacam itu biasa terjadi dalam perangkat lunak perusahaan - 'perpustakaan pembantu' yang memiliki, seperti, utilitas perusahaan untuk MVC + utilitas perusahaan untuk WPF + utilitas perusahaan untuk telerik ...
Lebih masuk akal bila '.NET' adalah satu platform terpadu.

@detikcom ya. Ada beberapa kelas / metode di perpustakaan helper Anda dapat menggunakan jenis tersebut di mana-mana. dan ketika u mereferensikan pustaka ini dalam proyek mvc, maka u dapat menggunakan kelas / metode terkait mvc.

Yah, ini hanya memaksa perpustakaan Anda untuk dilapisi dengan lebih baik 😉

Sayangnya ini berarti bahwa siapa pun yang melakukan penerapan di lokasi masih, tidak dapat mendukung perangkat lunak mereka selama lebih dari 3 tahun. Misalnya, segera setelah Anda merilis aplikasi yang menargetkan .netcore 3.0, pelanggan Anda memiliki waktu 3 tahun dan kemudian dipaksa untuk meningkatkan. Beberapa industri yang akan baik-baik saja, beberapa lainnya pasti tidak.

Itulah masalah terbesar dengan ini, dan membuat .net core benar-benar non-go untuk banyak orang, saya bayangkan. Saya sebenarnya setuju bahwa pada akhirnya ini adalah arah yang benar untuk dituju, tetapi saya yakin ini akan menghentikan banyak tempat menuju .net core.

Sangat membutuhkan tanggapan dari tim .net tentang ini.

Masalahnya, ASP.NET Core adalah kerangka kerja web. Dalam industri apa aman untuk menjalankan situs web selama> tiga tahun tanpa modifikasi sama sekali? Jika ini bukan kerentanan keamanan, itu adalah browser yang membatalkan hal yang Anda andalkan, atau TLS 1.4, atau pengguna yang menuntut agar situs berfungsi di jam tangan baru mereka.

Selama rentang waktu itu, Anda seharusnya bisa lolos hanya dengan sedikit perubahan dan pembaruan ketergantungan kecil, tetapi berencana untuk tidak memperbarui aplikasi web sama sekali selama bertahun-tahun adalah tindakan yang sembrono.

Saya pikir ini akan lebih cocok untuk komunitas jika Anda hanya meningkatkan periode LTS untuk ASP.NET Core 2.1 menjadi 5-7 tahun.

Dalam pengalaman kami, pengembangan korporat-y bergerak dengan kecepatan glasial dibandingkan dengan pengembangan web "modern", namun mereka masih ingin memastikan bahwa mereka tidak melakukan investasi baru pada platform yang jauh lebih lama. Aplikasi ini sering kali membutuhkan waktu lebih dari setahun bahkan untuk _launch_, apalagi dapat melakukan peningkatan besar dalam waktu 3 tahun. Aplikasi web perusahaan (biasanya hanya internal) ini sering kali didukung selama 7-10 tahun, meskipun menurut saya tidak masuk akal untuk LTS untuk ASP.NET Core 2.1 menjadi 10 tahun. 5 tahun terasa seperti solusi yang lebih baik dari 3, dengan 7 tahun menjadi angka yang pasti akan membuat hampir semua orang nyaman.

Dan ini hanya diperlukan karena ASP.NET Core 3.0 memerlukan perubahan besar yang dapat menghilangkan dukungan .NET Framework. Rilis LTS mendatang tidak boleh dipegang dengan standar ini, dengan asumsi perubahan yang melanggar tidak sebesar ini.

Saya tidak yakin bagaimana membuat .NET Standard bergerak secepat .NET Core dapat dilihat sebagai hukuman: tidak ada yang memaksa Anda untuk menargetkan netstandard TFM terbaru. Anda hanya akan melakukannya jika Anda membutuhkan set API terbaru. Jika Anda tidak membutuhkannya, targetkan versi yang lebih lama sehingga paket Anda dapat digunakan oleh kumpulan platform yang lebih luas.

Bagaimana jika platform tidak pernah menyusul? Kemudian Anda akan memiliki Perpustakaan yang menargetkan netstandard2.3 yang membutuhkan fitur A yang hanya tersedia di .NET Core dan Xamarin, tetapi tidak mungkin untuk .NET Framework.

Kemudian netstandard2.4 keluar, memiliki beberapa Apis baru dan beberapa API ini dapat ditransfer ke .NET Framework. Apa sekarang?

Bagaimana Anda menargetkan pustaka yang membutuhkan fitur dari netstandad2.4 yang berjalan pada .NET Framework, tetapi netstandard2.4 tidak dapat menargetkan .NET Framework, karena tidak dapat mengimplementasikan netstandard2.2 .

Kemudian Anda harus mengkompilasi silang ke tiga platform:
netstandard2.2 untuk platform lama dan net4x untuk standar bersih hanya untuk mendukung fitur yang ditambahkan pada netstandad2.4 dan net4x can also implement but not support because of APIs that went into netstandard2.3`.

Bagaimana hal itu akan memudahkan pembuat paket untuk menulis dan mengirimkan paket nugget mereka?

Semuanya hanya dapat berfungsi ketika penyebut umum terendah yang akan didukung semua platform mengalir ke standar bersih. Kecuali jika Anda menginginkan lebih banyak API memberikan pengecualian PlatformNotSupported , jika tidak maka akan menyebabkan fragmentasi dalam standar bersih.

Saya pasti bisa membayangkan itu tidak ideal untuk Anda, seperti menghapus dukungan .NET Framework untuk ASP.NET Core 3.0 tidak akan ideal untuk orang-orang yang tidak dapat pindah ke .NET Core. Tetapi apakah saya benar-benar salah mengira Anda - Microsoft - memiliki lebih banyak sumber daya untuk mengatasinya daripada rata-rata perusahaan harus pindah ke .NET Core? (Saya bahkan tidak berbicara tentang dependensi eksternal yang tidak Anda miliki dan kendalikan).

Apa masalah sebenarnya di sini? Orang yang tidak dapat berpindah dari ASP.NET Legacy ke ASP.NET Core tidak akan dapat memindahkan apakah ASP.NET Core menargetkan .NET Framework atau tidak. Kemungkinan besar alasan mereka tidak bisa atau tidak mau adalah pustaka khusus System.Web , yang tidak akan berfungsi baik pada ASP.NET Core di .NET Framework. Orang-orang yang memiliki aplikasi mereka sekarang, jelas sudah memiliki perangkat kerja.

Dan orang-orang yang sudah menggunakan ASP.NET Core 2.1 di .NET Framework, jika berfungsi, mengapa ingin pindah? Jelas semua yang dibutuhkan sudah ada dan segala sesuatu yang baru datang ke ASP.NET Core 3.0 bagus untuk dimiliki.

Adapun yang lainnya:
Ada banyak cara untuk memigrasi aplikasi ke .NET Core, yaitu memecah bagian dari aplikasi monolitik lama dan menerapkannya kembali sebagai Microservices, cara ini juga menurunkan risiko dan menyebarkannya seiring waktu

Bagaimana jika platform tidak pernah menyusul? Kemudian Anda akan memiliki Pustaka yang menargetkan netstandard2.3 yang membutuhkan fitur A yang hanya tersedia di .NET Core dan Xamarin, tetapi tidak mungkin untuk .NET Framework.

Jika API tidak dapat diterapkan oleh sebagian besar platform yang mendukung .NET Standard, maka kemungkinan besar itu tidak boleh menjadi bagian dari standar, bukan? (dalam praktiknya, sangat mungkin sebaliknya, karena platform yang dijalankan Xamarin umumnya jauh lebih terbatas). Saya berharap masalah seperti ini terdeteksi saat meninjau API untuk dimasukkan dalam .NET Standard, tetapi saya mungkin salah.

Dan orang-orang yang sudah menggunakan ASP.NET Core 2.1 di .NET Framework, jika berfungsi, mengapa ingin pindah?

• Dukung? (dukungan 3 tahun sangat pendek)
• Perbaikan bug hanya ada di 3.0? (Versi LTS hanya mendapatkan perbaikan untuk bug dan kerentanan kritis)
• Anda perlu merujuk pustaka yang hanya kompatibel dengan versi ASP.NET Core terbaru?

Ada banyak cara untuk memigrasi aplikasi ke .NET Core, yaitu memecah bagian dari aplikasi monolitik lama dan menerapkannya kembali sebagai Microservices, cara ini juga menurunkan risiko dan menyebarkannya seiring waktu

Ya, tentu, secara teori itulah cara ideal untuk mengatasinya. Tapi:

• Beberapa aplikasi bergantung pada pustaka eksternal yang tidak dapat Anda kendalikan. Jika pustaka tidak berfungsi pada .NET Core dan vendor tidak ingin (atau tidak dapat) mem-portnya, Anda kurang beruntung.
• Bermigrasi ke .NET Core bisa mahal dan memakan waktu. Jika tim terbaik Microsoft pun berjuang dengan itu, apakah menurut Anda akan semudah itu bagi tim biasa? Kami harus menunggu 3.0 untuk melihat Entity Framework 6 akhirnya kompatibel dengan .NET Standard.

Jangan salah mengartikan apa yang saya katakan: Saya mendukung penggunaan .NET Core untuk aplikasi baru. Tetapi fakta bahwa ASP.NET Core kompatibel dengan .NET Framework membantu banyak perusahaan pindah ke ASP.NET Core dengan biaya yang masuk akal. Saya yakin itu tidak akan pernah begitu populer tanpa jalur migrasi yang "tidak terlalu sulit".

Microsoft, apakah terlalu berlebihan jika meminta untuk memperpanjang dukungan 2.1? 2021 tidak cukup lama bagi kami dan kami tidak memiliki cukup sumber daya / waktu untuk melakukan konversi itu. Mungkin setidaknya sampai 2022? Satu tahun ekstra akan benar-benar memberi kita kesempatan untuk membuat perubahan, meski menyakitkan.

Perlu diingat bahwa banyak vendor pihak ketiga kami belum memigrasikan pustaka mereka ke kompatibilitas .Net Core, yang merupakan alasan terbesar untuk hangup kami.

FYI https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434521855

Sementara saya melihat memperluas LTS sebagaimana diperlukan, IMO menggulirkan ASP.NET Core pada .NET FX ke dalam siklus dukungan .NET FX juga harus dipertimbangkan. Sebagai permulaan, memiliki bagian yang berbeda dari .NET Framework membingungkan pada siklus dukungan yang berbeda di mana menggabungkannya bersama-sama akan lebih masuk akal. Kedua, kode untuk 2.1 sudah ditulis, dirilis, dan diandalkan sehingga akan membutuhkan sumber daya yang jauh lebih sedikit untuk mendukung 2.1 daripada secara aktif mengembangkannya yang bersinggungan dengan .NET Core 3.0. Jika tim yang sama mempertahankan keduanya, saya juga akan menganggap basis kode aktif ASP.NET Core yang baru dan lebih familier akan lebih mudah didukung daripada basis kode ASP.NET klasik yang sama sekali berbeda.

Ketika MS mengumumkan EOL of Silverlight 5 pada tahun 2012, mereka masih mendukungnya hingga Oktober 2021 (meskipun dirilis di Chrome pada tahun 2015 dan Firefox pada tahun 2017). Ini untuk teknologi yang ditinggalkan sepenuhnya yang tidak terjadi di sini, sebagian besar basis kode yang sama, model pemrograman, tim pengembang aktif masih mengerjakannya, hanya menjalankan perangkat lunak yang ada di .NET Framework yang ditinggalkan.

Sebelum pengumuman ini, ada pesan yang kuat MS tidak pernah meninggalkan .NETFramework bahwa itu bagus untuk beban kerja khusus Windows (berbeda dengan .NET Core untuk beban kerja lintas platform / kinerja tinggi) dan bahwa ASP.NET Core adalah masa depan model pemrograman yang akan mendukung .NET Framework dan .NET Core di masa depan dengan .NET Standard sebagai solusi untuk mengembangkan pustaka yang menargetkan banyak platform.

Sekarang jelas bahwa .NET Core adalah masa depan untuk semua proyek baru, tetapi ini tentang bagaimana memperlakukan investasi yang ada dan Pelanggan yang sudah ada yang telah membuat keputusan berdasarkan panduan ini hingga sekarang. Bagaimana kemajuan tim Pengembang .NET yang ada saat perlu mendukung sistem yang ada, mereka akan dipaksa untuk tetap menggunakan ASP.NET klasik (di mana keterampilan / pengetahuan mereka yang sudah usang dari hari ke hari) sementara konteks beralih untuk mengembangkan Aplikasi baru di .NET Core.

Jika saya dipaksa untuk memelihara sistem pada .NETFramework, saya lebih suka mengembangkannya pada model pemrograman ASP.NET baru dengan akses ke basis pengetahuan / ekosistem aktif kemudian dipaksa untuk kembali menggunakan ASP.NET lama tanpa batas waktu tetapi itu tidak akan mungkin kecuali ASP.NET Core di FX memiliki tingkat dukungan yang sama dengan WebForms.

MS juga memiliki kesempatan untuk memposisikan ASP.NET Core di FX sebagai lingkungan pengembangan yang "stabil" (yaitu tetap di ASP.NET Core 2.1). Tidak mudah menjadi pengembang .NET dalam beberapa tahun terakhir sejak .NET Core dimulai. Kami secara efektif harus meninggalkan semua upaya kami untuk mencoba porting ke .NET Core <1.x dengan itu menjadi sulit untuk mengikuti aliran konstan perubahan yang melanggar, hanya sampai .NET Core 2.x kami dapat untuk mendukungnya dan memindahkan Aplikasi yang ada ke atas. Di sisi lain, pengembang ASP.NET Framework yang ada telah melihat platform pilihan mereka mandek dan kemudian digantikan oleh model pemrograman ASP.NET Core baru dan dengan ekstensi mengikis keterampilan / pengetahuan yang ada. Penghentian dukungan untuk ASP.NET Core di FX membunuh strategi migrasi bertahap yang populer menuju .NET Core di mana mereka mengambil risiko (tanpa fallback kontingensi) yang berjalan pada platform yang ditinggalkan kecuali mereka dapat meningkatkan seluruh sistem mereka ke .NET Core (risiko yang dapat mencegah upaya migrasi dari pertimbangan) itu juga menutup peluang mereka untuk dapat berpartisipasi dalam model dev ASP.NET Core masa depan jika mereka tidak dapat memigrasi sistem mereka yang ada tempat mereka bekerja sehari-hari, yang akan hanya mungkin jika menikmati dukungan yang sama dengan WebForms - yang saya harap masih dalam pertimbangan.

Tidak ada yang disebutkan: dalam aplikasi inti asp.net, kami perlu menghosting layanan WCF dan ini adalah satu-satunya masalah untuk bermigrasi dari .net framework. Saya tidak melihat berita apa pun tentang dukungan wcf sisi server pada .net core 3, sayangnya.

@DamianEdwards @davidfowl @natemcmaster Kita satu perahu. Perusahaan saya memiliki sejumlah produk yang berjalan di ASP.Net Core dengan framework .Net Full, dan kami mendukungnya untuk waktu yang lebih lama dari 3 tahun, karena seberapa lambat industri yang kami jual bergerak. Memperluas LTS untuk .net core 2.2 akan menjadi tidak berarti dalam situasi kami karena kami harus mem-port aplikasi inti ASP.net kami kembali ke ASP.Net. Tentunya hal ini mengalahkan intinya guys! Apakah Anda hanya menyarankan aplikasi pendukung untuk periode waktu yang lebih singkat? Sayangnya ini juga sesuatu yang tidak dapat kami kendalikan. Industri tempat kami bekerja dapat membutuhkan waktu satu tahun hanya untuk meluncurkan perangkat lunak baru kami.

Sayangnya ini berarti bahwa siapa pun yang melakukan penerapan di lokasi masih, tidak dapat mendukung perangkat lunak mereka selama lebih dari 3 tahun. Misalnya, segera setelah Anda merilis aplikasi yang menargetkan .netcore 3.0, pelanggan Anda memiliki waktu 3 tahun dan kemudian dipaksa untuk meningkatkan. Beberapa industri yang akan baik-baik saja, beberapa lainnya pasti tidak.

Itulah masalah terbesar dengan ini, dan membuat .net core benar-benar non-go untuk banyak orang, saya bayangkan. Saya sebenarnya setuju bahwa pada akhirnya ini adalah arah yang benar untuk dituju, tetapi saya yakin ini akan menghentikan banyak tempat menuju .net core.

Sangat membutuhkan tanggapan dari tim .net tentang ini.

@davidfowl https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434594997

Yah, ini hanya memaksa perpustakaan Anda untuk dilapisi dengan lebih baik 😉

Bukankah argumen ini bekerja ke arah yang berlawanan?

Apa yang saya tidak mengerti adalah apa yang sebenarnya mencegah Anda dari arsitektur layering yang tepat dari ASP.NET Core?
Jadi, ya, beberapa fitur runtime tidak tersedia di .Net Framework, seperti Span<T> , tetapi itu tidak berarti fitur itu tidak tersedia sama sekali. Ini tersedia , hanya tidak berkinerja seperti pada inti .Net. Kita bisa mengatasinya.

Beberapa implementasi tingkat rendah dapat diimplementasikan dalam variasi untuk inti .net secara khusus dan untuk standar .net. Dan saya ragu ada banyak ruang untuk itu, karena API biasanya tersedia sebagai paket NuGet.
Banyak penulis perpustakaan mendukung implementasi yang berbeda untuk platform yang berbeda, inilah yang selalu terjadi.

Bisakah Anda menjelaskan apa sebenarnya yang mencegah Anda mendukung .Net Framework / .Net Standard. Beberapa contoh sederhana apa yang tidak dapat disarikan untuk memiliki implementasi khusus platform?

mencegah Anda mendukung .Net Framework / .Net Standard. Beberapa contoh sederhana apa yang tidak dapat disarikan untuk memiliki implementasi khusus platform?

Di luar kepalaku, item yang membutuhkan runtime atau perubahan kerangka kerja

• Petunjuk GC interior; jadi membuat Span aman dari ref hanya tanpa objek: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• Implementasi antarmuka default
• Item kerja khusus Threadpool
• Span overload pada tipe dasar: Stream, Sockets, TextReader / TextWriter, WebSockets
• IAsyncDisposable overload pada tipe dasar: Stream, Sockets, TextReader / TextWriter, WebSockets, dll.
• IAsyncEnumeratorkelebihan beban pada tipe dasar: Stream, Sockets, TextReader / TextWriter, WebSockets, dll.

Item bonus

• Intrinsik perangkat keras (x86, x64, ARM)
• Analisis melarikan diri (alokasi baru untuk ditumpuk)
• Versi runtime berdampingan
• Memperbaiki pengalihan binding dan pembuatan versi

Saya tidak mengerti mengapa kita tidak bisa hanya memiliki versi standar yang tidak lagi mendukung netframework. Sama seperti ponsel windows tidak memiliki dukungan standar bersih di luar 1.2. Mengapa kita tidak dapat memajukan standar dan mengizinkan implementasi seperti netcore, mono, xamarin, dll pada akhirnya cocok atau tidak sama sekali. Kemudian terserah pembuat perpustakaan untuk memutuskan versi standar bersih mana yang ingin mereka terapkan untuk memaksimalkan cakupan.

Perubahan ini membuatnya jadi xamarin dan mono tidak bisa lagi menggunakan aspnetcore. Itu membuatnya jadi pembuat perpustakaan dipaksa untuk menargetkan kedua netcore dan netstandard atau lebih buruk lagi namun meninggalkan standar bersih semuanya dan hanya menargetkan netcore.

Hal ini pada akhirnya akan menyebabkan matinya standar bersih.

mencegah Anda mendukung .Net Framework / .Net Standard. Beberapa contoh sederhana apa yang tidak dapat disarikan untuk memiliki implementasi khusus platform?

Di luar kepalaku, item yang membutuhkan runtime atau perubahan kerangka kerja

• Petunjuk GC interior; jadi membuat Span aman dari ref hanya tanpa objek: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• Implementasi antarmuka default
• Item kerja khusus Threadpool
• Span overload pada tipe dasar: Stream, Sockets, TextReader / TextWriter, WebSockets
• IAsyncDisposable overload pada tipe dasar: Stream, Sockets, TextReader / TextWriter, WebSockets, dll.
• IAsyncEnumerator kelebihan beban pada tipe dasar: Stream, Sockets, TextReader / TextWriter, WebSockets, dll.

Item bonus

• Intrinsik perangkat keras (x86, x64, ARM)
• Analisis melarikan diri (alokasi baru untuk ditumpuk)
• Versi runtime berdampingan
• Memperbaiki pengalihan binding dan pembuatan versi

Item dalam daftar pertama terdengar seperti hal-hal yang akan menjadi kandidat untuk perubahan standar bersih?

Kebanyakan dari mereka sepertinya tidak mungkin untuk dibawa ke runtime lain, tetapi tampaknya tidak ada yang mau rev ​​CLR untuk versi baru untuk membawa Implementasi Antarmuka Default ke .NET Framework.

Pada saat yang sama, Microsoft tampaknya tidak ingin mendorong ke depan dengan versi .NET Standard yang selamanya tidak kompatibel dengan .NET Framework. Jika tidak, ini tidak akan menjadi masalah - cukup dorong dengan netstandard30 atau netstandard40 dan jatuhkan dukungan Framework; dan memiliki target .NET Core salah satu standar yang lebih baru tersebut.

Saya merasa utas ini, dll., Adalah hasil dari Microsoft yang secara efektif mengecat diri mereka sendiri.

Pada saat yang sama, Microsoft tampaknya tidak ingin mendorong ke depan dengan versi .NET Standard yang selamanya tidak kompatibel dengan .NET Framework.

Ini tidak jujur; .NET Standard 2.1 sedang diselesaikan dan memiliki 3104 API baru di atas .NET Standard 2.0, termasuk kelebihan beban Span pada jenis kerangka dasar; yang mungkin membuatnya tidak kompatibel dengan .NETFramework.

.NET Standard masih bergerak maju.

Jika tidak, ini tidak akan menjadi masalah - cukup dorong ke depan dengan netstandard30 atau netstandard40 dan jatuhkan dukungan Framework; dan memiliki target .NET Core salah satu standar yang lebih baru tersebut.

Masalahnya adalah membuat setiap runtime, bukan hanya Framework yang tidak kompatibel dengan salah satu Standar yang lebih baru; dan kemudian tidak cocok dengan setiap Standar setelah itu. Apa yang masuk ke .NET Standard perlu disetujui oleh berbagai runtime sebagai hal yang dapat diimplementasikan.

Akankah berbagai GC Mono dan Unity segera mendukung petunjuk interior? Jika tidak menambahkannya ke .NET Standard akan memblokir mereka dari .NET Standard itu setiap .NET Standard masa depan sampai GC mereka diubah untuk menanganinya. Namun; lebih baik menambahkan API yang dapat mereka terapkan sekarang dan menyimpan aplikasi yang tidak dapat mereka gunakan untuk standar masa depan.

Apakah api yang ditambahkan ke Inti merupakan api yang tepat untuk diperbaiki secara permanen selamanya dan memaksa setiap runtime; yang ingin kompatibel dengan Standar berikutnya, untuk diterapkan?

Beberapa dari inti 2.1 apis berubah antara pratinjau 1 dan pratinjau 2 (karena umpan balik penggunaan); jadi sulit untuk mengetahui apis apa yang baru di Core X sampai dirilis pada titik mana set di batu. Lalu, manakah dari mereka yang merupakan set yang benar untuk ditambahkan ke Standar untuk semua runtime yang akan diterapkan (atau ditinggalkan).

Pendekatan .NET Standard masih lebih agresif daripada standar browser ketika 2 browser harus mengimplementasikan fitur sebelum standar diterima.

Akan lebih baik jika Standar .NET baru dapat dikirimkan pada waktu yang sama dengan .NET Core dan semua runtime dapat langsung menerapkannya dan ASP.NET Core kemudian dapat menggunakan semua API baru melalui .NET Standard; tapi meski bagus sebagai cita-cita, itu juga tidak praktis. Bahkan ada beberapa API yang disetujui yang belum diterapkan di .NET Core

Pertanyaan dasarnya adalah dapatkah ASP.NET Core menggunakan apis yang telah diminta olehnya dan dikirimkan dalam versi .NET Core yang disertakan dengannya (karena mereka dikirimkan secara bersamaan); atau dapatkah itu hanya menggunakan apis yang dikirimkan dalam versi .NET Core sebelumnya - yang karenanya berpeluang berada dalam versi .NET Standard untuk .NET Core itu? (Seperti yang terlihat seperti .NET Versi standar akan tertinggal dalam versi apis 1 di belakang .NET Core saat ini; menggunakan ukuran sampel 1)

Jika ASP.NET Core dapat menggunakan apis; kemudian apis mendapatkan pengujian penggunaan dan dievaluasi apakah apis itu bagus; jika tidak, maka apis yang lebih baik dapat diusulkan. Jika ASP.NET Core tidak dapat menggunakannya, maka apakah mereka apis yang baik masih cukup tidak diketahui ketika mereka menjadi kandidat .NET Standard.

tidak ada yang mau rev ​​CLR untuk versi baru untuk membawa Implementasi Antarmuka Default ke .NET Framework.

.NET Core dengan mendukung beban kerja .NETFramework tradisional (termasuk WinForms dan WPF) pada dasarnya adalah rev'ing dari CLR; tetapi dilakukan dengan cara yang lebih berkelanjutan, bukti masa depan?

Ini tidak jujur; .NET Standard 2.1 sedang diselesaikan dan memiliki 3104 API baru di atas .NET Standard 2.0, termasuk Span overload pada jenis kerangka dasar; yang mungkin membuatnya tidak kompatibel dengan .NETFramework.

Termasuk .NET Framework 4.8 dan .NET Framework 4.9?

Selalu ada kemungkinan bahwa pembaruan Kerangka di masa depan akan mendapatkan API baru ini. Saat ini tampaknya sudah ditetapkan bahwa .NET Framework tidak akan pernah mendapatkan DIM, oleh karena itu, antarmuka apa pun dengan metode DIM dapat _never_ di-porting ke .NET Framework.

.NET Core dengan mendukung beban kerja .NETFramework tradisional (termasuk WinForms dan WPF) pada dasarnya adalah rev'ing dari CLR; tetapi dilakukan dengan cara yang lebih berkelanjutan, bukti masa depan?

Dan tidak tahan mundur. Sebanyak Microsoft memamerkan hal-hal seperti Paint.Net yang berjalan di .NET Core, saya tidak dapat menjalankan proyek sisi server saya yang ada di .NET Core, dan begitu pula kebanyakan orang.

Akan lebih baik jika Standar .NET baru dapat dikirimkan pada waktu yang sama dengan .NET Core dan semua runtime dapat langsung menerapkannya dan ASP.NET Core kemudian dapat menggunakan semua API baru melalui .NET Standard; tapi meski bagus sebagai cita-cita, itu juga tidak praktis.

Ini mungkin juga tidak praktis, tetapi saya pikir orang-orang secara keseluruhan akan sedikit lebih bahagia jika ada dua versi ASP.NET Core:

• Versi terbaru yang bergerak cepat yang terkait dengan .NET _Core_ dan dapat menggunakan API baru apa pun yang diinginkan.
• Versi LTS yang bergerak lebih lambat yang terkait dengan .NET _Standard_ dan berjalan di lebih banyak tempat; yang akhirnya mengejar ketinggalan dengan build-edge lama tetapi selalu tertinggal.

Dengan mengaitkannya ke .NET Core Anda memaksakan pengorbanan yang tidak disukai semua orang. Saya mendapatkan alasan di balik pendekatan harus-bergerak-cepat, tetapi ada juga kekhawatiran yang sah untuk keseluruhan ekosistem .NET.

• Versi terbaru yang bergerak cepat yang terkait dengan .NET Core dan dapat menggunakan API baru apa pun yang diinginkannya.
• Versi LTS yang bergerak lebih lambat yang terkait dengan .NET Standard dan berjalan di lebih banyak tempat; yang akhirnya mengejar ketinggalan dengan build-edge lama tetapi selalu tertinggal.

Jadi jika ASP.NET Core 3.0 keluar sebagai .NET Core 3.0 saja; tetapi di kemudian hari ketika mereka adalah .NET Standard yang memiliki apis; paket untuk ASP.NET Core 3.x dirilis yang juga .NET Standard (bahkan jika ASP.NET Core telah pindah ke 4.0); apakah itu memenuhi kebutuhan Anda?

@ yaakov-h

Versi LTS yang bergerak lebih lambat yang terkait dengan .NET Standard dan berjalan di lebih banyak tempat; yang akhirnya mengejar ketinggalan dengan build-edge lama tetapi selalu tertinggal.

Apa artinya ini? Anda selalu dapat menggunakan ASP.NET Core 2.1 dengan dukungan tambahan yang disebutkan @DamianEdwards . Dugaan saya adalah meskipun dukungan itu 10 tahun, itu tidak akan memuaskan keluhan orang. Naluri memberi tahu saya bahwa selama ada fitur baru yang sedang dikembangkan, orang akan menginginkan akses ke fitur tersebut (bahkan yang saat ini sedang dalam perjalanan lambat), tetapi mungkin saya terlalu banyak membaca tanggapan ini ...

Anda selalu dapat menggunakan ASP.NET Core 2.1 dengan dukungan tambahan itu

Tolong jangan memisahkan komunitas !!
(berdasarkan voting) Apakah Anda mengharapkan 1/3 developer tetap menggunakan asp.net core 2.1? atau mengharapkan 2/3 developer yang membuat paket nuget yang harus mempertahankan 2 versi library mereka?

@benaams

Jadi jika ASP.NET Core 3.0 keluar sebagai .NET Core 3.0 saja; tetapi di kemudian hari ketika mereka adalah .NET Standard yang memiliki apis; paket untuk ASP.NET Core 3.x dirilis yang juga .NET Standard (bahkan jika ASP.NET Core telah pindah ke 4.0); apakah itu memenuhi kebutuhan Anda?

Tepat.

@tokopedia

Anda selalu dapat menggunakan ASP.NET Core 2.1 dengan dukungan tambahan yang disebutkan @DamianEdwards . Dugaan saya adalah meskipun dukungan itu 10 tahun, itu tidak akan memuaskan keluhan orang.

Sepertinya ada pesan yang bentrok di sini:

1. Tidak masalah untuk tetap menggunakan 2.1, versi LTS yang lebih lama
2. ASP.NET Core bergerak sangat cepat sehingga kami bahkan tidak bisa menunggu satu siklus rilis antara .NET Core dan berikutnya .NET Standard.

Saya pikir (2) menyebabkan banyak kebingungan dan ketakutan tertinggal.

@Johnny

(berdasarkan voting) Apakah Anda mengharapkan 1/3 developer tetap menggunakan asp.net core 2.1? atau mengharapkan 2/3 developer yang membuat paket nuget yang harus mempertahankan 2 versi library mereka?

Saya berharap penulis perpustakaan memutuskan apa versi minimum dari ASP.NET Core yang mereka dukung dan menargetkan itu. Itu yang sudah mereka lakukan hari ini. Beberapa pustaka mendukung ASP.NET Core 1.x dan 2.x beberapa hanya mendukung 2.x. Ini tidak berbeda.

@ yaakov-h

Saya tidak begitu mengerti apa pesan yang bertentangan itu. 2.1 saat ini adalah LTS dan berjalan di .NET Core dan .NET Framework dan didukung selama 3 tahun. Ini bukanlah pesan baru, ini adalah pesan yang sama yang kami terima sejak awal.

ASP.NET Core bergerak sangat cepat sehingga kami bahkan tidak bisa menunggu satu siklus rilis antara .NET Core dan berikutnya .NET Standard.

Itu spekulasi berdasarkan komentar yang dibuat di sini. Secara resmi, kami terikat dengan siklus pengiriman .NET Core dan kami menambahkan serta menggunakan API baru dengan setiap rilisnya. ASP.NET Core yang berjalan di .NET Framework tidak pernah dimaksudkan sebagai sesuatu yang permanen (bahkan disebut ASP.NET Core), itu selalu dimaksudkan sebagai batu loncatan. Kami hanya perlu menambahkan cukup banyak API inti kembali sehingga pelanggan dapat menulis aplikasi yang berfungsi penuh secara wajar.

Ada tanggapan tentang ini dari tim ms?

Sayangnya ini berarti bahwa siapa pun yang melakukan penerapan di lokasi masih, tidak dapat mendukung perangkat lunak mereka selama lebih dari 3 tahun. Misalnya, segera setelah Anda merilis aplikasi yang menargetkan .netcore 3.0, pelanggan Anda memiliki waktu 3 tahun dan kemudian dipaksa untuk meningkatkan. Beberapa industri yang akan baik-baik saja, beberapa lainnya pasti tidak.

Itulah masalah terbesar dengan ini, dan membuat .net core benar-benar non-go untuk banyak orang, saya bayangkan. Saya sebenarnya setuju bahwa pada akhirnya ini adalah arah yang benar untuk dituju, tetapi saya yakin ini akan menghentikan banyak tempat menuju .net core.

Sangat membutuhkan tanggapan dari tim .net tentang ini.

Sayangnya ini berarti bahwa siapa pun yang melakukan penerapan di lokasi masih, tidak dapat mendukung perangkat lunak mereka selama lebih dari 3 tahun

itu hanya omong kosong, Anda sebenarnya hanya dapat melakukan peningkatan. satu-satunya waktu di mana ia tidak berfungsi adalah di dalam lingkungan tertanam, tetapi perangkat lunak tertanam memiliki lebih banyak masalah daripada jendela dukungan 3 tahun.

@schmitch Saya tidak yakin apa yang Anda maksud? Jelas Anda hanya dapat memutakhirkan, tetapi untuk beberapa industri, peningkatan ke versi baru perangkat lunak menjadi proyek besar yang dapat memakan waktu bertahun-tahun, tergantung pada siklus rilis dan seberapa progresif secara teknis (atau tidak) industri tersebut.

@tokopedia

Dugaan saya adalah meskipun dukungan itu 10 tahun, itu tidak akan memuaskan keluhan orang.

Tidak yakin bagaimana Anda mengharapkan orang untuk mengambilnya, semua orang efek keputusan ini dihadapkan dengan platform tempat mereka dijual tidak hanya tidak memiliki masa depan, tetapi investasi mereka yang ada yang dibangun di atas model pemrograman terbaru terus berjalan platform yang tidak didukung (yang pada pengumuman ini) dalam waktu kurang dari 3 tahun. Orang lain yang berpikir tentang migrasi bertahap yang hati-hati ke .NET Core melalui migrasi ke .NET Framework terlebih dahulu sekarang dihadapkan pada risiko bahwa tidak akan ada kemungkinan untuk mundur - itu dijalankan pada runtime atau bust .NET Core baru.

Platform pengembang seharusnya tidak menjadi tujuan itu sendiri, karena ada nilai yang secara eksponensial lebih besar yang dibuat di platform, kemudian nilai platform itu sendiri. Gerakan membutakan seperti ini membuatnya tampak bahwa efisiensi maksimum sumber daya untuk meningkatkan kecepatan platform lebih penting daripada investasi ekosistem yang sedang dibuat di atasnya. Tinta pada bit .NET Core 2.1 bahkan belum kering tetapi sistem yang ada (di FX) sudah diperlakukan sebagai kewajiban (dengan maksud memberikan dukungan minimal) alih-alih aset dan nilai yang mereka tambahkan ke ekosistem.

Seperti yang telah disebutkan, sistem perusahaan dapat bergerak dengan sangat cepat, seringkali secara bersamaan menyeimbangkan tim pengembang yang memberikan peningkatan berkelanjutan yang perlu digunakan oleh sejumlah karyawan dan pelanggan untuk mendapatkan ROI yang konstan dari mereka. Banyak migrasi perlu terjadi "dalam penerbangan" dengan perencanaan yang cermat dan pengujian yang ketat yang dapat memakan waktu bertahun-tahun - waktu yang mereka lebih suka gunakan untuk menciptakan nilai kemudian berebut untuk keluar dari platform yang memiliki dukungan yang ditarik dari bawah mereka. Sistem brownfield yang besar bukanlah komoditas seperti iPhone yang dapat dengan mudah dibuang dan ditingkatkan dengan mulus setiap beberapa tahun, sistem yang lebih tua dan lebih lama sedang dalam pengembangan, semakin banyak nilai yang diinvestasikan di dalamnya dan semakin sulit untuk bermigrasi darinya, yang menjadi sangat penting. sulit untuk diserap mengingat tidak ada nilai yang tercipta dalam migrasi, hal itu membutuhkan sumber daya, menyerap biaya peluang, meningkatkan risiko, dan yang terbaik yang dapat mereka harapkan adalah migrasi tanpa cela dengan sistem yang ada berjalan persis sama seperti sebelumnya.

Apa pun tanggal kedaluwarsa yang diterapkan pada dukungan FX, akan ada sistem yang ada yang berjalan melewatinya yang mengalami hambatan atau tidak dapat dimigrasi darinya. Lalu apa yang menjadi pedomannya?

ASP.NET Core 2.1 sudah dikembangkan, upaya untuk menjalankan ASP.NET Core di FX / .NET Core adalah sunk cost yang sudah diinvestasikan. Jadi keputusan harus dibingkai sebagai masalah sumber daya MS untuk mempertahankan platform yang sudah dikembangkan (setelah LTS) vs jumlah kumulatif biaya, niat buruk dan inersia yang dihasilkan karena meninggalkan platform populer.

Saya tidak yakin saya mengerti apa yang diminta saat itu. Siklus hidup LTS tidak berubah sejak versi 2.1. Jika Anda menulis aplikasi pada versi LTS apakah .NET Core atau .NET Framework, itu akan menjadi 3 tahun sampai Anda "tidak didukung". Saya tidak begitu mengerti bagaimana permadani ditarik dari bawah Anda dalam hal penyangga, itu tidak berubah. Anda perlu meningkatkan untuk mendapatkan pembaruan platform apa pun.

Sekarang saya memahami bahwa 2.1 menjadi versi LTS terakhir yang didukung pada .NET Framework berarti tidak ada tempat untuk meningkatkan, tetapi di situlah dukungan LTS yang diperluas masuk. Jika aplikasi tidak pernah dapat pindah ke .NET Core bahkan setelah 6 tahun ini karena API adalah hilang, harap ajukan masalah agar kami memahami celahnya.

Saya tidak yakin saya mengerti apa yang diminta saat itu.

Utas ini meminta berbagai tingkat komitmen dari MS mulai dari: terus mengembangkannya bersama-sama dengan .NET Core, mengembangkannya dengan "kereta lambat", tidak meninggalkan ASP.NET Core 2.1 dan mempertahankan tingkat dukungan yang sama seperti WebForms, perluas LTS . Preferensi saya adalah tidak meninggalkannya sebagai opsi hosting untuk ASP.NET Core (edit: obv apa pun di atas yang akan lebih disukai) yang tidak akan menahan .NET Core hanya v3 + sambil menyediakan banyak utilitas untuk .NET yang ada Investasi FX.

Sekarang saya mengerti bahwa 2.1 sebagai versi LTS terakhir yang didukung pada .NET Framework berarti tidak ada tempat untuk meningkatkan

Yang berarti itu menjadi platform yang tidak didukung, siapa pun di dalamnya harus memperlakukannya seperti lava dan berebut untuk turun sebelum mencapai ujung EOL yang tidak didukung.

• Siapa pun yang berpikir untuk menggunakannya sebagai platform pementasan untuk pindah ke .NET Core telah menjadi pilihan yang kurang layak karena mereka menghadapi risiko terdampar di platform yang tidak didukung jika migrasi memakan waktu lebih lama dari yang diharapkan atau mereka menemui hambatan jika ada ketergantungan yang mereka andalkan tidak dapat berjalan di .NET Core.
• Siapa pun yang dipaksa untuk menggunakan server .NET Framework infrastruktur terkelola perusahaan mereka yang ada tidak dapat berpartisipasi dalam menggunakan model dan ekosistem dev yang baru dan harus melihat pengetahuan / keterampilan ASP.NET klasik mereka menjadi kurang berharga setiap hari.
• Tim tidak dapat memigrasi sistem yang diperlukan .NET Framework mereka yang ada dan akan memerlukan pengalihan konteks ke proyek ASP.NET Core baru di .NET Core.
• Tidak ada organisasi yang ingin dipaksa melakukan migrasi yang tidak direncanakan karena panduan yang mereka andalkan untuk mendasarkan keputusan anggaran, perencanaan, dan investasi mereka telah berubah.

Sekali lagi bukan masalah untuk proyek greenfield, untuk orang yang dapat atau berencana untuk bermigrasi ke .NET Core tetap atau untuk siapa pun yang tidak harus mempertahankan sistem lama, tetapi itu berdampak pada ekosistem .NET FX yang ada dan ASP.NET Core menjadi lebih miskin karena tidak dapat lagi mempertimbangkan untuk menggunakan opsi hosting populer di .NET FX.

Di dunia yang sempurna setiap orang akan menggunakan .NET Core tetapi ada sejumlah besar investasi di .NET FX yang sedang didevaluasi dengan keputusan ini.

Jika aplikasi tidak pernah bisa pindah ke .NET Core bahkan setelah 6 tahun ini karena API tidak ada,

Ada banyak orang yang tidak dapat atau tidak ingin pindah ke .NET Core, mereka ingin berbagi tingkat dukungan yang sama seperti ASP.NET klasik (yang disarankan oleh pesan saat ini tanpa batas).

API yang hilang bukan satu-satunya alasan yang mencegah migrasi, misalnya mereka dapat mengandalkan ketergantungan di mana tim pengembang membuatnya tidak ada lagi, ini adalah komponen penting yang tidak dapat diubah, tidak dapat difaktor ulang dengan aman (mis. tidak ada tes), itu dibagikan dengan sistem lain .NET FX-only, itu dikelola oleh departemen lain yang tidak memiliki anggaran, kapasitas untuk mengubahnya atau karena faktor eksternal seperti infrastruktur yang dikelola perusahaan mereka hanya mendukung berjalan di server .NET Framework.

Terima kasih telah membunuh .NET Standard dengan keputusan semacam ini.

Sejauh ini kami telah mengabaikan .NET Core karena ada banyak Assemblies pihak ketiga yang belum menargetkan Core.

Banyak vendor yang bersedia mendukung Core, melakukannya dengan setengah hati, misalnya ODP.NET yang Dikelola tanpa API asli yang hanya tersedia di .NET Framework.

Kemudian Anda datang dengan keputusan seperti ini.

Tidak, kami tidak akan mengadopsi .NET Core lebih cepat hanya karena terlalu merepotkan Microsoft untuk mendukung .NET Framework dan tidak dapat memenuhi Standar .NET yang Anda dorong untuk memulai.

@davidfowl Saya dapat memberi Anda 2 contoh tentang apa yang membuatnya sulit untuk bermigrasi ke .NET Core - WCF (banyak aplikasi perusahaan yang ada menggunakannya, saya yakin orang lain telah mengangkat masalah itu), dan kurangnya pustaka Adomd di .NET Core / NET Standar (itu untuk berkomunikasi dengan SSAS, juga digunakan di aplikasi perusahaan, yang dilacak di SQL https://feedback.azure.com/forums/908035-sql-server/suggestions/35508349-adomd-core). Beberapa (bentuk win) lainnya harus diperbaiki dengan paket kompatibilitas .net core 3 (yay!) - kita harus menunggu dan melihat cara kerjanya.

@tokopedia

Utas ini meminta berbagai tingkat komitmen dari MS mulai dari: terus mengembangkannya bersama-sama dengan .NET Core, mengembangkannya dengan "kereta lambat", tidak meninggalkan ASP.NET Core 2.1 dan mempertahankan tingkat dukungan yang sama seperti WebForms, perluas LTS . Preferensi saya adalah tidak meninggalkannya sebagai opsi hosting untuk ASP.NET Core yang tidak akan menahan .NET Core hanya v3 + sambil menyediakan banyak utilitas untuk investasi .NET FX yang ada.

Saat ini kami sedang menjajaki untuk memperluas dukungan LTS tetapi kami tidak mempertimbangkan dukungan kelas satu .NETFramework untuk ASP.NET Core selamanya (yang Anda minta). Versi ASP.NET Core yang Anda cari dengan tingkat dukungan yang sama dengan WebForms hanya akan mendapatkan perbaikan keamanan dan perbaikan keandalan. Saya dapat menjamin Anda bahwa ketika fitur muncul di versi ASP.NET Core yang lebih baru, tingkat kepuasan mereka yang menggunakan ASP.NET Core 2.1 akan turun (setidaknya, itulah yang dikatakan firasat saya) karena perubahan itu masih akan keluar dari mencapai.

API yang hilang bukan satu-satunya alasan yang mencegah migrasi, misalnya mereka dapat mengandalkan ketergantungan di mana tim pengembang membuatnya tidak ada lagi, ini adalah komponen penting yang tidak dapat diubah, tidak dapat difaktor ulang dengan aman (mis. tidak ada tes), itu dibagikan dengan sistem lain .NET FX-only, itu dikelola oleh departemen lain yang tidak memiliki anggaran, kapasitas untuk mengubahnya atau karena faktor eksternal seperti infrastruktur yang dikelola perusahaan mereka hanya mendukung berjalan di server .NET Framework.

Ini sangat umum (bahkan dalam Microsoft) dan itulah mengapa kami menambahkan kemampuan itu untuk mereferensikan .NET Framework dll di .NET Core 2.0 karena ternyata sebagian besar rakitan kompatibel bahkan jika tidak dikompilasi untuk .NET Core. Sekarang ada beberapa hal yang tidak akan pernah berfungsi (seperti AppDomains ...) tetapi saya berharap saat kita menambahkan lebih banyak permukaan API, kumpulan pustaka yang tidak hanya berfungsi akan menyusut ke angka yang tidak signifikan.

@pjmlp

Saya tidak melihat bagaimana ini membunuh .NET Standard. .NET Standard jauh lebih besar dari ASP.NET Core. Ini tentang membuat pustaka bersama yang dapat digunakan kembali (seperti Microsoft.Extensions *) yang bekerja pada platform .NET pendukung apa pun.

Sejauh ini kami telah mengabaikan .NET Core karena ada banyak Assemblies pihak ketiga yang belum menargetkan Core.

Yang mana Apakah dukungan untuk mereka yang sedang dalam perjalanan atau akankah rakitan tersebut tidak pernah mendukung .NET Core?

Banyak vendor yang bersedia mendukung Core, melakukannya dengan setengah hati, misalnya ODP.NET yang Dikelola tanpa API asli yang hanya tersedia di .NET Framework.

Saya setuju dengan ini dan telah melihat banyak versi pustaka yang lumpuh di .NET Core (bahkan dengan beberapa pustaka yang dikirimkan Microsoft) tetapi saya akan mengatakan bahwa pasang surut menyalakannya. Beberapa alasan untuk itu adalah karena kumpulan API awal yang hilang yang ada di .NET Core 1.0. Dengan 2.0 dan 2.1, kami telah melihat sekumpulan besar port library dengan lebih mudah ke inti / standar tanpa banyak kehilangan fungsionalitas.

@voltcode Terima kasih atas umpan balik konkret! Kami berharap beberapa jenis masalah kompatibilitas ini hilang atau minimal selama rentang waktu yang kami dukung proyek .NET Core hari ini (3 tahun atau lebih).

@tokopedia

....

Sejauh ini kami telah mengabaikan .NET Core karena ada banyak Assemblies pihak ketiga yang belum menargetkan Core.

Yang mana Apakah dukungan untuk mereka yang sedang dalam perjalanan atau akankah rakitan tersebut tidak pernah mendukung .NET Core?

Dalam kasus kami, ODP.NET adalah yang paling jelas, karena Oracle tidak memindahkan 100% fitur driver ke Core.

Banyak vendor yang bersedia mendukung Core, melakukannya dengan setengah hati, misalnya ODP.NET yang Dikelola tanpa API asli yang hanya tersedia di .NET Framework.

Saya setuju dengan ini dan telah melihat banyak versi pustaka yang lumpuh di .NET Core (bahkan dengan beberapa pustaka yang dikirimkan Microsoft) tetapi saya akan mengatakan bahwa pasang surut menyalakannya. Beberapa alasan untuk itu adalah karena kumpulan API awal yang hilang yang ada di .NET Core 1.0. Dengan 2.0 dan 2.1, kami telah melihat sekumpulan besar port library dengan lebih mudah ke inti / standar tanpa banyak kehilangan fungsionalitas.

Itu bukan berapa banyak pelanggan kami yang melihatnya.

Hanya agar Anda dapat merasakan bagaimana keputusan semacam ini memengaruhi masa depan .NET, pada proyek baru-baru ini pelanggan membayar upaya pengembangan untuk memindahkan aplikasi dari .NET Framework ke Java untuk penyebaran UNIX, karena dia tidak bersedia melakukannya bertaruh pada .NET Core dan implementasi ODP.NET yang lumpuh, sedangkan driver JDBC menawarkan paritas fitur 1: 1 dengan driver .NET Framework ODP.NET.

Orang lain mungkin memilih tumpukan alternatif lain juga.

Ada banyak sekali dependensi yang tidak akan dan tidak dapat di-porting di aplikasi perusahaan rata-rata Anda.

Masalah ini muncul di bagian atas HN. Kalian (@MSFT) mungkin ingin memeriksanya juga. Hanya 1 jam dan sudah 50+ komentar.

@tokopedia

Saya tidak melihat bagaimana ini membunuh .NET Standard. .NET Standard jauh lebih besar dari ASP.NET Core. Ini tentang membuat pustaka bersama yang dapat digunakan kembali (seperti Microsoft.Extensions *) yang bekerja pada platform .NET pendukung apa pun.

Saya tidak mengerti apa itu ASP.NET Core jika bukan perpustakaan bersama yang dapat digunakan kembali? Jika tren perpustakaan menjadi modern dan cepat adalah dengan menjatuhkan dukungan .NET Standard maka itu adalah pesan yang rumit. Haruskah Newtonsoft.Json beralih ke .NET Core 3 saja, jika dapat berjalan jauh lebih cepat? Haruskah Autofac?

Saya mengerti alasan di balik ini, tetapi saya tidak yakin argumen dan evaluasi telah banyak berubah sejak terakhir kali ini muncul! Saya kira kita akan menunggu dan melihat ...

Saya akan membuang kasus penggunaan saya di luar sana dan memberikan beberapa perspektif tentang bagaimana hal-hal yang terlihat di toko kami saat ini yang berkaitan dengan ini:

AspNetCore sangat luar biasa untuk tumpukan kami dalam hal hosting mandiri (http.sys) API web dan konten web statis di berbagai layanan. Kami berasal dari Nancy yang solid, tetapi juga memiliki banyak kekurangan dari sudut pandang kami sehingga kami beralih ke AspNetCore sekitar setahun yang lalu. Hari ini, kami menjalankan semua basis kode kami di 2.x. Dalam banyak kasus, kami akan baik-baik saja pindah ke target .NET Core murni. Namun, ada juga banyak layanan yang kami bangun untuk memanfaatkan AspNetCore yang juga mengandalkan hal-hal seperti System.DirectoryServices dan System.Drawing . Dari perspektif layanan ini, kami akan mengubah teknologi hosting web sebelum kami pindah dari .Net Framework. Sayangnya, karena kerumitan dalam mengelola 2 teknologi hosting web yang berbeda secara bersamaan dan ukuran tim kami, kami kemungkinan besar juga akan menyerang AspNetCore dari layanan kami yang lain secara bersamaan untuk mendukung sesuatu yang lebih kompatibel di kedua target.

Singkatnya - Keputusan ini akan memaksa kami sepenuhnya keluar dari AspNetCore di beberapa titik di masa depan (kemungkinan ketika LTS berakhir untuk 2.x), untuk apa yang saya tidak tahu sekarang. Jika memang benar, kami kemungkinan akan menulis solusi internal kami sendiri untuk menggantikan AspNetCore, karena kasus penggunaan kami terkait # aktual fitur AspNetCore yang digunakan cukup sempit (yang dikatakan, fitur yang kami _do_ sediakan nilai tambah yang sangat besar bagi kami hari ini).

Orang lain mungkin memilih tumpukan alternatif lain juga.

Itu adil, tetapi tumpukan alternatif memiliki kebijakan dukungan yang sama. Java telah pindah ke model LTS serupa (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

Ada banyak sekali dependensi yang tidak akan dan tidak dapat di-porting di aplikasi perusahaan rata-rata Anda.

@bencyoung

Ini kerangka kerja, bukan perpustakaan. Itu terdiri dari satu set perpustakaan yang sangat besar yang dikirimkan bersama.

Saya tidak mengerti apa itu ASP.NET Core jika bukan perpustakaan bersama yang dapat digunakan kembali? Jika tren perpustakaan menjadi modern dan cepat adalah dengan menjatuhkan dukungan .NET Standard maka itu adalah pesan yang rumit. Haruskah Newtonsoft.Json beralih ke .NET Core 3 saja, jika dapat berjalan jauh lebih cepat? Haruskah Autofac?

Saya tidak melihat betapa rumitnya. Saya 97% yakin perpustakaan tersebut tidak akan menghapus kerangka kerja karena pelanggan mereka akan mengeluh. Bilahnya sangat tinggi untuk menghapus kerangka kerja dan itu alasan yang sama kami mempertahankan Microsoft.Extensions. * Di .NET Standard 2.0. Saya setuju akan kabur jika kita memindahkan semuanya ke sana tapi bukan itu yang terjadi di sini.

Di satu sisi, ini hanya memformalkan apa yang sebenarnya sudah ada di .NET Core. Kami mengirimkan ASP.NET Core dengan .NET Core. Di .NET Core ASP.NET Core adalah kerangka kerja bersama, bukan hanya sekumpulan paket. Paket-paket tersebut tidak pernah dikirimkan secara terpisah dari keseluruhan produk sehingga manfaat mereferensikan paket individu ini kecil (daftar paket juga kecil).

@rachmawati_rachman

Namun, ada juga banyak layanan yang kami bangun untuk memanfaatkan AspNetCore yang juga mengandalkan hal-hal seperti System.DirectoryServices dan System.Drawing

Yang ada di paket kompak windows di .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack.

Singkatnya - Keputusan ini akan memaksa kami sepenuhnya keluar dari AspNetCore di beberapa titik di masa depan (kemungkinan ketika LTS berakhir untuk 2.x), untuk apa yang saya tidak tahu sekarang. Jika itu yang terjadi, kami kemungkinan akan menulis solusi internal kami sendiri untuk menggantikan AspNetCore, karena kasus penggunaan kami dalam hal # aktual fitur AspNetCore yang digunakan cukup sempit (yang dikatakan, fitur yang kami manfaatkan menyediakan nilai tambah yang sangat besar bagi kami hari ini).

Akankah itu juga menjadi masalah jika dukungan diperpanjang?

Selain itu, sekarang kita harus memangkas semua teknologi yang tidak didukung lainnya (AppDomains, Remoting, dll.) Terlebih dahulu, alih-alih dapat melakukan pekerjaan itu secara paralel atau pada tahap selanjutnya.

Mengapa Anda tidak dapat bermigrasi ke 2.1 dulu?

Alasan terbesar saya ragu adalah bahwa batas dukungan 3 tahun berarti Anda tidak dapat mempertahankannya. Ini adalah batu loncatan migrasi jangka pendek, bukan titik di mana Anda dapat memiliki platform jangka panjang yang stabil. Yang berarti Anda harus menanggung semua kesulitan migrasi maju sekaligus karena Anda tidak bisa mengambil risiko setengah jalan, menjeda migrasi untuk membangun sejumlah fitur baru yang berprioritas tinggi dan kemudian mencoba menyelesaikan migrasi hanya untuk menemukan hard block dan harus mem-backport semua fitur baru Anda ke basis kode lama.

Alasan terbesar saya ragu adalah bahwa batas dukungan 3 tahun berarti Anda tidak dapat mempertahankannya.

Tentu, itulah mengapa kami menawarkan dukungan tambahan seperti yang disebutkan @DamianEdwards .

Hanya untuk menunjukkan seberapa besar konsekuensi yang ditimbulkan oleh keputusan ini - bagaimana dengan Blazor? Akankah itu berhenti didasarkan pada, standar bersih? Haruskah kita mengharapkan itu juga? Blazor diiklankan sebagai hal besar berikutnya. Apa lagi dari github.com/aspnet yang saat ini bergantung pada netstandard, akan membuangnya dan pindah ke inti bersih pada rilis besar berikutnya? Apa rencana untuk hal lain, di MSFT control tetapi di luar repo aspnet yang akan berbagi nasib aspnetcore?

@tokopedia

Orang lain mungkin memilih tumpukan alternatif lain juga.

Itu adil, tetapi tumpukan alternatif memiliki kebijakan dukungan yang sama. Java telah pindah ke model LTS serupa (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

Detail kecil yang Anda abaikan adalah bahwa Java, dan tumpukan lainnya, masih kompatibel di seluruh versi tidak seperti .NET Framework dan .NET Core tanpa memerlukan Standar yang hanya diterapkan sebagian di seluruh implementasi runtime.

Untuk apa nilainya, saat ini saya sedang mengerjakan penerapan aplikasi inti ASP.Net pertama perusahaan saya. Kami memiliki investasi yang sangat besar dalam .NET Framework, jadi menggunakan ASP.Net Core pada .NET Framework sebagai lawan .NET Core adalah pendekatan yang jelas.

Sekarang saya bertanya-tanya apakah saya akan membuat kami menghadapi banyak rasa sakit nanti.

Ada banyak masalah yang saling terkait di sini. Anda mengatakan bahwa inti ASP.Net tidak pernah dimaksudkan untuk hanya berjalan di .NET Framework. Pesan Microsoft tentang ASP.Net Core di masa lalu gagal membuatnya sangat jelas.

Demikian pula, banyak Pengembang .NET terbiasa dengan gagasan bahwa .NETFramework adalah implementasi utama, dan umumnya yang lain adalah subset, kecuali tentu saja untuk API khusus lingkungan. Ini telah berubah dengan .NET Core, tetapi banyak orang pada umumnya mendapat kesan bahwa .NET Framework "penuh" pada akhirnya akan mendukung semua yang hampir dilakukan .NET Core (kecuali untuk perkakas, dan kompatibilitas lintas platform, jelas), tetapi hanya pada skala waktu yang lebih lambat, menunggu kekusutan diselesaikan sebelum memasukkannya.

Baru-baru ini ada banyak saran bahwa beberapa fitur yang sangat penting mungkin tidak akan pernah masuk ke .NET Framework. (Misalnya, bahwa risiko kompatibilitas Spanjenis yang dianggap terlalu parah untuk diterapkan di .NET Framework 4.8 menyarankan mereka mungkin tidak pernah diterapkan, karena mengapa risiko tersebut menjadi lebih rendah di 4.9 ?. Kekhawatiran serupa tampaknya mengelilingi Metode Antarmuka Default.) Itu adalah perubahan paradigma utama yang tidak akan disukai oleh banyak pengembang!

Pesan di utas ini menunjukkan bahwa Microsoft mulai mempertimbangkan .NET Framework sebagai fitur warisan, sesuatu yang akan semakin sedikit mendapat perhatian pengembangan dari waktu ke waktu, hingga itu benar-benar hanya mendapat perbaikan keamanan.

Microsoft secara historis sangat buruk dalam menjelaskan tentang apa yang mereka kembangkan secara aktif, apa yang sebagian besar hanya mereka pertahankan dengan hanya fitur-fitur baru yang sporadis, dan apa yang mereka rencanakan untuk hanya benar-benar memberikan perbaikan keamanan dan stabilitas. Kedengarannya banyak bagi saya seperti .NET Framework tidak hanya berada di kategori kedua itu sekarang, tetapi sangat dekat dengan kategori ketiga.

Itu sangat mengganggu. .NET Core memiliki beberapa masalah yang membuatnya kurang optimal untuk beberapa aplikasi perusahaan. Tentu menggunakannya pada aplikasi yang memiliki pengembangan berkelanjutan yang berkelanjutan mungkin baik-baik saja. Namun, sebagai contoh, sebagian besar perusahaan juga memiliki beberapa aplikasi yang dapat diterapkan, dan hanya disentuh sekali dalam beberapa tahun. Itu bekerja buruk dengan .NET Core. Di sini perusahaan harus berjuang dengan siklus dukungan singkat untuk sebagian besar rilis. Dan di Windows tidak ada mekanisme yang saat ini ada untuk secara otomatis menginstal rilis patch baru untuk mendapatkan pembaruan keamanan, dll.

Jadi perusahaan yang memulai proyek baru dibiarkan bertanya-tanya apa yang harus dilakukan. .NET Framework yang lebih ramah perusahaan menunjukkan tanda-tanda yang cukup jelas menjadi usang, dan dengan demikian sesuatu yang lebih baik dihindari untuk pengembangan baru. Di sisi lain .NET Core ada tetapi secara substansial kurang ramah perusahaan.

Jadi ini pada dasarnya menjadi kata-kata kasar, tapi saya harap ini lebih menggambarkan kekhawatiran yang dimiliki banyak pengembang.

@tokopedia

Namun, ada juga banyak layanan yang kami bangun untuk memanfaatkan AspNetCore yang juga mengandalkan hal-hal seperti System.DirectoryServices dan System.Drawing

Yang ada di paket kompak windows di .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack.

Saya tidak menyadari bahwa paket kompatibilitas mendukung kasus penggunaan ini. Idealnya, kami ingin memajukan semuanya ke .NET Core, dan ini tampaknya merupakan jawaban yang sangat bagus (yang mungkin telah kami abaikan pada awalnya). Kami tidak berencana untuk memindahkan hosting layanan kami ke Linux / OSX, jadi bagian-bagian ini cocok untuk kami.

Akankah itu juga menjadi masalah jika dukungan diperpanjang?

Dalam hal dukungan - saya merasa LTS 2.x hingga 2021 masuk akal, mengingat semua kendala lain yang terkait dengan sesuatu yang menjangkau sejauh ini.

Berdasarkan apa yang saya pahami sekarang, kami mungkin akan merasa nyaman memutakhirkan ke AspNetCore 3.x setelah kami memiliki kesempatan untuk meninjau dan mengonversi proyek .NET Framework ke proyek .NET Core (dengan penggunaan paket kompatibilitas sesuai kebutuhan).

Terima kasih atas tindak lanjutnya.

Saya menulis di .NET (kebanyakan C #) selama 15 tahun dalam proyek tekanan tinggi. Saya menyia-nyiakan waktu bertahun-tahun dan uang pelanggan membuang-buang waktu menggunakan kerangka kerja yang direkayasa secara berlebihan. Saya menyukai konsep .NET Core. Bagi saya itu adalah kecepatan menulis proyek NodeJS tetapi dalam ekosistem .NET yang menakjubkan (termasuk semua lemaknya). Sayangnya itu gagal memenuhi janji itu, masih (bahkan dengan pengumuman baru ini) terlalu rumit untuk digunakan secara berdarah. Selama 3 tahun terakhir saya telah membangun di NodeJS, maaf kawan, itu tidak bisa dibandingkan. Buat lebih sederhana dan mudah digunakan dan Anda akan menarik komunitas pengembang yang luas lagi.

Untuk proyek dengan dependensi .NET Framework biner terkompilasi yang keras (barang vendor tanpa kode sumber) yang dapat berjalan di aplikasi ASP.NET Core 2.1 yang menargetkan .NET Framework yang diterapkan di Windows, akan menambahkan Paket Kompatibilitas Windows ke proyek membuat mereka tetap bekerja Core 3.0 jika jenis referensi ketergantungan keras disediakan oleh paket?

Ada ekosistem besar pustaka komersial yang sangat matang yang sayangnya memiliki ketergantungan pada System.Drawing, GDI, dan terkadang Registry (!). Jika sekarang ini hanya akan bekerja dengan 2.1 dan hanya didukung selama tiga tahun, ini adalah masalah yang dapat menghentikan adopsi Core di beberapa perusahaan.

.NET Core membuat lingkaran penuh untuk mencapai titik awal.

Saya akan menyarankan pendekatan lain: biarkan .NET Framework menggabungkan fitur-fitur yang berguna dari .NET Core, dan kemudian hilangkan .NET Core sekaligus sebagai cabang percobaan buntu. Sehingga menghentikan segmentasi dan menyimpan teknologi untuk kepentingan pelanggan yang lebih besar. Agak kontroversial, tetapi pendekatan yang lebih waras dari segi produk.

@tokopedia

ASP.NET Core yang berjalan di .NET Framework tidak pernah dimaksudkan sebagai sesuatu yang permanen, itu selalu dimaksudkan sebagai batu loncatan

Itu tidak benar sama sekali. Pesan di ASP.NET Core selalu didukung di .NET Core dan .NET Framework. Bahkan pengumuman paling awal dari .NET Core menyebutkan kedua platform untuk ASP.NET Core (saat itu ASP.NET 5).

Gambar yang sangat terkenal yang memamerkan .NET Standard juga memiliki ASP.NET Core yang mencakup Core dan kerangka kerja penuh. Dan dokumentasi resmi bahkan mengatakan: "Tidak ada rencana untuk menghapus dukungan untuk penargetan .NET Framework di ASP.NET Core".

Jadi ya, sudah jelas bahwa keputusan ini telah berubah sekarang , tetapi mengatakan bahwa selalu seperti itu hanyalah kebohongan, atau komunikasi yang sangat buruk yang dilakukan oleh Microsoft selama bertahun-tahun .

itu bahkan disebut ASP.NET Core

Oh ayolah. Bagaimanapun juga orang-orang seperti saya harus melawan orang-orang untuk memisahkan .NET Core dan ASP.NET Core karena mereka bukan hal yang sama, jangan hanya menggunakan nama yang mirip untuk keuntungan Anda di sini. Itu tidak adil. Perubahan nama menjadi "Core" tentu saja bukan untuk menghubungkannya secara eksplisit ke .NET Core. Selain itu, EF Core juga memiliki "Core" tetapi akan terus berjalan dengan standar bersih sehingga argumen itu tidak berfungsi.

di situlah dukungan LTS yang diperpanjang berperan. Jika aplikasi tidak pernah dapat dipindahkan ke .NET Core bahkan setelah 6 tahun ini […]

Dari mana datangnya ini sekarang? Terakhir kali, pesannya masih "kami sedang menyelidiki penawaran LTS 'dukungan diperpanjang'" . Apakah ini hal yang nyata sekarang dan kita mendapatkan 6 tahun?

@pjmlp

Detail kecil yang Anda abaikan adalah bahwa Java, dan tumpukan lainnya, masih kompatibel di seluruh versi tidak seperti .NET Framework dan .NET Core tanpa memerlukan Standar yang hanya diterapkan sebagian di seluruh implementasi runtime.

Poin yang adil, tapi saya tidak mengerti apa hubungannya dengan dukungan yang lebih baik. Klaim dibuat bahwa beralih ke Java akan lebih baik karena perpustakaan yang tidak terlalu cacat (yang merupakan masalah titik waktu) dan dukungan perusahaan (siklus dukungan yang lebih lama).

@Kevin_depok

Pesan di utas ini menunjukkan bahwa Microsoft mulai mempertimbangkan .NET Framework sebagai fitur warisan, sesuatu yang akan semakin sedikit mendapat perhatian pengembangan dari waktu ke waktu, hingga itu benar-benar hanya mendapat perbaikan keamanan.

Microsoft secara historis sangat buruk dalam menjelaskan tentang apa yang mereka kembangkan secara aktif, apa yang sebagian besar hanya mereka pertahankan dengan hanya fitur-fitur baru yang sporadis, dan apa yang mereka rencanakan untuk hanya benar-benar memberikan perbaikan keamanan dan stabilitas. Kedengarannya banyak bagi saya seperti .NET Framework tidak hanya berada di kategori kedua itu sekarang, tetapi sangat dekat dengan kategori ketiga.

Lihat https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/

Untuk proyek dengan dependensi .NET Framework biner terkompilasi yang keras (barang vendor tanpa kode sumber) yang dapat berjalan di aplikasi ASP.NET Core 2.1 yang menargetkan .NET Framework yang diterapkan di Windows, akan menambahkan Paket Kompatibilitas Windows ke proyek membuat mereka tetap bekerja Core 3.0 jika jenis referensi ketergantungan keras disediakan oleh paket?

Ya, ini kompatibel dengan biner.

Ada ekosistem besar pustaka komersial yang sangat matang yang sayangnya memiliki ketergantungan pada System.Drawing, GDI, dan terkadang Registry (!). Jika sekarang ini hanya akan berfungsi dengan 2.1 dan hanya didukung selama tiga tahun, ini adalah masalah yang dapat menghentikan adopsi Core di beberapa perusahaan.

Seperti yang sudah saya sebutkan beberapa kali di thread ini. Kami menambahkan kemampuan untuk secara langsung mereferensikan dependensi yang dikompilasi terhadap .NET Framework di proyek .NET Core.

@poke Anda benar tentang pesan itu, tidak jelas sama sekali, kesalahan saya.

Dari mana datangnya ini sekarang? Terakhir kali, pesannya masih "kami sedang menyelidiki penawaran LTS 'dukungan diperpanjang'". Apakah ini hal yang nyata sekarang dan kita mendapatkan 6 tahun?

Saya membuat 6, saya tidak tahu berapa lama dukungan akan diperpanjang ketika kami menawarkannya.

.NET Core selalu akan menggantikan .NET Framework (Awalnya itu akan menjadi .NET Framework 5), tetapi penulisan ulangnya sangat ambisius sehingga sekarang digunakan untuk mendukung aplikasi desktop.

Wah banyak banget komentar kocak di sini. Sepertinya ada banyak amukan nerd yang salah tempat, diselingi dengan orang yang gagal membaca artikel.

bersiap

@edandersen apakah Anda menjalankan ApiPort pada dll eksternal ini? Ini akan menunjukkan kepada Anda jika mereka menggunakan API apa pun yang tidak tersedia di .NET Core. Jika hanya menggunakan API yang tersedia maka itu seharusnya tidak menjadi masalah, jika tidak, mengetahui API mana yang hilang membantu diskusi dan prioritas fitur.
Paket kompatibilitas windows sudah menyediakan fungsionalitas untuk system.drawing dan registri. Apakah Anda sudah mencoba menjalankan hal ini di .NET Core? System.Drawing bahkan berfungsi pada * nix menggunakan libgdiplus mono. Ini memungkinkan kita untuk menggunakan ClosedXML pada sistem non-windows untuk bekerja dengan file Excel.

Ketergantungan terbesar .NET Framework untuk aplikasi "terkini" di perusahaan kami adalah fungsionalitas WCF.
Pustaka klien .NET Core WCF semakin baik. Saya belum memeriksa status saat ini tentang seberapa baik mereka bekerja dengan beberapa layanan yang kami konsumsi tetapi di masa lalu, kami tidak dapat berbicara dengan beberapa layanan. Tetapi fungsionalitas yang hilang sudah ada dalam daftar masalah mereka. Sebaliknya, layanan sederhana bekerja dengan baik!
Di sisi lain, tidak ada pengganti "penurunan" untuk hosting layanan SOAP di .NET Core. Ini akan memblokir migrasi beberapa aplikasi ke .NET Core (tetapi seperti yang disebutkan - tidak perlu).
Untuk aplikasi ASP.NET Core terbaru, kami membuat aplikasi web proxy ASP.NET tambahan yang hanya menghosting layanan WCF dan kemudian meneruskan ke aplikasi ASP.NET Core melalui HTTP / JSON. Tidak terlalu cantik dan menambah kompleksitas penerapan tetapi memungkinkan untuk beberapa titik integrasi.

Saya tidak mengatakan bahwa saya benar-benar menginginkan kemampuan hosting WCF di .NET Core, mengingat saya pusing saat mengonfigurasinya. Beberapa opsi untuk meng-host layanan SOAP dan menghasilkan WSDL akan keren. Saya telah melihat beberapa perpustakaan OSS mencoba melakukan itu. Mungkin ini sudah cukup.

@ david_cinta

Poin yang adil, tapi saya tidak mengerti apa hubungannya dengan dukungan yang lebih baik. Klaim dibuat bahwa beralih ke Java akan lebih baik karena perpustakaan yang tidak terlalu cacat (yang merupakan masalah titik waktu) dan dukungan perusahaan (siklus dukungan yang lebih lama).

Intinya adalah bahwa meskipun versi Java LTS juga tiga tahun, kompatibilitas di antara semua implementasi utama adalah emas, yang merupakan sesuatu yang ingin Anda buang keluar jendela di sini.

Keseluruhan ini .NET Framework, .NET Core, Xamarin, .NET Standard salah langkah mulai terlihat seperti masa lalu yang baik dari WinDev vs DevTools, tepat di dalam tim .NET untuk perubahan.

Jadi secara alami pelanggan bersedia pindah ke platform yang tidak terlihat seperti tim internal yang berjuang untuk fitur peta jalan.

Keputusan ini tidak membangkitkan kepercayaan diri.

Ini benar-benar terasa seperti kesalahan di pihak tim .NET, terutama dalam konteks iklim saat ini!

Bagi mereka yang menyebut Java, pernahkah Anda melihat apa yang terjadi di sana baru-baru ini? Di antara gugatan mereka yang benar-benar gila terhadap Google karena menggunakannya di Android dan kejahatan perizinan terbaru mereka, perilaku Oracle secara konsisten tampak seperti perusahaan yang ingin membunuh produk yang tidak diinginkan, bukan yang ingin produk itu berkembang!

Ini adalah waktu yang tepat bagi Microsoft untuk memanfaatkan ini dengan pemasaran yang kuat yang menyarankan mereka melakukan kebalikannya, dan bahwa .NET adalah tempat yang tepat untuk opsi pengembangan yang waras, stabil, dan aman. Sebaliknya, kami mendapatkan ... ini. :kecewa:

@jamur_kejang

Kami yang bekerja di kedua lingkungan benar-benar menghargai pekerjaan Oracle
telah melakukan dengan Java.

Mereka yang jarang menggunakan Java dalam produksi, membenci Oracle, yang mendapatkan
kalah dalam argumen kebencian terhadap mereka.

Dalam hal Android, saya mendukung sepenuhnya gugatan tersebut, sebagai Google
berhasil bercabang pada platform Java, sehingga berhasil di mana Microsoft gagal
dengan J ++. Masih menantikan hari JAR acak di Maven Central dijamin benar-benar berfungsi di Android.

Adapun. NET, saya mulai muak dengan reboot terus menerus
bagaimana kami seharusnya menargetkan platform Microsoft.

Seluruh WinRT, UAP, UWP, .NET Native menjatuhkan F #, XNA, Core 1.0 telah pergi
banyak anggur asam dan keputusan baru-baru ini tidak membuat segalanya menjadi lebih baik
secara keseluruhan.

NET adalah platform favorit saya jadi tolong jangan merusaknya lebih jauh.

@tokopedia

Sekarang saya mengerti bahwa 2.1 sebagai versi LTS terakhir yang didukung pada .NET Framework berarti tidak ada tempat untuk meningkatkan

Yang berarti itu menjadi platform yang tidak didukung, siapa pun di dalamnya harus memperlakukannya seperti lava dan berebut untuk turun sebelum mencapai ujung EOL yang tidak didukung.

Itulah salah satu poin yang saya tidak terlalu mengerti dalam keseluruhan diskusi. Apa yang sebenarnya Anda dapatkan dari dukungan LTS selain perbaikan keamanan (yang dapat tercakup dalam dukungan LTS yang diperpanjang)?

Dalam dukungan LTS arus utama, hanya ada dua hal yang diharapkan:

• Perbaikan keamanan
• Perbaikan bug penting

Sebagian besar yang sebelumnya (perbaikan keamanan) akan ditambal melalui Pembaruan Windows (karena Anda menargetkan .NET Framework). Jadi hanya perbaikan keamanan & bug kritis yang tersisa yang ada di ASP.NET Core itu sendiri.

Katakanlah sudah tahu bahwa dukungan berakhir 2018, saya tidak berharap ada orang yang memulai proyek baru pada tahun 2020, jadi (imho) tidak mungkin Anda menemukan bug penghenti pertunjukan kritis setelah 2021 (atau 2026 atau berapa lama dukungan diperpanjang dimaksudkan menjadi).

Itu hanya membiarkan bug keamanan terbuka, yang masuk akal untuk ditutup dengan LTS.

Dalam jawaban sebelumnya saya melihat penyebutan TLS 1.4 dll. Ini tidak akan tercakup dalam LTS karena itu adalah fitur baru, yang sama bahkan untuk Java (Java 6 hanya memiliki Dukungan TLS 1.0 - TLS 1.1 jika Anda menghitung dalam pembaruan non-publik hanya tersedia untuk pelanggan dukungan perpanjangan Oracle).

• Siapa pun yang berpikir untuk menggunakannya sebagai platform pementasan untuk pindah ke .NET Core telah menjadi pilihan yang kurang layak karena mereka menghadapi risiko terdampar di platform yang tidak didukung jika migrasi memakan waktu lebih lama dari yang diharapkan atau mereka menemui hambatan jika ada ketergantungan yang mereka andalkan tidak dapat berjalan di .NET Core.
  Tetapi API mana yang hilang yang sekarang dapat Anda gunakan dengan ASP.NET Core di .NET Framework, tetapi tidak bisa di ASP.NET Core di paket .NET Framework + Kompatibilitas?

Saya pikir itulah poin yang lebih penting di sini, untuk mengidentifikasi yang ini dan mengirimkan API yang hilang dengan paket Kompatibilitas di masa mendatang atau menambahkannya ke .NET Core, sehingga memungkinkan untuk mereferensikan pustaka .NET Framework bahkan ketika menargetkan .NET Core.

Sejak .NET Core, Anda dapat mereferensikan (dan menggunakan) pustaka .NET Framework apa pun dalam proyek .NET Core selama itu hanya menggunakan API yang tersedia di .NET Standard atau .NET Core .

Ini tidak memerlukan pembuat perpustakaan untuk memperbarui perpustakaannya untuk menargetkan netstandard / netcoreapp.

Mungkin akan membantu jika Microsoft akan memperluas halaman web / perpustakaan NuGet dengan fitur / tautan di sebelah setiap paket nuget di nuget.org yang menampilkan laporan jika perpustakaan ini menggunakan API yang tidak kompatibel yang tidak tersedia dalam versi tertentu dari .NET Core?

Sebagai contoh

'Company.Example.MyLib` akan ditampilkan

• .NET Core 2.1: dukungan parsial (laporan terperinci) - di mana laporan terperinci akan menunjukkan Apis yang berfungsi dan mana yang tidak
• .NET Core 3.0 :; didukung penuh

Ini harus dimungkinkan dengan menjalankan .NET Portability Analyzer? Bonusnya adalah, jika menambahkan daftar API publik yang aman untuk dipanggil (dengan menganalisis Kode IL dan melihat API lain yang memanggilnya untuk memastikan aman atau tidak)?

Ini setidaknya akan mempermudah pengembang untuk menentukan apakah pustaka tertentu yang mereka perlukan untuk proyek mereka dapat berjalan di .NET Core atau tidak bahkan jika itu tidak secara eksplisit menyebutnya?

Saat ini agak merepotkan untuk mengetahui bahwa jika API didukung atau tidak, Anda memerlukan pustaka, menjalankan penganalisis secara lokal di atasnya. Banyak pengembang mungkin tidak tahu bahwa mereka dapat menggunakan beberapa pustaka yang tidak secara resmi mendukung standar bersih.

@davidfowl @terrajobst Apakah itu tambahan yang layak untuk NuGet? Untuk membuat dapat ditemukannya pustaka .NET Framework yang kompatibel dengan -NET Core lebih mudah dan lebih cepat?

• Siapa pun yang dipaksa untuk menggunakan server .NET Framework infrastruktur terkelola perusahaan mereka yang ada tidak dapat berpartisipasi dalam menggunakan model dan ekosistem dev yang baru dan harus melihat pengetahuan / keterampilan ASP.NET klasik mereka menjadi kurang berharga setiap hari.

Itu bukan argumen untuk atau menentang dukungan .NET Framework atau tidak. Orang-orang yang terjebak pada dependensi lama dan tidak dapat bermigrasi ke .NET Core (dengan paket kompatibilitas atau dengan pustaka .NET Framework) tidak akan dapat melakukan keduanya setelah itu. Bagaimana hal itu mengubah segalanya?

Namun, bagian dari aplikasi monolitik dapat dipecah dan secara bertahap memindahkan bagian dari aplikasi lama ke yang baru, tapi itu cerita yang berbeda.

• Tidak ada organisasi yang ingin dipaksa melakukan migrasi yang tidak direncanakan karena panduan yang mereka andalkan untuk mendasarkan keputusan anggaran, perencanaan, dan investasi mereka telah berubah.

Jika keuntungannya melebihi investasi, mengapa tidak? yaitu jika ada fitur unik yang memberi Anda keuntungan besar atau peningkatan kinerja yang besar.

Jika tidak, tetap gunakan sistem lama. Pengembangan perangkat lunak seperti ini selamanya. Masih ada perusahaan yang menjalankan perangkat lunak yang dikembangkan di Fortune dan Cobol.

Ada banyak orang yang tidak dapat atau tidak ingin pindah ke .NET Core, mereka ingin berbagi tingkat dukungan yang sama seperti ASP.NET klasik (yang disarankan oleh pesan saat ini tanpa batas).

API yang hilang bukan satu-satunya alasan yang mencegah migrasi, misalnya mereka dapat mengandalkan ketergantungan di mana tim pengembang membuatnya tidak ada lagi, ini adalah komponen penting yang tidak dapat diubah, tidak dapat difaktor ulang dengan aman (mis. tidak ada tes), itu dibagikan dengan sistem lain .NET FX-only, itu dikelola oleh departemen lain yang tidak memiliki anggaran, kapasitas untuk mengubahnya atau karena faktor eksternal seperti infrastruktur yang dikelola perusahaan mereka hanya mendukung berjalan di server .NET Framework.

Ya tapi ketergantungan yang mana? Contoh konkret akan diperlukan untuk mengidentifikasi API mana yang digunakan dependensi eksternal ini. API ini dapat ditambahkan ke .NET Core 3.0 atau versi .NET Core yang akan datang.

Ini memungkinkan untuk menggunakan pustaka .NETFramework ini di proyek inti .NET. Satu-satunya masalah adalah ketika pustaka .NET Framework menggunakan API yang tidak tersedia di .NET Standard atau .NET Core. Tetapi untuk memperbaiki umpan balik itu diperlukan untuk mengidentifikasi perpustakaan.

@pjmlp

@tokopedia

Orang lain mungkin memilih tumpukan alternatif lain juga.

Itu adil, tetapi tumpukan alternatif memiliki kebijakan dukungan yang sama. Java telah pindah ke model LTS serupa (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

Detail kecil yang Anda abaikan adalah bahwa Java, dan tumpukan lainnya, masih kompatibel di seluruh versi tidak seperti .NET Framework dan .NET Core tanpa memerlukan Standar yang hanya diterapkan sebagian di seluruh implementasi runtime.

Itu tidak sepenuhnya benar untuk edisi Java selanjutnya. Java 9 menambahkan langkah pertama untuk memodularisasi runtime, yang merupakan perubahan yang mengganggu . Di Versi 9, ini telah dinonaktifkan secara default tetapi di versi yang akan datang, bendera akan diaktifkan secara default (atau tidak dapat mematikannya) dan ini membuat perubahan yang mengganggu pada aplikasi lama.

Misalnya untuk banyak pustaka yang menggunakan API internal melalui beberapa sihir refleksi bisa dan akan rusak dengan perubahan itu. Dan banyak dari perpustakaan ini, seperti di dunia .NET, tidak dikelola lagi, sehingga pembaruan tidak diharapkan.

@ TsengR

Terlepas dari perubahan besar yang diperkenalkan di Java 9, 100% dari semua kerangka kerja Java yang relevan berfungsi di Java 9, 10 dan 11, yang jelas tidak terjadi di seluruh .NET Framework, UWP dan Core.

Bayangkan bahwa bahkan ada dua framework GUI lintas platform resmi, sementara kami masih belum mendapatkan peta jalan resmi untuk Core!

@pjmlp

@ TsengR

Terlepas dari perubahan besar yang diperkenalkan di Java 9, 100% dari semua kerangka kerja Java yang relevan berfungsi di Java 9, 10 dan 11, yang jelas tidak terjadi di seluruh .NET Framework, UWP dan Core.

Bayangkan bahwa bahkan ada dua framework GUI lintas platform resmi, sementara kami masih belum mendapatkan peta jalan resmi untuk Core!

Maaf, itu sama sekali tidak masuk akal.

Modul internal Java 9, yang mencegah refleksi ke dalam modul-modul ini kecuali --add-opens dipanggil (dan iirc seharusnya selalu menjadi solusi sementara sehingga orang dapat terus menjalankan aplikasi lama mereka dan menghapus beberapa versi kemudian).

Jika Anda melewatkan drama dan omong kosong ketika Java 9 akan dirilis kembali, berikut adalah tanggapannya:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

Untuk membantu seluruh ekosistem bermigrasi ke platform Java modular di a
langkah yang lebih santai Saya dengan ini mengusulkan untuk mengizinkan akses reflektif ilegal
dari kode di jalur kelas secara default di JDK 9, dan untuk melarangnya masukrilis masa depan.

Selain itu, Java EE 9 tidak digunakan lagi, JAX-WS sudah tidak digunakan lagi dan akan dihapus di Java EE 11. Itu secara kasar bisa dilihat sebagai setara dengan WCF. Penggunaan apa pun yang berlaku tidak dapat di-porting ke versi yang lebih baru juga tanpa menggantinya dengan sesuatu yang lain, yang merupakan proses migrasi. Tidak lebih atau kurang berbeda dengan migrasi dari ASP.NET Core di .NET Framework ke ASP.NET Core di .NET Core (atau dari ASP.NET ke ASP.NET Core @ .NET core)

https://www.oracle.com/corporate/features/understanding-java-9-modules.html

Integritas platform yang lebih baik — Sebelum Java 9, banyak kelas dalam platform yang tidak dimaksudkan untuk digunakan oleh kelas aplikasi dimungkinkan. Dengan enkapsulasi yang kuat, API internal ini benar-benar dikemas dan disembunyikan dari aplikasi yang menggunakan platform. Ini dapat membuat migrasi kode lama ke modularized Java 9 bermasalah jika kode Anda bergantung pada API internal.

Aplikasi apa pun yang menggunakan API internal ini (termasuk semua dalam namespace sun.* yang digunakan oleh beberapa perpustakaan lama - atau digunakan kembali ketika Java 9 akan dirilis) atau menggunakan perpustakaan pihak ketiga yang bergantung pada API ini atau pustaka lain mungkin tunduk pada perubahan yang mengganggu ini. Masalahnya adalah, seperti di .NET Framework dan .NET Core adalah Anda tidak melihat dari pustaka saja API mana yang dipanggil atau tidak.

@Tokopedia

Modul internal Java 9, yang mencegah refleksi ke dalam modul-modul ini kecuali --add-opens dipanggil (dan iirc seharusnya selalu menjadi solusi sementara sehingga orang dapat terus menjalankan aplikasi lama mereka dan menghapus beberapa versi nanti).

Atau Anda dapat menggunakan mode classpath dan melewatkan kekacauan yaitu modul. Mode itu akan tetap ada di masa mendatang. Dan jika Anda masuk ke modul, Anda dapat secara eksplisit mendeklarasikan dependensi ke dalam paket modul lain.

Selain itu, Java EE 9 tidak digunakan lagi, JAX-WS sudah tidak digunakan lagi dan akan dihapus di Java EE 11. Itu secara kasar bisa dilihat sebagai setara dengan WCF.

Semua J2EE sudah tidak digunakan lagi dan dihapus di Java 11, yang sudah keluar. Tetapi J2EE hanya mendefinisikan antarmuka, bukan implementasinya. Untuk terus menggunakan J2EE, yang saya lakukan, Anda hanya perlu beralih dependensi. Semua implementasi terpisah, dan berfungsi dengan baik di Java 11.

Aplikasi apa pun yang menggunakan API internal ini (termasuk semua di ruang nama sun. * Yang digunakan oleh beberapa perpustakaan lama - atau digunakan kembali ketika Java 9 akan dirilis) atau menggunakan perpustakaan pihak ketiga yang bergantung pada API ini atau perpustakaan lain mungkin terkena perubahan yang melanggar ini.

Yang selalu terjadi. Mereka adalah API yang tidak berdokumen. Seharusnya tidak ada yang menggunakannya dan itu bisa diubah atau dihapus kapan saja. Banyak dari API internal yang umum (ab) digunakan dibiarkan agar tidak merusak program yang ada, sehingga mereka dapat bermigrasi ke API yang sesuai di masa mendatang.

Beberapa API sudah tidak digunakan lagi, tetapi yang kita bicarakan adalah API spesifik dan bukan keseluruhan ekosistem JRE atau Java. Pekerjaan yang diperlukan untuk berpindah dari API tersebut ke API yang lebih baru, resmi, dan terdokumentasi umumnya minimal.

Dan Java selalu lebih bersedia untuk merusak kompatibilitas ke belakang daripada .NET. Misalnya, di Java sekarang ilegal untuk mendeklarasikan tipe bernama var karena dicadangkan untuk inferensi lokal. Di Java, menamai variabel _ ilegal karena dicadangkan untuk digunakan sebagai discard / wildcard. C # membuat keputusan yang berlawanan dalam kedua kasus, atas nama menjaga kompatibilitas ke belakang.

Jangan salah paham, Java itu sendiri berantakan. Di antara modul, dukungan untuk Java 8 hampir berakhir dan Oracle menjadi serakah dengan lisensi JRE, ada banyak peluang bagi Microsoft untuk mengubah orang. Tetapi itu sangat tidak mungkin terjadi jika Microsoft akan mengeluarkan pesan yang beragam mengenai dukungan dan evolusi platform mereka di masa depan.

@Tokopedia

Itulah salah satu poin yang saya tidak terlalu mengerti dalam keseluruhan diskusi. Apa yang sebenarnya Anda dapatkan dari dukungan LTS selain perbaikan keamanan (yang dapat tercakup dalam dukungan LTS yang diperpanjang)?

Ada jam yang terus berdetak di LTS itu yang akan berakhir tanpa tempat untuk ditingkatkan yang merupakan titik kunci yang disembunyikan ketika Java LTS dilemparkan sebagai perbandingan. Dengan Java dan .NET Framework Anda selalu memiliki tingkat keyakinan yang tinggi bahwa Anda dapat memutakhirkan sistem yang ada dengan sedikit usaha mengingat fokusnya yang kuat pada kompatibilitas mundur. Dengan tidak ada lagi jalur peningkatan, sistem yang ada dihadapkan pada keharusan untuk bermigrasi ke runtime baru atau tetap berjalan pada platform yang tidak didukung. Untuk berbagai alasan akan ada sistem yang tidak memungkinkan untuk bermigrasi ke .NET Core meninggalkan masa depan mereka (dengan keputusan ini) untuk tetap menjalankan fungsi bisnis penting mereka pada platform yang tidak didukung.

Tidak yakin apa metafora terdekat dari keputusan ini akan berada di tanah Jawa, mungkin memaksa sistem yang ada untuk bermigrasi untuk berjalan di GraalVM, banyak hal akan berfungsi, beberapa tidak akan, semakin besar sistem semakin kurang kepercayaan untuk dapat memprediksi kompatibilitas / masalah sampai migrasi secara fisik dicoba.

Saya setuju bahwa banyak yang telah dilakukan untuk membuat migrasi ke .NET Core mungkin, tetapi masih akan ada sejumlah faktor eksternal (termasuk di luar kendali MS) yang akan mencegah migrasi dan keputusan ini hanya akan membuat migrasi lebih kecil kemungkinannya seperti sebelum pengumuman ini ASP.Core / FX adalah jalur migrasi yang populer, tetapi tidak lagi bijaksana untuk merekomendasikan strategi migrasi keseluruhan untuk memasukkan migrasi ke platform yang tidak didukung di masa depan, yang akan mencegah banyak migrasi dari yang terjadi mengakibatkan lebih banyak sistem / devs yang tersisa di ASP.NET klasik yang stagnan.

Sebagian besar yang sebelumnya (perbaikan keamanan) akan ditambal melalui Pembaruan Windows (karena Anda menargetkan .NET Framework). Jadi hanya perbaikan keamanan & bug kritis yang tersisa yang ada di ASP.NET Core itu sendiri.

Organisasi tidak ingin mendasarkan perusahaan mereka pada platform yang didukung sebagian dengan harapan bahwa bug atau masalah keamanan di masa mendatang hanya akan terjadi di pustaka yang telah dialokasikan untuk dukungan. Ini akan sangat membantu jika ASP.Core / FX akan dicakup oleh tingkat dukungan yang sama seperti .NET Framework lainnya di mana kerentanan keamanan di masa depan akan diselesaikan.

Saat ini hanya MS yang dapat menambal dan merilis paket ASP.Core NuGet yang diperbarui, dengan pohon ketergantungan yang saling berhubungan menjadi OSS tidak akan banyak membantu di sini kecuali 2.1 PR yang mereka terima (pasca LTS) akan ditinjau, diterima dan dirilis.

Pada akhirnya setelah semua detail dibahas, pertanyaan terakhir yang masih penting adalah:

Bisakah kita terus menjalankan sistem yang ada di ASP.Core / FX?

Secara teknis itu akan mungkin tetapi tanpa jaminan bahwa bug kritis / kerentanan keamanan masa depan akan diselesaikan, rekomendasi tersebut menjadi TIDAK, membiarkan ekosistem eksternal terpengaruh menyerap rasa sakit dari keputusan ini.

Jika ASP.NET Core akan menjadi .NET Core saja, bagaimana perasaan kita tentang keseluruhan .NET Standard?

Jika Microsoft sendiri tidak bertaruh untuk alasan (yang tidak diragukan lagi valid), mengapa kita harus?

Apakah akan ada libs kelas satu, yang terbaru .NET Core saja dan libs "sederhana", standar .NET yang kurang canggih?

Ini tampaknya mematikan drive untuk meningkatkan platform non-.NET-Core.

Semoga seseorang bisa menunjukkan bahwa saya salah dan meredakan kekhawatiran saya.

Hai,
Saya melihat nilai dalam mendorong dan saya menyukainya, tetapi saya melihat 3 masalah utama tentang keputusan ini:
1) Netstandard akan menjadi warga negara kelas dua jika tidak ada orang di dalam Microsoft yang membangun sesuatu yang sulit dengannya, jika kalian tidak melakukan dogfood, bagaimana Anda bisa meminta pengembang lain untuk melakukannya? Saat ini penulis perpustakaan harus bekerja sangat keras, dukungan tidak akan meningkat jika ppl internal tidak menggunakan standar.
2) ada nilai dalam menjalankan inti aspnet di runtime lain.
3) ada nilai dalam perangkat lunak yang berjalan di runtime lama (dengan ketergantungan yang tidak akan pernah disentuh) yang tidak boleh dibuang begitu saja.

Lalu ada komunikasi: Saya pikir semua orang hanya akan menyukai satu runtime .net yang berjalan di mana-mana, tapi itu utopia untuk masa mendatang dan standar bersih dibuat sebagai pengganti. Dari sudut pandang saya, setiap proyek yang tidak menargetkan standar bersih tetapi platform adalah langkah yang tidak mengarah ke arah visi itu.
Jelas bahwa .net framework dalam mode pemeliharaan, .netcore akan menggantikannya (meninggalkan beberapa tubuh mati) dan mono akan berjalan di perangkat, cerita aot dan CoreRT tidak terlihat maju.

Dengan netcore 3.0 Anda melakukan dua hal sekaligus: mendukung beban kerja desktop dan "memberi tahu ppl untuk langsung melompat agar tetap relevan". Saya pikir ini membutuhkan lompatan kepercayaan dari pengembang dan itu terlalu optimis karena semua orang tahu bahwa banyak proyek tidak akan dimigrasi karena beberapa ketergantungan yang hilang, yang mungkin akan ditambahkan di rilis 3.1 / 3.2 di masa mendatang dalam 1-2 tahun ( sangat dekat dengan 3 LTS tahun 2.1). Sementara itu, developer yang ingin relevan diblokir untuk menggunakan bit 3.0 karena dependensi yang tidak dapat mereka kendalikan.

Apakah mungkin untuk menunda keputusan ini setelah ppl mengujinya dan melihat implikasi sebenarnya?
Apakah mungkin untuk memiliki inti aspnet dikompilasi ke kedua netstandard dan netcoreapp seperti Anda meresepkan penulis perpustakaan untuk dilakukan? Tidak apa-apa untuk memiliki kinerja yang menurun yang berjalan pada kerangka kerja .net 😄

Roslyn sekarang berjalan di .NETStandard 2.0 -> https://github.com/dotnet/roslyn/pull/30914

Itu pasti dianggap sebagai sesuatu yang sulit!

@tokopedia

Saya yakin ini akan mulai sangat membatasi opsi untuk pengembangan masa depan sistem .Net Framework yang tidak dapat bermigrasi karena berbagai alasan, karena komunitas sedang mengalihkan upaya ke ASP.Net Core.

Misalnya Identity Server telah pindah ke ASP.Net Core dan posting baru-baru ini tentang masa depan SignalR menyatakan tidak mengherankan bahwa ASP.Net Core SignalR akan menjadi fokus upaya pengembangan di masa depan, dengan ASP.Net SignalR berada dalam mode pemeliharaan - yang mana pada saat menyatakan akan mendukung .Net Framework & .Net Core dan saya berharap ini adalah tren yang akan terus kita lihat.

Saya tahu bahwa dukungan LTS untuk ASP.NET Core sudah ditetapkan pada 3 tahun, tetapi untuk penerapan di lokasi, diperlukan siklus hidup yang lebih lama karena kami harus memberikan dukungan sepanjang jalur ini (4 tahun) kepada pelanggan kami.
Selama periode ini kami harus dapat merilis tambalan yang menyertakan perbaikan keamanan tanpa perubahan besar pada aplikasi. Ini untuk tetap sejalan dengan proses kontrol perubahan pelanggan kami yang akan membutuhkan pengujian penerimaan pengguna yang ekstensif oleh mereka untuk perubahan yang lebih besar dan agar kami tidak perlu membuat perubahan besar seperti bermigrasi ke versi yang lebih baru pada rilis yang berada dalam mode pemeliharaan .

Apakah ada kemungkinan kebijakan LTS berubah? sesuatu seperti strategi Ubuntu untuk rilis LTS setiap 2 tahun dengan dukungan 5 tahun - meskipun saya akan meminta 6 tahun agar rilis saat ini memiliki dukungan 3+ tahun sementara pekerjaan untuk bermigrasi ke versi baru dilakukan.

Saya memahami bahwa dukungan tambahan telah disebutkan, tetapi saya berasumsi bahwa ini adalah sesuatu yang harus dibeli oleh setiap klien kami, yang menurut saya tidak sesuai jika pemasangan awal mereka (setelah dev, proses penjualan, UAT, dll.) 2 tahun dukungan.

Juga, penasaran bagaimana memperlakukan pustaka .netstandard dalam .netcore 3.0 kali.
Slogan dari .netstandard adalah "Satu perpustakaan untuk mengatur semuanya".
Sebelum ini, sepertinya itu berarti segalanya.
Setelah ini, kelihatannya itu sedikit berarti.

Hanya untuk menunjukkan seberapa besar konsekuensi yang ditimbulkan oleh keputusan ini - bagaimana dengan Blazor? Akankah itu berhenti didasarkan pada, standar bersih? Haruskah kita mengharapkan itu juga?

Adakah yang bisa mengklarifikasi ini?

Jadi, apakah rekomendasi untuk pustaka seperti Newtonsoft.Json (yang dapat memanfaatkan kinerja tinggi) untuk beralih ke .NET Core daripada .NET Standard? Saya tidak melihat banyak perbedaan antara library semacam itu dan ASP.NET Core. Kami menyematkan layanan REST ke dalam aplikasi yang lebih besar - beberapa di antaranya dapat dengan mudah dipindahkan ke .NET Core dan beberapa tidak.

Dalam pemahaman saya, rekomendasi untuk perpustakaan adalah menargetkan .NET Core 3 dan .NET Standard 2.x jika Anda ingin mendapatkan keuntungan dari API baru tetapi tidak ingin kehilangan audiens.

Dalam pemahaman saya, rekomendasi untuk perpustakaan adalah menargetkan .NET Core 3 dan .NET Standard 2.x jika Anda ingin mendapatkan keuntungan dari API baru tetapi tidak ingin kehilangan audiens.

Saya pikir jalan di depan adalah standar bersih di mana-mana , dan saat ini, kami hanya dalam transisi. Tetapi dengan langkah seperti ini, orang lain akan (atau perlu) mengikuti dan kami kembali ke multi-penargetan.

.NET Framework dan .NET Core mengisi peran yang sama, jadi saya yakin ASP.NET Core tidak akan berjalan di .NET Framework suatu hari nanti, baik sekarang atau nanti.

Namun, saya melihat masalah besar saat tidak menjalankan .NET Standard X . Sejujurnya, saya tidak memerlukan inti asp.net untuk dijalankan di xamarin atau unity, tetapi senang dapat mengatakan bahwa itu bisa - ini hanyalah kumpulan pustaka lain yang berjalan di platform .NET. Dengan memutuskan kami mendapatkan integrasi yang lebih erat antara .NET Core dan ASP.NET Core dan saya khawatir dengan .NET Core 4.5 kami mengutuk Microsoft.AspNetCore dan @davidfowl memulai DNX 2.0.

Di sisi lain. NET Standard jelas bukan tempat untuk bereksperimen dan sulit untuk memasukkan semuanya dengan benar, jadi bisakah kita berkompromi? Apakah layak untuk memiliki ASP.NET Core saat ini yang hanya menargetkan .NET Core, tetapi versi LTS yang menargetkan .NET Standard? Jika API tidak menemukan jalannya ke .NET Standard, apakah itu benar-benar layak digunakan?

Kami juga dapat melihat ini dengan cara yang mungkin Anda inginkan untuk:

• .NET Core untuk konsol / web / desktop pihak ketiga (standar + api khusus web)
• Unity untuk game (standar + api khusus game)
• Xamarin untuk perangkat / desktop (standar + perangkat / api khusus desktop)

Tapi siapa yang mendorong .NET Standard maju? Seperti yang Anda katakan sebelumnya, sumber daya terbatas, jadi tanpa memiliki kebutuhan aktual untuk mendorong hal-hal (yang dalam proposal saya akan jatuh ke tim inti .net core / asp.net dengan memerlukan perubahan untuk merilis LTS) Saya khawatir. NET Standard akan menjadi cepat basi.

Bagi mereka yang tidak memperhatikan, tampaknya .NET Standard 2.1 baru saja menjatuhkan dukungan untuk .NET Framework.

Mengingat banyak penambahan API di .NET Standard 2.1 memerlukan perubahan runtime agar bermakna, .NET Framework 4.8 akan tetap menggunakan .NET Standard 2.0 daripada menerapkan .NET Standard 2.1. .NET Core 3.0 serta versi Xamarin, Mono, dan Unity yang akan datang akan diperbarui untuk mengimplementasikan .NET Standard 2.1.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

Betapapun menyakitkan saya melihat .Net Framework mendapatkan Silverlight-ed, yang penting bagi saya sehubungan dengan ASP.NET Core adalah ia harus menargetkan .NET Standard .

Sebagai salah satu aplikasi referensi terbesar dalam ekosistem Core / Standar, saya percaya ASP.NET Core memiliki tanggung jawab untuk menjadi juara .Net Standard dan semua hal baik yang diperjuangkannya.

Saya yakin wajar bagi ASP.NET Core untuk meminta perubahan pada standar yang kemudian diterapkan di .NET Core.

Dengan cara yang sama seperti Span dll _is_ tersedia di .Net Framework melalui paket nuget, saya percaya itu wajar jika ASP.NET Core membutuhkan / ingin bergantung pada sesuatu yang belum ada dalam .Net Standard, ketergantungan itu harus disertakan masuk melalui paket nuget.

Akhirnya, saya berharap (terhadap semua bukti yang bertentangan), bahwa akan ada .Net Framework 5.0 yang menargetkan .Net Standard 3.0+ dan akan menjadi instalasi berdampingan dengan 4.x.

Akhirnya, saya berharap (terhadap semua bukti yang bertentangan), bahwa akan ada .Net Framework 5.0 yang menargetkan .Net Standard 3.0+ dan akan menjadi instalasi berdampingan dengan 4.x.

Ya persis. Inilah yang telah saya katakan selama bertahun-tahun sekarang: arsitektur CLR 2.0 telah melayani kami dengan baik untuk waktu yang lama, tetapi itu mulai lama di gigi, dan inilah saatnya untuk peningkatan mendasar dari jenis yang sama seperti Generik. Mungkin agak menyakitkan untuk membuat perubahan yang diperlukan, tetapi itu perlu; memperbarui dengan fungsionalitas baru yang lebih kuat diperlukan dengan cara yang sama seperti Generik dibutuhkan, dan menundanya hanya akan memperburuk rasa sakit, bukan menguranginya, ketika akhirnya terjadi.

Itulah tepatnya .NET Core, dan utas ini adalah rasa sakit sementara yang dialami.

@terrajobst mengatakan itu tidak akan terjadi: lihat utas: https://twitter.com/terrajobst/status/1059525279431815168?s=19

@tokopedia
Ya, kecuali dua hal.

1. Inti bukanlah peningkatan dari Kerangka; itu konsep paralel. Ada begitu banyak hal mendasar yang tidak dapat dilakukan, banyak di antaranya, seperti AppDomains, kami diberi tahu bahwa kemungkinan tidak akan pernah terjadi. Demi Tuhan, kita bahkan masih belum memiliki Reflection.Emit berfungsi! Mempertimbangkan betapa umum hal itu ada di kompiler dan alat pembuat kode, Anda akan berpikir itu benar-benar menjadi salah satu prioritas pertama, namun di sini kita 4 tahun kemudian dan itu tidak berhasil! Ini membuatnya sangat sulit untuk menganggap serius gagasan "Inti sebagai pengganti / peningkatan untuk .Net Framework".
2. Core tidak secara radikal mengupgrade runtime, gaya CLR 2.0. Di bagian "Proposal bahasa apa yang akan mendapat manfaat dari perubahan CLR?" kami memiliki daftar yang bagus dari komunitas fitur hilang yang dianggap penting oleh orang, yang tidak dapat didukung oleh CLR, (atau setidaknya tidak dapat mendukung tanpa kludges besar dan jelek untuk mengatasi keterbatasan CLR,) umumnya karena fitur yang hilang dalam sistem tipe. Berapa banyak dari proposal dalam topik tersebut yang bahkan ditanggapi dengan serius oleh tim Inti? Dan berapa banyak dari mereka yang telah diberhentikan karena orang yang menjalankan proyek tidak ingin meningkatkan runtime? Kami mendapatkan DIM dan ... ada lagi? Apa-apa?

Jadi tidak, .NET Core bukanlah .NET Framework yang ditingkatkan yang membuat pembaruan CLR yang sangat dibutuhkan, karena ini bukan .NET Framework yang ditingkatkan dan tim proyek melakukan semua yang mereka bisa untuk menghindari pembaruan CLR sedapat mungkin. Ini benar-benar kebalikan dari itu.

Demi Tuhan, kita bahkan masih belum memiliki Refleksi yang berfungsi. Mempertimbangkan betapa umum hal itu ada di kompiler dan alat pembuat kode, Anda akan berpikir itu benar-benar menjadi salah satu prioritas pertama, namun di sini kita 4 tahun kemudian dan itu tidak berhasil! Ini membuatnya sangat sulit untuk menganggap serius gagasan "Inti sebagai pengganti / peningkatan untuk .Net Framework".

Akan sangat bagus untuk memahami apa yang tidak berhasil. ASP.NET Core dan EF menggunakan pancaran refleksi di beberapa tempat jadi saya tidak menyadari celah besar. Bisakah Anda menjelaskannya di sini?

Sudah ada setidaknya sejak 2.0 .. iirc bahkan 1.0 memiliki DefineDynamicAssembly, meskipun mungkin bukan keseluruhan paket emit stuff.

Saya juga merasa sulit untuk menganggap serius gagasan bahwa mereka menghindari memperbarui CLR. Pernahkah Anda melihat banyaknya pekerjaan yang dilakukan? https://github.com/dotnet/coreclr/commits/master
Ada fitur bahasa yang dijadwalkan untuk C # 8 yang hanya akan berfungsi pada .NET Core karena perubahan CLR juga. Banyak dari keberatan ini sepertinya merupakan informasi lama (yang cukup adil, karena rencana Microsoft kadang-kadang berubah dengan cepat ...)

@tokopedia

Akan sangat bagus untuk memahami apa yang tidak berhasil. ASP.NET Core dan EF menggunakan pancaran refleksi di beberapa tempat jadi saya tidak menyadari celah besar. Bisakah Anda menjelaskannya di sini?

Memang sudah beberapa bulan sejak saya memeriksanya, jadi ini mungkin telah berubah baru-baru ini, tetapi sejauh yang saya tahu itu mungkin untuk membuat rakitan baru di memori, tetapi tidak menyimpannya ke disk karena alasan misterius yang melibatkan pembuatan File PDB, yang membuat Core tidak berguna untuk pengelola kompiler seperti saya.

Apakah ini sudah diperbaiki? Saya akan senang mendengar bahwa itu ...

@bayu_joo

Saya juga merasa sulit untuk menganggap serius gagasan bahwa mereka menghindari memperbarui CLR

Apa yang saya katakan adalah bahwa mereka menghindari peningkatan secara radikal CLR dengan cara yang sama seperti pembaruan 2.0 (generik.)

Secara khusus, mereka tampaknya secara aktif menghindari perubahan apa pun yang akan menambahkan jenis dasar baru jenis ke sistem jenis, (bentuk, metaclass, DU, dll) atau instruksi IL baru ke set instruksi.

@jamur_kejang

Memang sudah beberapa bulan sejak saya memeriksa, jadi ini mungkin telah berubah baru-baru ini, tetapi sejauh yang saya tahu itu mungkin untuk membuat rakitan baru di memori, tetapi tidak menyimpannya ke disk

Melihat https://github.com/dotnet/corefx/issues/4491 (di mana Anda pernah berkomentar di masa lalu), saya pikir situasinya masih sama. Meskipun menurut saya kehilangan satu fitur tertentu (meskipun itu yang penting) sangat berbeda dari "kami bahkan belum memiliki Reflection.Emit ".

yang membuat Core tidak berguna bagi pengelola kompiler seperti saya

Bagaimana Reflection.Emit berguna bagi penulis kompiler? Saya pikir itu terbatas untuk memproduksi rakitan untuk kerangka kerja saat ini, jadi tidak dapat digunakan untuk membuat misalnya rakitan Standar Bersih sama sekali, yang menurut saya akan menjadi batasan yang signifikan untuk kompiler apa pun.

Apa yang saya katakan adalah bahwa mereka menghindari peningkatan secara radikal CLR dengan cara yang sama seperti pembaruan 2.0 (generik.)

Saya pikir ada beberapa inersia untuk tidak mengubah CLR, meskipun ada juga beberapa alasan yang sangat bagus untuk itu, terutama jika Anda menganggap bahwa perubahan seperti itu paling berguna dan paling tidak menyakitkan ketika sebuah platform masih muda.

Saya pikir DIM adalah tanda bahwa ini mungkin berubah, tetapi saya masih tidak mengharapkan instruksi IL baru ketika JIT intrinsik sering dapat bekerja dengan baik, atau jenis jenis baru ketika mereka dapat dikodekan secara wajar dalam sistem jenis yang ada.

@tokopedia

Meskipun saya pikir kehilangan satu fitur tertentu (meskipun itu yang penting) sangat berbeda dari "kami bahkan belum memiliki Reflection.Emit yang berfungsi".

Jika Anda memiliki editor teks yang memungkinkan Anda mengetik file teks tetapi tidak menyimpannya, bukankah Anda akan mengatakan itu tidak berfungsi?

Bagaimana Reflection.Emit berguna bagi penulis kompiler?

Sejauh ini berhasil dengan baik. Dan sejauh yang saya ketahui, ini adalah satu-satunya backend kompiler yang tersedia yang memungkinkan Anda untuk menghasilkan rakitan baru dan menyimpannya atau menghasilkan rakitan baru dalam memori dan menjalankannya.

tetap tidak mengharapkan instruksi IL baru ketika intrinsik JIT sering kali dapat bekerja dengan baik

Tentu, tapi bagaimana dengan kasus dimana mereka tidak mau?

atau tipe tipe baru ketika mereka dapat dikodekan secara wajar dalam sistem tipe yang ada.

Pernahkah Anda melihat proposal untuk menerapkan Bentuk dalam sistem tipe yang ada? Tidak ada yang masuk akal tentang itu; ini adalah kludge besar dan jelek dari awal sampai akhir. (Tidak ada yang melawan orang-orang yang datang dengan itu; itu harus dilakukan, mengingat keterbatasan yang dikerjakannya.) Dan semoga berhasil menerapkan metaclass sama sekali tanpa dukungan tingkat CLR!

Kami memerlukan CLR yang diperbarui untuk mengembangkan fitur tingkat yang lebih tinggi dengan cara apa pun yang efisien, dan tidak ada yang benar-benar bekerja untuk mewujudkannya di Core.

Dapatkah seseorang dari tim .net mengklarifikasi apa yang mereka rekomendasikan untuk penerapan di lokasi? Apakah hanya "gunakan asp.net biasa"? Saya berbicara secara khusus untuk komentar @ Edward84

Apakah ini mempengaruhi pustaka dukungan Microsoft.Extensions.* ? Khususnya Microsoft.Extensions.Logging dan Microsoft.Extensions.Configuration .

Kami memiliki basis kode besar yang berbagi API inti yang sama. Beberapa di antaranya adalah WinForms, beberapa adalah ASP.NET klasik, beberapa WCF, dll. Dan aplikasi terbaru adalah .NET Core (Saat ini tidak, tetapi pada akhirnya ketika kami mem-porting pustaka inti kami ke standar .NET)

Kami telah memilih untuk mendasarkan logging inti dan API konfigurasi kami pada abstraksi di pustaka yang disebutkan di atas.

Jadi saya bertanya-tanya apakah ini aman digunakan dalam .NET Standard API yang direferensikan oleh .NET Core dan .NET Framework (4.7.2+) atau mungkinkah mereka juga mulai menggunakan fitur .NET Core saja?

@mvestergaard Seperti yang disebutkan dalam pengumuman itu sendiri :

Paket Microsoft.Extensions (seperti logging, injeksi ketergantungan, dan konfigurasi) akan terus mendukung .NET Standard

Dan dalam komentar @benaadams di utas ini :

Tidak semua pustaka pindah ke .NET Core saja (mis. Microsoft.Extensions.* tetap sebagai .NET Standard)

@mvestergaard seperti yang telah disebutkan, kami sedang

Masalah terbesar yang saya miliki dengan ini adalah tidak dapat menggunakan paket dewasa yang hanya dapat digunakan ketika menargetkan .NET Framework atau yang tidak tersedia di luar .NET Framework seperti yang membutuhkan System.Drawing dan GDI +.

Tampaknya skenario terakhir akan didukung di .NET Core 3.0, namun AFAICT, kami masih akan kehilangan penggunaan pustaka yang stabil dan matang yang hanya dapat digunakan pada .NET Framework.

Contohnya adalah Entity Framework . Kita harus beralih ke EF Core yang yang kembali ke evaluasi klien dalam memori di belakang Anda untuk menyembunyikan masalah yang menyebabkan kinerja. masalah .

Contohnya adalah Entity Framework. Kita harus beralih ke EF Core yang belum matang yang tampaknya masih jauh dari menangani semua skenario kompleks yang EF penuh dapat ...

EF6 akan didukung dalam .NET Core 3.0 seperti yang dijelaskan oleh @DamianEdwards pada minggu ini ASP.NET Community Standup - 6 November 2018 - Fitur ASP.NET Core 3.0 pukul 19:06

@benaadams itu berita bagus! sangat tidak jelas untuk masalah besar seperti itu! :) kerja bagus menemukan itu. Menemukan penyebutan lain di sini .

@ SaebAmini : Anda dapat menggunakan System. Menggambar di .NET Core. Lihat System.Drawing.Common dan Scott Hanselmans Blogpost: https://www.hanselman.com/blog/HowDoYouUseSystemDrawingInNETCore.aspx ,

Dan sebelum CoreCompat.System.Drawing itu ada, sebagai porta System.Drawing milik Mono.

Apakah ada fitur yang hilang untuk kasus penggunaan Anda saat menjalankan .NET Core?

@TsengSR skenario khusus saya yang membuat kami menargetkan .NET Framework adalah:

1. Kebutuhan untuk menggunakan paket Microsoft Solver Foundation, hanya tersedia di .NET Framework.
2. Paket pembuatan gambar kode batang yang menggunakan System.Drawing.
3. Kebutuhan untuk menggunakan EF6.

Ini sekitar setahun yang lalu.

@SaebAmini : Seperti yang disebutkan sebelumnya, dukungan EF6 hadir dalam .NET Core 3.0, System.Drawing sudah ada (dan sebelumnya paket CoreCompat memang ada dan mungkin berfungsi dalam kasus Anda) dan untuk Paket Microsoft Solver Foundation, setelah menjalankan Portability API Analyzer:

Lihat Cara menggunakan Portability Analyzer

https://gist.github.com/TsengSR/f61c03c5f2d63dbe78d6b8c1eed08831 (unduh dan buka HTML, tidak menemukan tempat lain untuk meletakkannya).

Ini menunjukkan 97.93% kompatibilitas dengan .NET Core 2.0 + Platform Extensions (yang dirilis sekitar setahun yang lalu) dan itu mencantumkan API yang tidak kompatibel, yang sebagian besar terkait dengan System.Web yang sudah usang dan System.ServiceModel / System.Data.Linq .

Sekarang, saya tidak menggunakan paket ini sebelumnya, dan saya tidak yakin mengapa pemecah membutuhkan akses ke System.Web dan HttpContext atau System.ServiceModel , tetapi jika Anda tidak Tidak memerlukan salah satu dari tesis (dan Anda tahu kasus penggunaan Anda tidak memanggil API ini), kemungkinannya cukup tinggi, bahwa Anda dapat menggunakannya pada Ekstensi Platform .NET Core 2.0 / 2.1 + atau di .NET Core 3.0, bahkan jika tidak secara khusus menargetkan moniker netstandard atau netcoreapp20 .

Jadi secara teknis, kemungkinannya bagus bahwa Anda dapat memigrasikan aplikasi Anda ke .NET Core 2.0 + Platform Extensions setahun yang lalu, jika EF Core 2.0 dapat memenuhi kebutuhan kebutuhan aplikasi Anda (tentu saja itu memerlukan beberapa pekerjaan migrasi dan pembaruan untuk bekerja dengan EF Core 2.0).

Ya, dibutuhkan lebih banyak pekerjaan untuk menganalisis pustaka yang dimaksud atau fitur untuk kerangka pengganti (EF6 -> EF Core 2.0 / 2.1), tetapi ini jauh dari tidak mungkin. Saya tidak berpikir orang dapat atau harus mengharapkan untuk mem-port semua kode mereka 1: 1 ke ASP.NET Core tanpa melakukan perubahan sama sekali (di luar ASP.NET Core itu sendiri).

Hanya berharap akan lebih jelas menampilkan kompatibilitas API, seperti dengan "lencana" (kompatibel .NET Core 3.0) dan / atau laporan kompatibilitas api terperinci di suatu tempat di halaman nuget untuk membuatnya lebih jelas daripada harus mengunduh paket dan kemudian jalankan melalui penganalisis paket.

Saya pikir pengumuman ini akan lebih baik diterima jika menekankan betapa lebih kompatibel .NET Core telah menjadi. Ada dua faktor yang memungkinkan untuk memindahkan ASP.NET Core dari .NET Framework:
1) Mengurangi kebutuhan untuk .NET Framework, membuat deps warisan tersedia dan meningkatkan interop dan sebagainya
2) Meningkatkan manfaat .NET Core, fitur dan kinerja serta mengurangi beban pemeliharaan

Faktor 2 tampak besar di benak orang yang harus benar-benar membangun ASP.NET! Namun, ada sedikit keuntungan dari sudut pandang pengguna. Orang-orang memiliki sesuatu yang berhasil dan prioritas tertinggi mereka adalah harus tetap bekerja. Kabar baiknya adalah dalam banyak kasus, itu akan terjadi.

Saya setuju dengan @gulbanana. .NET Core sekarang jauh lebih kompatibel dengan .NET Framework. Faktanya, saya dapat meluncurkan aplikasi .NET Framework yang cukup besar hanya dengan mengganti nama .exe menjadi .dll dan menambahkan beberapa .DLL yang hilang ke jalur probing.

Kemajuan alat baris perintah dotnet sangat mengesankan. Terutama penambahan alat global .NET Core. Mereka membuat pembangunan menjadi mudah.

Kompilasi AOT dengan crossgen bagus. Saya bisa terus dan terus.

tl / dr .NET Core sangat mengesankan saat ini.

Apa yang hilang:

• Strategi komunikasi pelanggan saat ini kurang. Pelanggan sangat kecewa ketika mereka mendengar platform .NET favorit mereka difragmentasi oleh Microsoft. Anda harus lebih jelas di sini. Misalnya, ini akan menjadi pendekatan yang jauh lebih baik untuk langsung mengiklankan implementasi .NET tunggal, sangat kompatibel, cepat, dan tahan masa depan kepada orang-orang. Seperti .NET Core, masa depan .NET, akan menyelesaikan sebagian besar masalah Anda, produktivitas roket, kreativitas, membuka ceruk pasar baru, dll.
• Bahkan lebih banyak strategi kompatibilitas di luar kotak
• Antarmuka pengguna grafis. Maksud saya dotnet alat baris perintah sangat bagus, tetapi saat ini kita harus menggunakan editor teks dan konsol tambahan untuk mengerjakan hampir semua proyek dalam format .NET SDK. Visual Studio UI kurang dalam hal ini. Hal ini menjadi hambatan besar bagi banyak orang yang memiliki kebiasaan untuk sekadar tunjuk-dan-klik. Ini juga harus diperbaiki
• Dukungan LTS

@TsengSR Terima kasih atas tanggapan rinci Anda, kawan, info bagus! pada saat menggunakan paket barcode tidak akan berfungsi karena proyek tidak akan mengumpulkan keluhan tentang target yang berbeda. Mungkin saya harus mencobanya lagi. (kecuali jika Anda bermaksud menyusun ulang sendiri dan mewarisinya)

Tidak peduli dengan usaha kok kalau itu wajar. Perhatian utama saya adalah dibiarkan tinggi dan kering tanpa pilihan dengan EF sebagai penghambat utama dan tampaknya tidak akan terjadi. Senang melihat itu telah dipikirkan dengan baik. Meskipun saya setuju dengan @gulbanana bahwa ini dapat diiklankan dengan lebih baik.

Ada banyak masalah yang saling terkait di sini. 2 sen pribadi saya adalah meninggalkan .NET Framework di belakang bukanlah masalah besar. Namun yang memprihatinkan adalah tidak adanya dukungan nyata untuk upaya standardisasi (.NET Standard). Tentu, Anda mungkin tidak ingin menjalankan ASP.NET Core, katakanlah Unity hari ini, tetapi ini bukan tentang hari ini. Ini sekitar satu atau dua tahun ke depan, ketika runtime .NET lain dapat muncul, saya ingin dapat mengatakan "Ya, segera setelah SuperNetRuntime mendukung .NET Standard 2.2 kita dapat menjalankan ASP.NET Core 3 di atasnya" ...

Apakah ada peluang untuk setidaknya "mengumpulkan" semua perubahan yang diperlukan di .NET Core 3 untuk ASP.NET Core 3 dan meneruskannya ke grup kerja .NET Standard sebagai saran?

Hai, akankah paket yang diterbitkan untuk .NetStandard 2.0 atau .NetCore 2.0 terus bekerja dengan .NetCore 3.0. Misalnya: Oracle.ManagedDataAccess.Core target .NetCore 2.0

Jika ada kompatibilitas mundur, maka pindah ke .NetCore 3.0 cocok tetapi jika tidak ada dukungan untuk versi yang lebih lama, maka itu benar-benar tidak berguna kecuali semua bermain mengejar ketinggalan.

.NetFramework memiliki riwayat kompatibilitas bahkan Anda dapat menggunakan .NetFramework 2.0 dalam versi terbaru sehingga sesuatu perlu dipertahankan untuk .NetCore juga setidaknya 2.0 hingga 3.0 dll.

Terima kasih

Hai, akankah paket yang diterbitkan untuk .NetStandard 2.0 atau .NetCore 2.0 terus bekerja dengan .NetCore 3.0. Misalnya: Oracle.ManagedDataAccess.Core target .NetCore 2.0

Ya, .NET Core 3.0 mempertahankan kompatibilitas mundur sehingga dapat menggunakan .NetStandard 1.0 -> .NetStandard 2.1 dan .NetCore 1.0 -> pustaka .NetCore 2.2

@benaadams maka itu bagus. Juga apakah .net framework dll akan berfungsi jika mereka tidak menggunakan api yang hilang?

Terima kasih

Juga apakah .net framework dll akan berfungsi jika mereka tidak menggunakan api yang hilang?

Ya, meskipun lebih aman untuk menggunakan pustaka .NET Standard seperti yang Anda tahu itu akan berfungsi pada .NET Core (dan di Mono, Xamarin, Unity, UWP)

Selain itu, menggunakan Paket Kompatibilitas Windows menambahkan 20.000 API lain di atas .NET Standard 2.0 untuk mendekatkan .NET Core ke .NET Framework (yang dapat Anda lakukan dengan .NET Core 2.1); dan .NET Core 3.0 adalah yang paling kompatibel dengan EF6 (cross-plat), dan di Windows: WinForms, WPF, COM Interop dll

Hai teman-teman,
Untuk memberi pelanggan batu loncatan yang masuk akal dalam perjalanan mereka untuk memigrasi aplikasi ke ASP.NET Core di .NET Core, kami akan memperluas dukungan dan layanan untuk ASP.NET Core 2.1.x di .NET Framework agar sesuai dengan dukungan saat ini kebijakan untuk kerangka kerja ASP.NET berbasis paket lainnya, misalnya MVC 5.x, Web API 2.x, SignalR 2.x. Ini secara efektif berarti paket terkait ASP.NET Core 2.1.x (daftar rinci akhir TBD) akan didukung tanpa batas waktu, di luar periode LTS 3 tahun untuk train .NET Core 2.1 secara keseluruhan.

Berita bagus. Terima kasih telah mendengarkan pelanggan Anda.

Ini akan memakan waktu yang sangat lama bagi kami untuk mem-porting aplikasi MVC lama kami karena kami telah menggunakan MVC sejak CTP3 dan hampir semua titik ekstensi digunakan. Ini mencakup keprihatinan kami.

@DamianEdwards Itu berita bagus! Hanya bertanya-tanya, apakah ini diperbaiki ke 2.1.x atau akankah ini diperbarui ke 2.2.x jika itu akhirnya menjadi rilis LTS? Ada banyak upaya untuk masuk ke versi 2.2 dan itu bahkan belum dirilis. Dan karena ini berlanjut dengan kompatibilitas standar bersih dan berjalan dengan baik pada kerangka kerja penuh, akan sia-sia jika melewatkan ini sepenuhnya untuk dukungan yang diperpanjang.

@poke sementara saya memahami kekhawatiran Anda, kami harus menarik garis di suatu tempat, dan dalam hal ini kami pikir lebih baik untuk menjaga versi tetap sejajar dengan LTS yang mendahuluinya. Ini adalah trade off yang harus diputuskan oleh pelanggan sendiri saat memilih antara LTS atau Kereta saat ini. Fitur baru tidak datang ke LTS karena ini tentang stabilitas. Umpan baliknya adalah untuk dukungan jangka panjang dan kami sudah memiliki kereta untuk itu jadi ini merupakan perpanjangan dari kereta. 2.2 tidak akan menjadi LTS.

@DamianEdwards Ya, saya mengerti itu, terima kasih atas balasan Anda. Saya hanya bertanya karena komentar terakhir tentang ini adalah belum diputuskan , jadi saya hanya ingin tahu apakah dukungan yang diperpanjang ini akan berlanjut jika 2.2 menjadi LTS.

Dan saya pikir itu cukup penting untuk menyoroti ini sehingga orang tidak akan meningkatkan aplikasi kerangka mereka ke 2.2 jika mereka harus mengandalkan dukungan yang diperpanjang ini. Jika tidak, mereka harus menurunkan versi lagi.

Fitur baru tidak datang ke LTS karena ini tentang stabilitas.

Itu tidak benar-benar sesuai dengan keputusan LTS sebelumnya.

@menyodok

Itu tidak benar-benar sesuai dengan keputusan LTS sebelumnya.

Ini membuatku bingung. Dengan cara apa? Apakah Anda mengacu pada fakta bahwa 1.1 telah ditambahkan ke kereta 1.x LTS? Jika demikian, itu adalah anomali kereta rilis pertama kami yang tidak akan terulang. Ke depan, maksud kami adalah untuk lebih konsisten dengan rilis mana yang menjadi LTS vs. Saat Ini (yaitu, di mana saya mendapatkan stabilitas vs. fitur).

@DamianEdwards Saya sebagian besar mengacu pada fakta bahwa setiap rilis sejauh ini merupakan rilis fitur yang besar, dan setiap keputusan LTS biasanya dibuat dalam retrospeksi (setidaknya untuk umum).

@poke Oke. Sejauh ini kami telah memiliki 4 rilis (1.0, 1.1, 2.0, 2.1) dengan rilis ke-5 akan segera hadir (2.2). Dari jumlah tersebut, hanya 1.0 dan 2.0 yang awalnya dimaksudkan sebagai LTS, tetapi karena sejumlah faktor (sebagian besar terkait dengan kami yang benar-benar baru dalam melakukan teknik dengan cara ini 😉) kami akhirnya menggunakan 1.0, 1.1 dan 2.1 sebagai kereta LTS. 2.0 dan 2.2 adalah (dulu, akan) rilis terkini. Pada tahap ini, 3.0 hampir pasti akan menjadi Arus juga (menyebabkan 2.2 memasuki periode "tenggang" 3 bulan saat ini) sebelum 3.1 menjadi LTS kereta 3.x. Harapan kami setelah itu, pola dan irama akan lebih konsisten (kami sangat menyukainya) tetapi sejauh ini bola kristal kami telah mengecewakan kami.

@DamianEdwards Terima kasih atas wawasannya! 😄 (Btw. Saya tidak mencoba untuk berdebat tentang ini, saya hanya ingin tahu;))

Masalah yang lebih besar bagi kami adalah REST API baru yang dihosting dalam proses oleh aplikasi lama yang sepertinya tidak akan pindah .NET Framework dalam waktu dekat. Setidaknya kita tahu untuk tidak berkembang melampaui pustaka pendukung .NET Standard 2 dan ASP.NET Core 2.1 sekarang! Ada baiknya periode LTS akan diperpanjang

Halo semuanya, pertanyaan singkat: Bagaimana dengan kita yang menggunakan paket asli dalam bentuk C ++ / CLI? Apakah itu akan didukung di .Net Core dalam waktu dekat, atau apakah kita menjadi yatim piatu kecuali kita melakukan pengerjaan ulang besar-besaran untuk menggunakan P / Invoke?

@lokitoth - itu akan menjadi pertanyaan bagus untuk orang-orang https://github.com/dotnet/core karena ini lebih umum daripada hanya ASP.NET Core.

@lokitoth ya, itu akan didukung, lihat https://github.com/dotnet/coreclr/issues/18013

oO Bagaimana saya melewatkan itu?

Oke, kalau begitu saya tidak punya masalah dengan ini.

@ danroth27 Dapatkah Anda memberi tahu kami dampak masalah ini untuk Client-Side-Blazor?

@Slebe Saya tidak mengharapkan dampak apa pun. Aplikasi Blazor sisi klien tidak bergantung pada runtime atau platform apa pun yang Anda putuskan untuk dijalankan di server.

@ danroth27 Dalam pemahaman saya, Client-side Blazor dapat berjalan di mono karena bergantung pada Microsoft.AspNetCore.* paket target standar bersih.
Apakah saya melewatkan sesuatu? Blazor harus tetap menargetkan Microsoft.AspNetCore.* 2.1.X?

@Slkebe Pustaka Blazor sisi klien hanya bergantung pada komponen yang akan terus menargetkan .NET Standard (seperti Microsoft.Extensions. * Dan teman-teman). Bagian sisi server Blazor yang bergantung pada ASP.NET Core akan menargetkan .NET Core seperti yang dijelaskan dalam masalah ini.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

Apa keputusannya sekarang? Target pada standar .net 2.1?

@ John0King Tidak ada keputusan baru.

Ini pisang! PISANG

Saya bersimpati pada sudut pandang Anda.

Mohon maaf jika ini telah diangkat, tetapi bagaimana dengan kasus penggunaan di mana saya hanya ingin menggunakan Kestrel + beberapa middleware sebagai bagian dari aplikasi non ASP.NET? Apakah saya harus menarik seluruh pohon 3.0 (yang tidak ideal, karena kasus penggunaan saya melibatkan penetapan SDK khusus untuk konsumen), atau apakah kasus penggunaan ini tidak didukung di 3.x?

Saat ini saya sedang mengembangkan aplikasi ASP.NET Core yang berjalan di .NET Framework, karena pustaka yang disertakan. Saya menggunakan ASP.NET Core karena kemampuan multi-authnya. Saya merasa dibodohi dan terkunci.

Saya menggunakan ASP.NET Core karena kemampuan multi-authnya.

@FlorianGrimm Apa secara spesifik? Microsoft.Owin menyediakan fungsionalitas autentikasi yang serupa untuk ASP.NET 4.

Ini adalah aplikasi hybrid satu kode sumber (.exe) yang berjalan di lokasi dan azure, saat ini menggunakan autentikasi windows, aad, autentikasi dasar, dan anonim.

@FlorianGrimm Dependensi perpustakaan mana yang mencegah Anda menggunakan .NET Core?

Microsoft.Office.Project.Schema, Microsoft.SqlServer.TransactSql.ScriptDom dan Microsoft.SharePointOnline.CSOM.

Saya berharap Tim SharePoint akan selesai
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/16585795-support-net-core-with-csom
dan saya menemukan opsi lain selain ilspy.

Saya suka ASP.NET Core dan saya berharap Tim Microsoft lainnya akan menyediakan lebih banyak rakitan .NET Core.

Kami secara berkala menutup masalah 'diskusi' yang belum diperbarui dalam jangka waktu yang lama.

Kami mohon maaf jika hal ini menyebabkan ketidaknyamanan. Kami meminta jika Anda masih mengalami masalah, harap catat masalah baru dengan informasi yang diperbarui dan kami akan menyelidikinya.