Aspnetcore: Paket ASP.NET Core 2.0 yang baru tidak lagi dapat digunakan di .NET Desktop

Ini akan menjadi perubahan yang sangat aneh dan buruk untuk dilakukan. Saya telah menulis banyak kode inti netfx-only asp.net dan tidak ingin melihat investasi itu sia-sia. Secara lebih umum, pelanggan .NET harus dapat interoperable antara ASP.NET Core dan kode Desktop di masa mendatang - bayangkan aplikasi web yang menggunakan Active Directory, atau otomatisasi Office COM, atau yang melakukan thumbnail menggunakan beberapa System.Drawing berbasis perpustakaan, atau berbagi kode dengan aplikasi WPF. Sangat sepele untuk memikirkan banyak skenario seperti ini dan saya harap kita hanya salah memahami apa yang sedang terjadi.

Saat ini kami menggunakan AspNetCore 1.1.1 - yaitu, cabang dukungan "saat ini". Jika kami tidak dapat pindah ke 2.0 karena ketergantungan pada Net4XX, apakah itu berarti kami tidak akan didukung saat 2.0+3bulan turun?

Kami menggunakan kombinasi WPF dan ASP.NET Core dan menargetkan dalam kedua kasus kerangka kerja penuh.
Jadi saya kira tidak ada 2.0 di masa mendatang?

Tetapi kerangka kerja penuh 4.6.1 akan mendukung standar bersih 2? apakah saya melewatkan sesuatu? (https://docs.microsoft.com/en-us/dotnet/articles/standard/library)

bukankah ini karena perkakas saat ini tidak diperbarui?

itu akan baik-baik saja dan diharapkan untuk melihat asp.net core berjalan pada standar net 2. hal yang mengkhawatirkan adalah prospek pindah ke net core app2.0, yang berarti tidak lagi dapat menggunakan kode lama di dalam asp.net situs web inti

oh, itu masalah .. Saya kira itu sedikit dikurangi oleh shims compat di netcore2 yang memungkinkan Anda untuk mereferensikan rakitan lama, tapi tetap saja, itu berarti mem-porting semua proyek ke sistem proyek baru dan banyak pekerjaan lain ..

Akan menyenangkan mendengar alasan tim tentang ini

oh, jadi menurut Anda proyek netcoreapp2.0 hanya dapat mereferensikan lib netfx berkat penyatuan tipe? itu akan menjelaskan banyak hal. pertanyaan saya, jika demikian, adalah berapa banyak kode yang benar-benar akan berfungsi ketika dijalankan di windows tetapi pada CLR inti..

Wow. Ini akan benar-benar memblokir bagi kami dan pada dasarnya memastikan kami tidak akan pernah dapat memperbarui paket-paket ini untuk masa mendatang yang jauh. Kami bahkan mungkin perlu memigrasikan proyek MvcCore kami kembali ke Mvc, karena saat ini kami tidak dapat menyiasati penargetan net462+.

Saya sangat ingin tahu tentang ini juga. Saya benar-benar berharap ini dalam langkah menengah (dan berumur pendek) atau miskomunikasi besar. Ini tentu akan menjadi penghambat adopsi untuk sebagian besar aplikasi kami juga.

Memindahkan semuanya ke Core terlalu banyak untuk basis kode besar yang ada (tanpa menghentikan dev untuk melakukannya), pindah ke Kelas ASP.NET baru (HttpRequest, pengontrol, dll.) sebagai langkah perantara harus terjadi untuk proyek utama kami.

Mungkin @DamianEdwards atau @davidfowl dapat mengomentari rencana di sini? Saya juga kesulitan menemukan alasan tambahan.

Saya dapat melihat mengapa ini awalnya merupakan momen WTF yang menakutkan. Mari saya jelaskan karena ini tidak seaneh kelihatannya.

• Anda mengatakan .NET pelanggan akan perlu untuk beroperasi. Setuju.
  
  
  
  • Kami dapat berbagi pustaka standar bersih antara ASP.NET Core 2.0 dan DI MANA SAJA.
  
  
  • Kami bahkan dapat mereferensikan banyak rakitan net461+ dari ASP.NET Core 2.0 karena penerusan jenis dan netstandard20
  
  
• Anda mengatakan WebApps mungkin perlu menggunakan:
  
  
  
  • AD – Benar-benar, ini adalah celah JIKA Anda ingin memanggil LDAP secara langsung. Anda pasti dapat mengautentikasi terhadap Windows Auth SEKARANG. Kami berencana untuk secara khusus memiliki namespace DirectoryServices untuk Core 2.0 sekitar jangka waktu musim panas
  
  
  • Menggambar – Benar-benar, ini adalah celah. Kami berencana untuk memiliki ini untuk Core 2.0 sekitar jangka waktu musim panas. Sampai saat ini, opsi standar bersih ini juga ada opsi ImageSharp, ImageResizer, Mono, dll
  
  
  • COM Automation – Ini tidak pernah mungkin dilakukan di bawah Core 2.0, tetapi Anda pasti dapat melakukan PIN jika Anda ingin melukai diri sendiri. Anda juga dapat melokalkan WebAPI ke proses net461+ jika Anda benar-benar ingin melukai diri sendiri.
  
  
  • Berbagi kode dengan Aplikasi WFP – YA. Sangat mungkin dengan netstandard2.0.
  
  
• Ini adalah perubahan yang aneh untuk dilakukan.
  
  
  
  • Rasanya seperti itu tapi…
  
  

Pikirkan seperti ini. WPF bukan netstandard2.0, ia tahu itu di net461+ dan tidak apa-apa. Ini dioptimalkan, tetapi dapat mereferensikan lib standar bersih. ASP.NET Core 2.0 dioptimalkan untuk Core 2.0 tetapi dapat mereferensikan pustaka bersama. Xamarin juga sama.

.NET Core berdampingan dan bergerak cepat. Ini JAUH lebih cepat daripada .NET (Full) Framework dapat bergerak yang bagus. Dengan membangun ASP.NET Core 2.0 di atas .NET Core 2.0 (yang, ingat, adalah SUPERSET dari .NET Standard) itu berarti barang dapat dibangun lebih cepat daripada NetFx atau bahkan Netstandard.

NetCore > Net Standard > NetFx dalam hal kecepatan pengembangan dan inovasi.

Intinya adalah, jika Anda melakukan pekerjaan baru, netstandard20. Jika Anda memiliki pustaka net461+ yang lebih lama, KEBANYAKAN di antaranya dapat dirujuk di bawah ASP.NET Core 2.0.

ASP.NET Core 1.1 yang berjalan di .NET Framework akan didukung penuh selama setahun setelah kami merilis 2.0. Beban kerja itu didukung penuh hingga setidaknya Juli 2018.

Kesenjangan besar yang tersisa yang hilang di .NET Core 2 adalah System.DirectoryServices dan System.Drawing. Kami sedang bekerja untuk memiliki paket kompat Windows yang akan mengaktifkan keduanya di .NET Core di Windows musim panas ini.

Apa yang kami butuhkan dari Anda semua adalah daftar/pemahaman yang jelas tentang MENGAPA Anda perlu ASP.NET Core 2.0 untuk berjalan di net461+.

Saya pikir .NET Standard 2.0 adalah semua tentang kompatibilitas dan interoperabilitas yang menjembatani kesenjangan antara .NET Core dan .NET fx yang semua orang tunggu - ini tampaknya membunuh itu.

Untuk alasan apa pun akan ada banyak pelanggan yang akan memiliki dependensi yang memerlukan .NET 4.x apakah itu dependensi eksternal kustom, komponen komersial, dependensi lib lama, dll.

Apakah ini dimaksudkan agar Pelanggan tidak dapat membuat aplikasi ASP.NET Core 2.0 yang berjalan di Desktop CLR sehingga mereka dapat mereferensikan deps .NET 4.x yang ada?

@shanselman Terima kasih atas jawabannya - banyak contoh bagus di sana.

Tindak lanjut tentang perpustakaan:
Akankah semua lib abstraksi tetap dikompilasi silang? Misalnya jika saya menggunakan HttpRequest , mempertahankan 1.x dan 2.x dibangun di atas versi ASP.NET Core yang Anda gunakan (yang sekarang dengan bersih memetakan ke TFM setidaknya) akan menjadi sesuatu Saya lebih suka menghindari...jadi saya berharap abstraksi akan tetap pada netstandard . Apakah itu rencana umumnya?

Kami telah mempertahankan beberapa varian untuk hal-hal yang bergantung pada ASP.NET/MVC karena System.Web 's HttpRequest benar-benar berbeda, jadi itu perpustakaan lain sepenuhnya (misalnya MiniProfiler vs . MiniProfiler.AspNetCore ). Saya hanya ingin memastikan bahwa kami mengingat jumlah varian yang kami muat untuk dipertahankan untuk setiap penulis lib jika dependensinya beralih dari netstandard ...dan semoga saja menghindari sakit kepala itu bersama-sama.

Saya sangat senang ini sepertinya bukan masalah besar seperti yang terlihat, terima kasih atas klarifikasi detailnya.

Saya punya dua pertanyaan/masalah:

• Kedengarannya seperti mengkonsumsi pustaka .NET Framework dari ASP.NET Core harus memiliki gesekan minimal. Itu keren! Bagaimana dengan sebaliknya? Mungkin ada .NET Framework atau pustaka dan aplikasi netstandard di luar sana yang menyematkan bagian atau komponen dari Mvc dan pustaka ASP.NET Core pendukung lainnya (saya tahu karena saya punya pasangan). Itu akan pecah, benar? Apakah ada tip untuk mengatasi skenario itu? Jika pustaka netstandard tidak dapat lagi menggunakan pustaka ASP.NET Core, itu sepertinya masalah besar untuk skenario ASP.NET Core yang disematkan.

• Dari perspektif non-teknis sepertinya ini akan menyebabkan banyak kebingungan. Di luar orang-orang yang aktif di GitHub, mengikuti di Twitter, dll. sudah ada banyak kebingungan seputar platform yang berbeda, dll. Saya dapat melihat pengembang yang hanya mengikuti sebagian atau yang baru saja bangun untuk mempercepat menjadi sangat frustrasi ketika mereka pergi menggunakan ASP.NET Core (mungkin mengikuti tutorial yang sudah ketinggalan zaman) dan tidak bisa membuatnya bekerja pada platform .NET Framework mereka. Tidak yakin apa, jika ada, yang bisa dilakukan tentang itu.

Kami bahkan dapat mereferensikan banyak rakitan net461+ dari ASP.NET Core 2.0 karena penerusan jenis dan netstandard20

Sayangnya, ini tidak berarti bahwa perpustakaan yang dikompilasi dan dirancang untuk kerangka kerja lengkap akan bekerja pada .NET Core (risikonya tinggi, hal-hal akan meledak saat runtime!).

Banyak dari API "lama" yang diperkenalkan kembali di .NET Core 2.0 adalah rintisan yang tidak akan pernah (secara fungsional) berfungsi. Belum lagi masih banyak API yang hilang, bahkan seluruh area yang sengaja dikeluarkan dari .NET Core (IdentityModel, server WCF, remoting, dukungan AppDomain lengkap, dll.)

Mencoba meyakinkan orang bahwa mereka dapat "dengan aman" memigrasikan aplikasi ASP.NET Core 1.0 w/ .NET Desktop ke ASP.NET Core 2.0 w/ .NET Core adalah - IMHO - bohong.

.NET Core berdampingan dan bergerak cepat. Ini JAUH lebih cepat daripada .NET (Full) Framework dapat bergerak yang bagus. Dengan membangun ASP.NET Core 2.0 di atas .NET Core 2.0 (yang, ingat, adalah SUPERSET dari .NET Standard) itu berarti barang dapat dibangun lebih cepat daripada NetFx atau bahkan Netstandard.

Saya tidak percaya itu yang (kebanyakan) orang cari. Banyak orang tidak membutuhkan perpustakaan yang bergerak cepat, mereka membutuhkan barang- barang stabil yang dapat diintegrasikan dengan baik ke dalam barang-barang lama mereka tanpa mengambil risiko merusak segalanya.

@daveaglick

• Benar karena tidak ada kemampuan implisit untuk mereferensikan netcoreapp2.0 dari net461 atau bahkan netstandard2.0 . Jembatan berjalan satu arah. Anda selalu dapat mengatasinya dengan menentukan TFM untuk fallback paket, tetapi itu jelas merupakan jalan keluar, bukan skenario yang didukung (walaupun itu akan cukup untuk membuka blokir banyak orang). Ini adalah pekerjaan yang tidak sepele bagi kami untuk mendukung sub-sistem ASP.NET Core di luar tumpukan yang lebih besar (yang disiratkan oleh penargetan netstandard ).
• Potensi kebingungan berjalan dua arah. Misalnya, kami mendapat banyak masukan bahwa fakta bahwa "ASP.NET Core" dapat berjalan di .NET Framework (yang bukan .NET Core) membingungkan. Perubahan ini secara efektif menjadikan ASP.NET Core bagian dari tumpukan .NET Core yang berarti jika Anda menggunakan ASP.NET Core, Anda menggunakan .NET Core.

@shanselman BTW, Anda tidak mengatakan mengapa kompilasi silang bukanlah pilihan. Komponen inti ASP.NET yang dapat mengambil manfaat dari netcoreapp2.0 -API hanya dapat memiliki net46 / netstandard1.x / netstandard2.0 dan netcoreapp2.0 TFM dan buat barang baru yang keren/cepat .NET Core-only.

@NickCraver saat ini rencananya tidak termasuk meninggalkan paket *.Abstractions yang menargetkan netstandard . Pemisahannya tidak sebersih itu di seluruh papan. Namun, untuk tujuan seseorang yang mencoba migrasi seperti yang Anda sarankan, menggunakan fallback target paket akan membawa Anda ke sana (tapi saya mungkin salah paham dengan Anda).

Juga maksud Anda tentang pemisahan TFM bersih benar, dan merupakan keuntungan dari rencana ini, dalam satu paket sekarang dapat menargetkan ASP.NET Core 1.x dan 2.0+ secara bersamaan menggunakan TFM sebagai poros.

Saya telah bermain-main dengan gagasan "aplikasi campuran". Misalnya aplikasi WPF mengekspos Web API atau Server yang menawarkan REST API dan titik akhir WCF (ini mungkin untuk kompatibilitas dengan klien sebelumnya). Skenario ini dibuat tidak mungkin dengan perubahan ini dan membuat ASP.NET Core hanya cocok untuk aplikasi baru daripada menjadi "hanya perpustakaan".

@PinpointTownes seperti yang dinyatakan @shanselman , kami sangat tertarik dengan persyaratan dan pemblokir khusus yang dimiliki pelanggan sehubungan dengan kebutuhan untuk terus menargetkan .NET Framework secara langsung. Pekerjaan kami dengan pelanggan di kapal ini sejauh ini telah menunjukkan bahwa System.DirectoryServices dan System.Drawing dan pemblokir No.1 dan 2 dan kami memiliki rencana untuk mengatasinya. Di luar itu, kami sedang melihat umpan balik dan kami akan menilai.

Cross-compiling merupakan overhead yang harus diimbangi dengan kebutuhan pelanggan dan produk. Inilah sebabnya mengapa kami ingin mendapatkan umpan balik ini sehingga kami dapat lebih konkret mendefinisikan seperti apa lanskap bagi pelanggan kami dan kami saat kami terus mengembangkan ASP.NET Core bergerak maju.

@DamianEdwards Terima kasih atas klarifikasi lebih lanjut. Pustaka netstandard -> ASP.NET Core adalah masalah besar bagi saya. Saya menyematkan Kestrel (yang juga terlihat akan pindah ke netcoreapp) di beberapa pustaka standar net. Saya juga menyematkan Razor di beberapa tempat, dan saya tahu Anda sedang mengerjakan versi baru yang lebih modular, tetapi jika itu hanya menargetkan netcoreapp juga, itu akan merugikan. Ada juga banyak perpustakaan yang merupakan "bagian" dari ASP.NET Core tetapi memiliki banyak utilitas di luarnya.

Dengan kata lain, saya jauh lebih peduli tentang menghapus kemampuan perpustakaan standar bersih untuk menggunakan paket ASP.NET Core daripada sebaliknya. Sepertinya ini menghapus seluruh kelas kasus penggunaan dari pertimbangan.

@daveaglick Razor sendiri (mesin) akan terus menargetkan netstandard . Sekali lagi, ada biaya yang terlibat dalam mendukung sub-sistem tertentu dari grafik kompleks yang besar (seperti ASP.NET Core 2.0) pada platform yang berbeda. Untuk hal-hal seperti penyematan ada opsi lain (penyematan sumber, penyalinan, dll.) tetapi tentu saja mereka datang dengan trade-off mereka sendiri.

Pasti mendengar Anda di depan kelas kasus penggunaan yang berbeda, kami memang memiliki kelompok pelanggan yang berbeda untuk dipertimbangkan saat merancang dan mengirimkan tumpukan seperti milik kami.

Saya membagikan kekhawatiran @daveaglick di sini: ASP.NET Core yang ingin menggunakan API terbaru benar-benar dapat dimengerti, tetapi untuk semua hal lain di hilir yang memerlukan hal yang sama menjadi sedikit lebih berantakan. Anda tidak mendapatkan pilihan apa pun setelah 1.0 stabil atau meningkatkan, Anda berada di kereta tercepat yang tersedia dengan netcoreapp2.0 dan itulah satu-satunya pilihan. Jika semua bit (bahkan abstraksi dasar) tidak dapat dikonsumsi tanpa membuat pengguna mengkonsumsi netcoreapp2.0 , itu berarti secara efektif tidak ada netstandard2.0 untuk seluruh baris perpustakaan itu... itu tergantung pada mereka.

Saya membuat tumpukan aplikasi inti bergerak, tetapi saya tidak selalu setuju dengan abstraksi khususnya yang bergerak. Salah satu poin utama dari abstraksi adalah untuk menghindari kopling ketat seperti ini, setidaknya dari pandangan saya sebagai konsumen. Saya akan sangat penasaran untuk melihat beberapa contoh di mana netstandard2.0 tidak memiliki API yang diperlukan untuk mereka tetapi netcoreapp2.0 memiliki - apakah ada beberapa contoh di luar sana? Apakah ini terutama di sekitar tipe baru dalam parameter metode? Saya tidak ragu ada banyak alasan, saya hanya sangat ingin tahu - melihat contoh akan membantu menunjukkan biaya pemeliharaan yang kami tidak memiliki wawasan harian yang hampir sama.

Kasing Kestrel lebih rumit, tetapi saya tentu melihat argumen untuk memilikinya di set API terbaru. Saya membayangkan API baru akan terus dibuat untuk Kestrel mengingat pekerjaan yang dijalankannya.

@PinpointTownes seperti yang dinyatakan @shanselman , kami sangat tertarik dengan persyaratan dan pemblokir khusus yang dimiliki pelanggan sehubungan dengan kebutuhan untuk terus menargetkan .NET Framework secara langsung.

Sebagai konsultan, saya membantu banyak klien memindahkan aplikasi mereka ke ASP.NET Core dan saya sering harus menargetkan .NET Desktop untuk dapat menggunakan perpustakaan pihak ketiga (sumber tertutup) tergantung pada IdentityModel / WCF atau mengandalkan AppDomain mendukung.

Tidak memiliki hal-hal ini di ASP.NET Core 2.0 akan menjadi penghalang utama bagi mereka.

Ada juga perpustakaan yang tidak akan bekerja pada .NET Core bahkan jika API ada di sana, karena mereka akan berbeda secara fungsional. Inilah kasus konkret yang sering saya lihat:

Pada .NET Core, RSA.Create() mengembalikan instance RSACng di Windows, tetapi pada .NET Desktop, instance RSACryptoServiceProvider dikembalikan. Namun, banyak perpustakaan - termasuk BLC itu sendiri - mencoba mentransmisikan RSA ke RSACryptoServiceProvider , yang akan selalu gagal pada .NET Core, karena RSACng tidak dapat ditransmisikan ke RSACryptoServiceProvider .

@NickCraver abstraksi mana yang khusus? Masalah dengan hanya memindahkan abstraksi adalah bahwa selanjutnya Anda akan berakhir menginginkan semua yang dibangun di atas abstraksi itu juga (kecuali jika Anda benar-benar mengatakan bahwa Anda hanya membutuhkan Microsoft.AspNetCore.Http.Abstractions dan tidak ada yang lain)

@davidfowl Ya, hanya abstraksi: misalnya HTTP, Hosting, HTML, dan Logging. Sepertinya Microsoft.Extensions.* dicakup oleh komentar sebelumnya, yang sebagian besar dari ini. Mereka adalah orang-orang yang saya berinteraksi dengan hari ini.

Sebagai contoh konkret: MiniProfiler Middleware tidak membalas apa pun kecuali abstraksi ( tautan )

Jika Anda menggunakan MVC dan semacamnya di atas, maka Anda tetap menggunakan netcoreapp2.0 , dan memang begitu (dan IMO, tidak apa-apa). Tetapi saat ini saya memiliki kebebasan untuk membagi API secara logis di mana dibagikan dan melakukannya dengan mudah karena itu adalah abstraksi. Saya sangat penggemar perpecahan saat ini, tolong jangan menguncinya jika tidak perlu.

Heh. Sebagai konsultan, saya pasti pernah mendengar pertanyaan "What? ASP.NET Core berjalan di desktop .NET Framework!?" pertanyaan beberapa kali. Fakta bahwa "ASP.NET Core" secara harfiah memiliki ".NET Core" dalam namanya sangat disayangkan.

Bagaimanapun ... Sama seperti saya adalah penggemar menjatuhkan API usang/warisan/rusak ketika .NET Core dimulai (awal "baru"), saya juga penggemar perubahan ini untuk mendapatkan kerangka kerja yang lebih cepat dan lebih ramping dengan lebih banyak fitur dan tingkat inovasi yang lebih tinggi.

Dengan itu, saya juga bersimpati kepada semua pengembang di luar sana yang karena alasan tertentu tidak dapat memigrasikan semua kode mereka ke .NET Core sebelum Juni tahun depan.

Ini termasuk klien saya saat ini, yang memiliki perpustakaan/kerangka warisan yang sangat besar, menargetkan .NET Framework, dikonsumsi oleh beberapa proyek ASP.NET Core yang saat ini sedang dikembangkan secara paralel. Pada saat sistem ini mulai diproduksi, akan ada sedikit atau tidak ada waktu untuk a) mem-port semuanya ke .NET Core, atau b) memindahkan semuanya ke kerangka kerja penuh ASP.NET, sebelum ASP.NET Core 1.x tidak didukung.

Apakah satu tahun dukungan benar-benar cukup di sini? Saya bisa membayangkan ada kasus serupa lainnya di luar sana ...

@khellang seperti yang dinyatakan sebelumnya, mereka akan dapat melanjutkan referensi perpustakaan/kerangka kerja yang menargetkan .NET Framework, dan itu akan berfungsi dengan baik dengan asumsi API yang mereka panggil adalah bagian dari penutupan netstandard2.0 . Apakah Anda tahu jika mereka mengandalkan hal-hal di luar ruang itu? Itulah yang sangat ingin kami dapatkan umpan baliknya sehingga kami dapat menilai prioritas porting API tersebut (seperti System.DirectoryServices dan System.Drawing ).

Jadi meng-hosting api web (misalnya lapisan komunikasi) atau bahkan soket inti asp.net yang akan datang akan menjadi tidak mungkin untuk layanan windows saat ini atau aplikasi desktop WPF? (dengan versi yang didukung).

Saya membayangkan akan ada daftar yang akan datang dari hal-hal yang dulunya netstandard1.x yang sekarang menjadi netcoreapp2.0

Saya telah menelusuri repo dan tampaknya hal-hal khusus MVC adalah netcoreapp2.0 tetapi HttpAbstractions, Logging, Configuration, dll masih netstandard Atau ada lebih banyak perubahan yang akan datang?

@NickCraver Saya melihat Anda menggunakan Ekstensi tetapi masih menggunakan System.Web. Apakah Anda memiliki rencana untuk menipu Microsoft.AspNetCore.Http.HttpContext dengan System.Web.HttpContext ? Apakah Anda tahu berapa banyak API yang Anda butuhkan?

Jika Anda menggunakan MVC dan semacamnya di atas, maka Anda tetap menggunakan netcoreapp2.0, dan memang begitu (dan IMO, tidak apa-apa). Tetapi saat ini saya memiliki kebebasan untuk membagi API secara logis di mana dibagikan dan melakukannya dengan mudah karena itu adalah abstraksi. Saya sangat penggemar perpecahan saat ini, tolong jangan menguncinya jika tidak perlu.

Saya tidak berbicara tentang MVC, saya hanya berbicara tentang pembantu lain yang mengekspos lebih banyak fungsionalitas di atas abstraksi yang mendasarinya. Nilai besar dari pola "abstraksi" yang kami pilih adalah bahwa hal-hal lain dapat dibangun di atasnya, bukan abstraksi itu sendiri. Nyali saya memberi tahu saya bahwa jika kita membuat abstraksi ASP.NET menjadi standar net maka kita akhirnya harus membuat semua netstandard middleware juga.

Layanan windows @dasMulli akan berfungsi setelah kami memiliki porting API (ada juga perpustakaan sumber terbuka yang mendukung layanan windows di .NET Core).

Aplikasi desktop WPF? (dengan versi yang didukung).

Ya. Ini tidak akan menjadi default lagi. Kami tidak akan mendukungnya lagi dengan .NET Core 2.0.

@davidfowl Saya tidak yakin Anda melihat bagian yang tepat di sana:

tetapi masih menggunakan System.Web

...tidak di perpustakaan yang sama, karena pemisahan ini. Untuk mencapai overhead minimal dan bukan beban truk ketergantungan bagi konsumen, ada MiniProfiler untuk ASP.NET MVC < 6 (System.Web) dan MiniProfiler.AspNetCore / MiniProfiler.AspNetCore.Mvc (banyak NuGet ).

Saya pikir Anda sedang berbicara tentang sisa System.Web yang ada di MiniProfiler.Shared - Saya menunggu untuk membersihkannya sampai masalah NuGet diperbaiki tadi malam di rakitan kerangka kerja. Saya baru saja menghapusnya untuk membersihkan semuanya.

@DamianEdwards Saya tidak 100% pada penutupan netstandard2.0 , tetapi saya akan dengan senang hati (dengan izin mereka) menjalankan penganalisis portabilitas dan membagikan hasilnya. Apakah penganalisa portabilitas masih ada dan mutakhir?

ASP.Net Core dengan cepat menjadi Python 3* baru; hanya lebih buruk. Ini sepertinya langkah ke arah yang salah bagi saya. Ini berarti banyak skenario akan memaksa pengembang untuk mempertahankan (dan menulis kode baru) pada "platform lama" selama bertahun-tahun yang akan datang alih-alih pindah. "Perkembangan lebih cepat" sepertinya bukan argumen yang bagus jika semua itu berarti Anda sampai ke tempat yang lebih buruk/tidak cocok "Lebih cepat".

*Saya suka Python 3, tapi sudah hampir satu dekade dan komunitas Python masih retak

Untuk memperjelas - apakah ada pemblokir teknis (hal-hal perf mewah) atau apakah ini hanya untuk menghemat biaya pemeliharaan kompatibilitas di masa mendatang?
Saya pikir sebagian besar dari kita tahu langkah ini akan datang tetapi tidak ada yang mengharapkannya begitu cepat .. mengingat waktu transisi masih berlangsung (seperti lib sedang di-porting, standar .net 2.0 di tikungan tetapi belum ada lib yang dibangun untuk itu) - akan lebih baik jika tetap mendukung net* untuk setidaknya satu rilis (mis. 2.0, bukan 2.1).

@shanselman Saya melihat poin Anda dan saya pribadi bahkan setuju, tetapi _banyak_ orang tidak akan melihatnya seperti itu.

Masalah utama adalah tidak memanggil rakitan net46 dari inti, shims compat berurusan dengan itu dalam banyak kasus. Masalahnya adalah kode net46 yang ada dan kode asp.net core 1.* berjalan pada 46. Seperti yang disebutkan seseorang, inti dari netstandard adalah untuk memungkinkan kode, termasuk asp.net, berjalan di mana-mana, ini akan terasa seperti sebuah langkah jauh dari itu dan mungkin bahkan kegagalan visi itu untuk beberapa orang.

Saya tidak berpikir masalahnya adalah orang tidak _ingin_ pindah ke inti bersih. Masalahnya adalah bahwa organisasi, manajer, CTO dan sejenisnya harus diyakinkan bahwa biaya/manfaat melakukannya sepadan. Porting tidak hanya memakan waktu yang cukup untuk memakan waktu pengiriman, tetapi juga menimbulkan risiko regresi, dll.

dengan kata lain, tidak selalu alasan teknis yang mencegah orang bergerak. Saya bahkan akan mengatakan itu langka, _secara teknis_ hampir semua proyek dapat membuat lompatan. Tetapi memotivasi slip biaya/pengiriman itu, itulah masalahnya. Ini bisa menjadi penjualan yang sangat sulit, yang harus saya lakukan beberapa kali. Dalam kasus-kasus itu, dapat mengatakan, "tetapi Anda dapat berjalan pada kerangka kerja penuh" telah menjadi cara untuk mendorong langkah itu

Jika kamu ingin menyakiti dirimu sendiri

Ini adalah persis itu. Pengembang dan manajemen Net46 tidak akan melihatnya seperti itu, mereka akan melihatnya sebagai _you_, microsoft, ingin menyakiti mereka untuk mengikuti rilis terbaru. "Yah, jangan bergerak kalau begitu" bisa dikatakan tetapi dengan dukungan asp.net core 1.x sesingkat itu, mereka agak harus, setidaknya dari perspektif manajer yang harus bertanggung jawab jika a bug menyebabkan downtime atau kehilangan informasi. (bahkan jika kerangka kerja tidak bertanggung jawab)

Banyak pengembang yang benar-benar mendorong asp.net core 1.1 juga akan merasa dikhianati bahwa mereka sekarang tidak akan dapat pindah ke 2.0 tanpa core. Itu mungkin dibenarkan atau tidak, tetapi saya hanya memberi tahu Anda, banyak orang akan merasa seperti itu, merekalah yang harus menjawab rekan-rekan mereka yang lebih konservatif

Apakah semua itu penting? Akankah asp.net core2/dotnet core2 "mati" karena ini? Tidak, tapi itu akan memperlambat adopsi dan merusak ekosistem dan itu sangat menyedihkan. Saya ingin orang-orang dapat menggunakan semua hal hebat yang hadir dalam 2.0 ini dan memotong kompilasi silang ke standar bersih akan berdampak pada itu. Tentu saja, kebanyakan orang yang nongkrong di repo ini tidak akan memiliki masalah, Joe dan Jane dev dan terlebih lagi, manajer mereka itulah masalahnya.

@DamianEdwards
Saya setuju bahwa ini telah menjadi sumber kebingungan, saya harus menjelaskannya berkali-kali, tetapi hasilnya selalu mengubah pengembang yang kecewa menjadi pengembang yang bersemangat karena mereka pikir mereka tidak dapat menggunakan hal-hal baru yang keren tapi ternyata bisa.

Untuk musim panas, saya yakin keputusan ini tidak dibuat dengan mudah tetapi jika Anda harus melakukan ini, saya pikir Anda harus benar-benar _sangat_ berhati-hati dengan pesannya.. Anda harus menunjukkan bahwa bermigrasi ke asp.net core, terutama dari 1. x di net46 _super_ sederhana dan sangat halus. Kisah untuk mereferensikan pustaka standar net lain dari net46 baik sebagai referensi proyek maupun sebaliknya harus solid. Saya pikir Anda perlu menunjukkan/mengatasi ini secara eksplisit untuk menghindari orang-orang ketakutan

@khellang paging @terrajobst untuk pertanyaan Portability Analyzer.

@khellang

Ya, kami baru saja memperbarui VSIX untuk 2017, tetapi saya hanya menggunakan versi baris perintah dari sini .

@NickCraver Tentu, Anda dapat menulis sepotong middleware yang menargetkan netstandard, apa gunanya bagi Anda sebagai penulis perpustakaan jika ASP.NET Core mendukung netcoreapp2.0.

@aL3891 ringkasan yang bagus! Satu masalah besar yang kami miliki ke depan adalah bagaimana kami memanfaatkan API baru untuk hal-hal yang juga dalam standar bersih. .NET Core akan mendapatkan API baru yang kita perlukan untuk mengimplementasikan fitur baru (salah satu yang terlintas dalam pikiran adalah dukungan SSLStream ALPN untuk dukungan HTTP2 di Kestrel). Jadi Anda dapat berargumen bahwa kami tetap menggunakan standar net dan terus-menerus menggunakan versi tertinggi (yang belum didukung oleh .NET Framework) tetapi kemudian kami akan berada di kapal yang sama.

Satu masalah besar yang kami miliki ke depan adalah bagaimana kami memanfaatkan API baru untuk hal-hal yang juga dalam standar bersih. .NET Core akan mendapatkan API baru yang kita perlukan untuk mengimplementasikan fitur baru (salah satu yang terlintas dalam pikiran adalah dukungan SSLStream ALPN untuk dukungan HTTP2 di Kestrel).

Menurut https://github.com/dotnet/corefx/issues/4721 , dukungan ALPN untuk SslStream tidak akan siap untuk .NET Core 2.0. Dengan asumsi ini akhirnya diterapkan beberapa bulan kemudian, apakah itu berarti bahwa seseorang akan dapat menggunakannya ketika menargetkan netcoreapp2.0 TFM? Dalam hal ini, apa yang akan terjadi jika saya memutuskan untuk merilis perpustakaan berbasis netcoreapp2.0 yang menggunakan API baru yang bukan merupakan bagian dari bentuk netcoreapp2.0 awal jika pengguna saya menggunakan runtime .NET Core yang lebih lama ? Apakah itu akan crash? Atau akankah netcoreapp2.x disejajarkan dengan netstandard1.x , yang kontraknya tidak dapat diubah tanpa meningkatkan versi TFM?

@davidfowl untuk implementasi lain dari setiap bagian dari tumpukan dan pengujian. Dan karena dengan cara abstraksi (tidak memerlukan MVC) sebagai pemisahan yang layak antara 2 perpustakaan alih-alih "anggap semua orang memiliki MVC dan menginginkan semua dependensi".

Jika abstraksi sebenarnya bukan abstraksi dan sangat erat digabungkan dengan ASP.NET Core itu sendiri, mengapa kita tidak menghapus paket-paket itu saja? Ini pertanyaan yang jujur, karena itu akan membuat hidup lebih mudah dan lebih jelas jika itu tujuan hubungan secara keseluruhan. Saya mencoba memahami gunanya memiliki abstraksi sebagai paket terpisah jika mereka secara efektif terikat pada implementasi/penggunaan sederhana. Saya berpendapat bahwa tidak ada orang di luar Microsoft yang ingin atau memiliki sumber daya untuk didedikasikan ke server web netcoreapp2.x yang bersaing (senang diperbaiki di sana!).

Bisakah Anda mengklarifikasi apa gunanya abstraksi di dunia netcoreapp2.x ? Atau jika ada rencana untuk menghentikannya di 2.0?

Menurut dotnet/corefx#4721, dukungan ALPN untuk SslStream tidak akan siap untuk .NET Core 2.0. Dengan asumsi ini akhirnya diterapkan beberapa bulan kemudian, apakah itu berarti bahwa seseorang akan dapat menggunakannya saat menargetkan netcoreapp2.0 TFM? Dalam hal ini, apa yang akan terjadi jika saya memutuskan untuk merilis pustaka berbasis netcoreapp2.0 yang menggunakan API baru yang bukan merupakan bagian dari bentuk awal netcoreapp2.0 jika pengguna saya menggunakan runtime .NET Core yang lebih lama? Apakah itu akan crash? Atau akankah netcoreapp2.x disejajarkan dengan netstandard1.x, yang kontraknya tidak dapat diubah tanpa meningkatkan versi TFM?

ASP.NET versi x hanya akan menyelaraskan ke .NET Core versi x. TFM akan diperbarui agar selaras dengan setiap rilis .NET Core. Ini adalah produk tunggal yang akhirnya dapat diperlakukan seperti itu. Itu salah satu penyederhanaan utama yang kami lakukan seperti yang disebutkan @DamianEdwards di atas. Kami tidak akan merusak orang yang membangun perpustakaan dengan menambahkan API baru di inti tanpa mengubah TFM.

@NickCraver

untuk implementasi lain dari setiap bagian dari tumpukan dan pengujian.

Apa implementasi lainnya? Apakah ada bagian lain dari tumpukan yang mengimplementasikan ASP.NET Core.

Jika abstraksi sebenarnya bukan abstraksi dan sangat erat digabungkan dengan ASP.NET Core itu sendiri, mengapa kita tidak menghapus paket-paket itu saja? Ini pertanyaan yang jujur, karena itu akan membuat hidup lebih mudah dan lebih jelas jika itu tujuan hubungan secara keseluruhan. Saya mencoba memahami gunanya memiliki abstraksi sebagai paket terpisah jika mereka secara efektif terikat pada implementasi/penggunaan sederhana. Saya berpendapat bahwa tidak ada seorang pun di luar Microsoft yang ingin atau memiliki sumber daya untuk didedikasikan ke server web netcoreapp2.x yang bersaing (senang diperbaiki di sana!).

Bisakah Anda mengklarifikasi apa gunanya abstraksi di dunia netcoreapp2.x? Atau jika ada rencana untuk menghentikannya di 2.0?

Kami dapat memasukkan semuanya ke dalam satu perakitan tetapi refactoring memungkinkan kami fleksibilitas di masa depan yang tidak akan kami miliki jika kami melakukan ini. Bahkan membuka kemungkinan untuk memiliki implementasi lain dan tidak benar-benar menghalanginya dalam jangka panjang.

Sederhananya, abstraksi adalah tentang menurunkan jumlah dependensi, bukan tentang portabilitas platform.

Kami tidak akan merusak orang yang membangun perpustakaan dengan menambahkan API baru di inti tanpa mengubah TFM.

Kalian mengatakan bahwa Anda ingin memilih netcoreapp2.0 -hanya karena bergerak lebih cepat - dibandingkan dengan .NET Desktop dan dengan ekstensi, .NET Standard - tetapi apa gunanya menargetkan netcoreapp2.0 alih-alih netstandard2.0 jika Anda tidak dapat memanfaatkan .NET Core API baru tanpa mengubah TFM? (misalnya netcoreapp2.1 )

Kalian mengatakan bahwa Anda ingin memilih hanya netcoreapp2.0 karena bergerak lebih cepat - dibandingkan dengan .NET Desktop dan dengan ekstensi, .NET Standard - tetapi apa gunanya menargetkan netcoreapp2.0 daripada netstandard2.0 jika Anda bisa Tidak mendapat manfaat dari .NET Core API baru tanpa mengubah TFM? (misalnya netcoreapp2.1)

Maaf, saya salah bicara, maksud saya netcoreapp2.x bukan netcoreapp2.0 .

Oke, aku benar-benar bingung, sekarang.

Maaf, saya salah bicara, maksud saya netcoreapp2.x bukan netcoreapp2.0.

Saya tidak yakin saya mengerti. Apakah maksud Anda akan ada kesetaraan antara paket ASP.NET Core 2.1 dan netcoreapp2.1 TFM?

Apakah maksud Anda akan ada kesetaraan antara paket ASP.NET Core 2.1 dan netcoreapp2.1 TFM?

Ya. Pikirkan 2 sebagai satu dalam hal yang sama. Lihat https://github.com/aspnet/Home/issues/2022#issuecomment -299544884

Jadi apa yang mencegah Anda mengadopsi pola serupa, tetapi dengan netstandard ? Ini akan menjadi pendekatan terbaik, IMHO: API baru dapat diadopsi melalui TFM baru dan orang-orang yang perlu mendukung .NET Desktop masih dapat menjalankan aplikasi ASP.NET Core mereka pada kerangka kerja penuh.

ASP.NET Core 2.1/.NET Core 2.1/.NET Desktop 4.7.1 -> netstandard2.1
ASP.NET Core 2.2/.NET Core 2.2/.NET Desktop 4.8 -> netstandard2.2 .

@PinpointTownes karena .NET Framework di desktop tidak dapat dikirimkan dengan cukup cepat, itulah inti dari sebagian besar masalah versi dengan Core. Ini adalah masalah yang sulit dalam rantai yang sangat besar.

.NET Standard tidak akan bergerak dengan kecepatan yang sama dengan .NET Core. Tidak ada tempat di dekat itu dalam kenyataannya. Pergerakan di .NET Standard pada dasarnya meninggalkan semua platform, sampai mereka mengejar, dan .NET Framework adalah yang paling lambat bergerak dan terbesar.

Token poin, 'Saya tidak yakin seberapa cepat .NET Framework seharusnya dikirimkan (misalnya API ECDSA baru di-porting dari CoreFX ke NetFX dalam waktu kurang dari setahun, yang tampaknya merupakan kerangka waktu yang masuk akal untuk komponen kripto yang sensitif seperti itu) ).

Cross-compiling merupakan overhead yang harus diimbangi dengan kebutuhan pelanggan dan produk.

Jika Anda punya waktu sebentar, saya ingin tahu lebih banyak tentang sifat pasti dari overhead yang disebabkan oleh kompilasi silang. Terima kasih.

Apa yang kami butuhkan dari Anda semua adalah daftar/pemahaman yang jelas tentang MENGAPA Anda perlu ASP.NET Core 2.0 untuk berjalan di net461+. Jadilah spesifik sehingga kami dapat menutup celah itu dan membiarkan semua orang sukses.

Saat ini, kami membutuhkan versi fullframework dari pustaka klien WCF - karena versi netstandard / netcore (https://github.com/dotnet/wcf) belum selesai.

Jika Anda punya waktu sebentar, saya ingin tahu lebih banyak tentang sifat pasti dari overhead yang disebabkan oleh kompilasi silang. Terima kasih.

Akan ada waktu dalam waktu dekat di mana kami benar-benar tidak dapat melakukan polyfill fitur seperti dukungan ALPN untuk SSLStream. Juga kami bahkan belum mulai meregangkan kaki kami dan menambahkan API ke .NET Core, sejauh ini kami telah macet dengan porting kembali ke .NET Standard dan .NET Core 2.0 (seluruh tujuan .NET Standard 2.0) . Kami akan menambahkan API baru dan akhirnya menggunakannya di ASP.NET Core pada hari pertama.

Saat ini, kami membutuhkan versi fullframework dari library klien WCF - karena versi netstandard / netcore (https://github.com/dotnet/wcf) belum selesai.

@ctolkien Itu masalah dan itulah alasan kami mem-porting klien WCF di tempat pertama. Apakah Anda tahu apa yang menghalangi Anda? Ini adalah kesempatan yang baik untuk membantu kami memprioritaskan.

@davidfowl https://github.com/dotnet/wcf/issues/8

Mungkin ada lebih banyak lagi, ini hanyalah rintangan pertama yang kami hadapi sebelum beralih ke wcf kerangka kerja penuh.

Akan ada waktu dalam waktu dekat di mana kami benar-benar tidak dapat melakukan polyfill fitur seperti dukungan ALPN untuk SSLStream.

Bagaimana itu masalah? AFAICT, tidak ada yang pernah mengatakan bahwa rasa .NET Desktop dan .NET Core dari ASP.NET Core harus mendukung set fitur yang sama persis. Jika fitur tidak tersedia di .NET Desktop karena kehilangan API (mis. HTTP 2/0), mengapa tidak menjadikannya .NET Core-only dan melemparkan PlatformNotSupportedException memberi tahu pengembang bahwa fitur yang dia cari adalah tidak tersedia?
Ini akan jauh lebih baik daripada membuat semua paket ASP.NET Core .NET Core saja, meskipun kebanyakan dari mereka tidak akan mungkin menggunakan API BCL baru.

@davidfowl Saya kira satu ketakutan utama adalah bahwa hal-hal tidak diperbaiki katakanlah netcoreapp2.3 , itu diperbaiki dalam netcoreapp2.4 . Jika ASP.NET Core difokuskan pada kereta tercepat, berapa lama dengan setiap versi minor mendapatkan cinta? Jika kita harus terus mengupgrade, maka setiap konsumen harus terus mengupgrade.

Itu bagus untuk mendapatkan yang terbaru dan terhebat, tetapi itu bukan yang terbaik untuk sebagian besar perusahaan. Jadi kami harus memelihara banyak versi (setiap versi minor) dengan perpustakaan kami untuk setiap konsumen ASP.NET Core (agar tidak bergantung pada yang terbaru dan mengikuti perkembangan), atau menyeret pengguna ke versi terbaru untuk mengikuti. Ini tidak ramah untuk hal-hal seperti lingkungan yang divalidasi.

Kecuali jika abstraksi perlu diputar secepat (contoh?), Memutuskannya akan lebih disukai. Dengan begitu Anda tidak menyeret seluruh ekosistem bersama dengan setiap peningkatan. Saya kira saya lebih khawatir bukan karena mereka akan berada di netcoreapp , tetapi mereka akan terus diperbarui dan semuanya digabungkan dengan erat.

Jika abstraksi akan mempertahankan setiap versi minor dan menggeser rasa sakit (terus terang) ke pihak Anda, saya jauh lebih tidak khawatir. Bisakah kalian menguraikan niat dengan revisi di sini?

@PinpointTownes :

mengapa tidak membuatnya .NET Core-only dan melemparkan PlatformNotSupportedException yang memberi tahu pengembang bahwa fitur yang dia cari tidak tersedia?
Ini akan jauh lebih baik daripada membuat semua paket ASP.NET Core .NET Core saja, meskipun kebanyakan dari mereka tidak akan mungkin menggunakan API BCL baru.

Tidak, tolong jangan. Itu kegagalan runtime dan perilaku yang sangat tidak diinginkan. Kami ingin memiliki sebanyak mungkin jaminan waktu kompilasi bahwa perpustakaan kami akan berfungsi sebaik mungkin. Ada banyak perdebatan tentang ini, itu bukan jalan yang baik. PlatformNotSupported harus dihindari sebisa mungkin secara manusiawi.

Itu kegagalan runtime dan perilaku yang sangat tidak diinginkan.

Inilah yang akan terjadi dengan pendekatan "bawa rakitan .NET Desktop Anda ke .NET Core" jika rakitan Anda mencoba menggunakan API yang tidak didukung, kecuali Anda akan mendapatkan MissingMemberException alih-alih PlatformNotSupportedException .

Dengan pendekatan saya, Anda setidaknya dapat mendefinisikan cerita perkakas yang lebih baik dengan hal-hal seperti penganalisis Roslyn yang dapat menentukan pada waktu kompilasi apakah API yang Anda gunakan didukung atau tidak.

Dan BTW, melempar PlatformNotSupported akan benar-benar menjadi kasus sudut. Dengan kompilasi silang, opsi terbaik adalah dengan mengecualikan API yang tidak didukung dari kontrak publik.

@PinpointTownes Saya juga berpikir seperti ini, tetapi kenyataannya adalah platform baru dikirimkan dan tidak sesederhana itu. Setelah membahas ini berkali-kali, pikiran saya berubah banyak tentang bagaimana melakukan compat di sini. Mengikuti arah netcoreapp memungkinkan perbaikan dikirimkan dalam versi minor. Pergi ke arah lain berarti Anda harus menunggu di .NET Desktop untuk mengirimkan perbaikan, yang...semoga berhasil. Itu kendaraan yang sangat lambat untuk resolusi.

AFAICT, tidak ada yang pernah mengatakan bahwa rasa .NET Desktop dan .NET Core dari ASP.NET Core harus mendukung set fitur yang sama persis. Jika fitur tidak tersedia di .NET Desktop karena kehilangan API (mis. HTTP 2/0), mengapa tidak menjadikannya .NET Core-only

Paruh pertama adalah netstandard . Membedakan ke netcoreapp adalah persis apa yang mereka lakukan di sini. Tanpa pengecualian yang disengaja. Ini adalah kontrak yang tepat untuk rute ini.

Anda ingin pergi ke arah hal yang dapat diperbaiki dan ditingkatkan lebih cepat ketika kesenjangan terlibat, bukan sebaliknya. Pengecualian "PlatformNotSupported" dapat diperbaiki di perpustakaan besok, alih-alih menunggu platform berputar 3 bulan dari sekarang. .NET Core dapat mendukungnya lebih cepat karena kode yang sebenarnya dikirimkan bersamanya , tidak secara terpisah sebagai penerus sebagian besar waktu.

[@PinpointTownes] Jika fitur tidak tersedia di .NET Desktop karena kehilangan API (mis. HTTP 2/0), mengapa tidak menjadikannya .NET Core-only dan melemparkan PlatformNotSupportedException memberi tahu pengembang bahwa fitur tersebut dia cari tidak tersedia?

Kita perlu menyeimbangkan kesederhanaan di permukaan & jangkauan API dengan produktivitas pengembang. Sejauh ini, kami terutama menggunakan PlatformNotSupportedException untuk menghadirkan permukaan API yang kompatibel dengan masa lalu. Kami tidak bermaksud untuk menggunakan PlatformNotSupportedException sebagai cara untuk memberikan rangkaian fitur yang terpisah-pisah ke depan. Sebagai gantinya, kami akan menghentikan dukungan untuk versi platform .NET yang tidak memiliki fitur tersebut atau memberikan fitur tersebut sebagai paket NuGet independen yang tidak didukung di semua tempat.

Mengikuti arah netcoreapp memungkinkan perbaikan dikirimkan dalam versi minor.

Apa bedanya dengan pendekatan 1.0? @davidfowl mengatakan bahwa API baru akan membutuhkan TFM baru, yang berarti Anda harus memilih keluar dari LTS untuk mendapatkan perbaikan dengan mengandalkan .NET Core API baru. Tidak benar-benar situasi yang ideal.

Membedakan ke netcoreapp adalah persis apa yang mereka lakukan di sini.

Membedakan benar-benar baik-baik saja dan saya sangat setuju .NET Core harus menjadi target pilihan untuk ASP.NET Core. Tapi itu tidak berarti membuang .NET Desktop sepenuhnya, khususnya ketika alternatif seperti kompilasi silang ada.

Kita perlu menyeimbangkan kesederhanaan di permukaan & jangkauan API dengan produktivitas pengembang.

Tentu. Tetapi Anda juga perlu menyeimbangkannya dengan fakta lib warisan - dikembangkan untuk .NET Desktop dan menggunakan fitur yang tidak tersedia di .NET Core - akan berfungsi dengan baik di ASP.NET Core 2.0, seperti yang mereka lakukan di 1.0.

Sebagai gantinya, kami akan menghentikan dukungan untuk versi platform .NET yang tidak memiliki fitur tersebut atau memberikan fitur tersebut sebagai paket NuGet independen yang tidak didukung di semua tempat.

Itu benar-benar baik dalam teori. Tetapi platform yang saat ini kekurangan fitur penting adalah .NET Core, bukan .NET Desktop. Ini mungkin akan berubah dalam beberapa tahun, tetapi yang pasti adalah bahwa orang masih akan menemukan fitur yang hilang di .NET Core 2.0.

Mungkin layak untuk memiliki forward-port repo di dotnet di mana orang dapat membuat permintaan api untuk item tertentu yang mereka anggap hilang dari .NET Core dari .NET Framework?

Lalu umpan balik, ulasan, dan bimbingan dapat dilakukan di luar kebisingan kode repo sehari-hari? Atau ulasan api umum/repo spesifikasi (Semacam seperti csharplang vs roslyn)

Juga akan menjadi pilihan yang baik untuk: "Saya memiliki masalah konversi dan perlu mencari masalah yang terkait dengan X api" Sedangkan corefx sangat bising untuk itu.

[@benaadams] Mungkin layak untuk memiliki repo port-forward di dotnet di mana orang dapat membuat permintaan api untuk item tertentu yang mereka anggap hilang dari .NET Core dari .NET Framework?

Saya akan mengatakan ini hanya masalah di CoreFx. Juga, janji kami secara umum adalah: jika jenisnya dibagi antara .NET Framework dan .NET Core, kami bermaksud untuk mem-port anggota yang baru ditambahkan ke .NET Framework. Dalam kasus yang sangat jarang ini mungkin tidak mungkin, tetapi taruhannya adalah bahwa mereka secara otomatis dipertimbangkan.

[@benaadams] Atau ulasan api umum/repo spesifikasi

Tidak yakin itu layak. Ulasan API sudah agak berat; mengekstraknya ke repo lain tampaknya memperkuat itu. Saya lebih suka kita terus merampingkan CoreFx sehingga menambahkan API baru semudah melakukannya di, katakanlah, ASP.NET.

seperti yang dinyatakan sebelumnya, mereka akan dapat melanjutkan referensi perpustakaan/kerangka kerja yang menargetkan .NET Framework, dan itu akan berfungsi dengan baik dengan asumsi API yang mereka panggil adalah bagian dari penutupan netstandard2.0

@DamianEdwards Bagaimana dengan API yang tidak dalam penutupan netstandard2.0? Sebagian besar perpustakaan pihak ke-3 adalah sumber tertutup. Bagaimana saya bisa tahu bahwa setiap kasus tepi dalam penutupan netstandard2.0?
Seperti yang ditunjukkan oleh @PinpointTownes , ini seperti bermain Roulette Rusia.

@MJomaa tooling akan membantu di sini, tetapi jelas satu-satunya cara untuk mengetahui dengan pasti adalah dengan menjalankannya. Itu sebenarnya tidak berbeda dari pustaka .NET Standard yang berjalan pada kerangka kerja yang didukung .NET Standard. API yang ada tidak menggantikan kebutuhan untuk menguji pustaka ini. Itu bukan untuk mengatakan bahwa implementasi standar net tidak bertujuan untuk menjadi kompatibel, tetapi mereka adalah tepi, misalnya https://github.com/dotnet/standard/blob/cc9f646354fc68a13707a82323d4032b8dbfda52/netstandard/src/ApiCompatBaseline.net461.txt

Itu adalah API yang ada di NS 2.0 tetapi tidak ada di .NET Framework 4.6.1.

Saya benar-benar gugup tentang perubahan ini, tetapi setelah membaca utas tampaknya baik-baik saja secara teori. Kami memiliki 5 aplikasi ASP.NET Core dengan 4 di antaranya pada kerangka kerja penuh, tetapi itu sebagian besar hanya karena kami bersikap defensif daripada yang lain dan mengambil jalur yang paling tidak tahan.

Saya pikir semacam alat yang dimasukkan ke dalam VS seperti .NET Core Portability Analyzer dapat membantu para pengembang yang tidak up-to-date di Twitter/GitHub dan tidak menyadari bahwa ekstensi ini bahkan ada. Munculan "sarankan ekstensi" muncul di benak, tetapi saya tidak yakin tindakan apa yang akan diambil seseorang untuk memicunya. Mencoba menambahkan lib net46x ke aplikasi ASP.NET Core 2+ mungkin?

Hal-hal yang tidak dapat dikontrol Microsoft seperti dukungan pihak ketiga dengan Telerik, Syncfusion, dll. akan menjadi pemblokir potensial juga tergantung pada apa yang mereka lakukan.

Pesan di utas GitHub ini harus keluar ke posting blog ASAP dengan FAQ atau sesuatu. Saya merasa seperti saya telah berada di atas segalanya, dan saya masih tidak 100% yakin apakah ini berarti kami dapat merujuk lib net46x atau tidak. Saya jelas bukan satu-satunya yang bingung dengan itu.

Untuk menggemakan apa yang orang lain katakan. Saya telah berbicara dengan setidaknya 10 pengembang yang tidak tahu ASP.NET Core dapat berjalan pada kerangka kerja penuh. Saya memiliki pengalaman yang sama dengan @ aL3891 meskipun di mana para pengembang sangat senang mereka dapat menjalankan ASP.NET Core pada kerangka kerja penuh dan lib internal mereka hanya akan berfungsi. Sekali lagi - pesan tentang .NET Core 2.0 yang memiliki sebagian besar kasus penggunaan akan sangat, sangat penting. Bagian tentang memiliki setidaknya solusi khusus Windows untuk seperti System.DirectoryServices dalam pekerjaan juga akan menjadi penting juga. Banyak pengembang NET yang saya ajak bicara untuk mengangkat bahu ketika mereka mendengar bahwa .NET Core adalah lintas-plat dan lebih peduli dengan kode yang ada yang berfungsi daripada x-plat/perf.

Guys, ini semacam sampah :(
Kami membangun di atas ASP.NET Core karena opsi untuk menggunakannya dengan netfx, dan kami membangun hal-hal yang dimaksudkan untuk bertahan 5-10 tahun, bukan untuk 1 tahun dukungan maks. Inilah arti nama ASP.NET dalam bisnis dan itulah sebabnya organisasi besar yang bergerak lambat memilihnya daripada kerangka kerja bulanan. Biarkan saya beralih ke kasus penggunaan konkret ..

Saya bekerja di grup perkakas yang membangun lini perpustakaan bisnis dan aplikasi untuk penggunaan internal ke perusahaan dan untuk dijual ke klien 'perusahaan'. Sebagian besar organisasi pemerintah dalam kasus kami, tetapi saya yakin Anda akan mendengar hal yang sama dari sektor swasta. Kami memiliki kerangka kerja internal yang mengkodekan pola bisnis ke dalam abstraksi umum - pikirkan "IDatabaseConnection", "IEntityProvider", "IWizardFlow", "ICodeGenerator" - dan buat frontend RAD di atas backend yang dapat dicolokkan ini.

Di tumpukan kami, ASP.NET Core adalah 'plugin' - ini adalah tujuan HTTP, digunakan sebagai abstraksi datastore dan untuk layanan hosting dan seterusnya. Ini juga merupakan 'frontend' - jelas banyak aplikasi LOB di luar sana adalah situs web, dan ini adalah kerangka kerja baru yang bagus untuk aplikasi web. Jadi kami memiliki persyaratan interoperabilitas dua arah - kode AN-C yang mereferensikan komponen acak lainnya, dan kode acak lainnya yang mereferensikan AN-C.

Kami benar-benar penggemar Core CLR dan portabilitas, dan kami telah mem-porting banyak komponen kami untuk menargetkan atau multitarget netstandard. Kami memiliki satu aplikasi yang dihosting di Linux sejauh ini dan berharap untuk memiliki lebih banyak lagi yang akan datang. Namun, tidak mungkin semuanya akan di-porting dalam waktu dekat! Kami memiliki kode yang masih hidup dan dikembangkan secara aktif yang bergantung pada

• Otentikasi NTLM (termasuk skenario lanjutan seputar token dan SPN)
• System.Drawing seperti di atas (kerutan yang menarik di sini: kita membutuhkan format gambar lama seperti TIFF, yang tidak didukung oleh perpustakaan OSS baru)
• Menghubungkan ke api WCF/SOAP - masih berton-ton ini di luar sana
• Windows crypto apis (termasuk RSACng, ECDSA, dan CSP untuk token PKI)
• WPF guis - klien kami tidak akan beralih ke windows 10 dalam waktu dekat dan bahkan ketika mereka melakukannya, mereka tidak akan menginginkan aplikasi Store
• Interop Microsoft Office (khususnya akses dan excel) untuk impor dan ekspor data
• Ekstensibilitas Visual Studio
• Plugin pihak ketiga seperti penyedia Oracle ADO.NET

Beberapa dari teknologi ini tidak akan pernah didukung oleh Core CLR. Tapi itu adalah teknologi nyata, yang merupakan dasar dari pengembangan aplikasi baru - kami membutuhkan versi .NET yang memiliki akses ke hal ini. Saat ini posisi kami dapat dikelola: kami mengisolasi dependensi "warisan" (benar-benar: khusus platform) ke dalam komponennya sendiri yang spesifik untuk net461. Aplikasi bisnis tertentu kemudian mengambil ketergantungan pada netfx jika mereka membutuhkan fitur ini, dan bukan sebaliknya. Saya membayangkan masa depan di mana ini jarang terjadi untuk aplikasi baru.. tetapi sulit untuk membayangkannya menjadi 0%.

Anda melakukan semua pekerjaan ini di csproj dan SDK karena interop itu penting. ASP.NET Core adalah wortel, alasan ingin interop. Saya tidak berpikir masuk akal untuk mengambilnya. Dan tidak, "Anda dapat memuat referensi Anda dalam satu arah, tetapi kemungkinan besar akan gagal saat runtime" bukanlah interoperabilitas.

@gulbanana Bisakah Anda menjelaskan bagian-bagian sistem yang menggunakan ASP.NET Core mengapa mereka harus dalam proses yang sama dengan .NET Framework. Saya menghargai daftarnya (pluging Visual Studio, interop kantor dll) tetapi apakah Anda menyematkan ASP.NET Core di semua tempat itu hari ini (saya tidak memiliki gambar yang bagus dari deskripsi di atas)?

Juga apa yang Anda gunakan sebelum ASP.NET Core ada? Atau apakah ini hanya usaha baru yang tidak pernah menggunakan ASP.NET tetapi bertaruh 5-10 tahun pada ASP.NET Core di .NET Framework menjadi sesuatu? Apakah Anda melihat Katana?

Oke, berikut adalah beberapa studi kasus khusus. Saya akan mengatakan di muka bahwa saya yakin banyak dari ini dapat ditangani dengan menjalankan pekerjaan khusus desktop dalam proses terpisah, meskipun sepertinya merepotkan untuk mengubah banyak implementasi antarmuka menjadi RPC. Ini tidak seperti kita hanya bisa menggunakan remote atau serialisasi biner antara CLR inti dan desktop, baik..

NTLM/AD

Untuk tujuan Single Sign On, kami memiliki aplikasi yang mengandalkan browser yang meneruskan kredensial masuk Windows ke IIS, yang meneruskannya ke situs web ASP.NET Core. Bagian dari proses otentikasi kemudian mencari informasi seperti apakah pengguna berada dalam grup AD tertentu. Saya benar-benar ingin mendengar lebih banyak tentang "paket dukungan windows" dan apakah itu dimaksudkan untuk mencakup hal-hal seperti ini.

Sistem.Gambar

Ini digunakan dalam aplikasi web yang membuat thumbnail dan pengeditan gambar dasar (rotasi, overlay tanda air). Banyak gambar yang digunakan berasal dari zaman dinosaurus, jadi ada hal-hal seperti TIFF di sana. Mereka adalah data yang dikelola oleh departemen pemerintah yang berkaitan dengan daftar properti tertentu dan pengelolaan lahan. Dalam hal ini aplikasi awalnya ASP.NET MVC, dan ditingkatkan/ditulis ulang melalui MVC 2, 4, 5 dan sekarang Core.

VSIX

Ini adalah kasus penyematan AN-C di netfx alih-alih sebaliknya. Kami memiliki ekstensi Visual Studio untuk pembuatan kode yang menjalankan 'templat' untuk berbagai skenario RAD. Beberapa template ini dibuat untuk pengembangan web dan mengacu pada tipe AN-C pada waktu desain (dibuat menggunakan preprosesor/runtime T4).

Kripto

Yang ini benar-benar harus dalam proc saya pikir - kami memiliki skenario lisensi di mana kodenya sangat sensitif terhadap keamanan. Secara umum, ini mendekripsi dan memverifikasi file lisensi sehubungan dengan lingkungan tempat kode berjalan - ini adalah perpustakaan umum yang digunakan di backend aplikasi web serta aplikasi desktop. Akhirnya .NET Core tampaknya akan mendapatkan dukungan crypto yang cukup sehingga yang ini dapat di-porting, tetapi tidak hari ini. Misalnya, salah satu opsi yang kami miliki saat ini adalah dukungan token Fortinet/ePass2003 PKI, di mana middleware mereka jelas tidak mendukung Core (dan tidak ada kerangka waktu untuk melakukannya).

Oracle ADO.NET

Menggunakan Entity Framework 6 dengan backend Oracle tidak harus di-proc tetapi pasti akan merepotkan bagi situs web kami untuk menambahkan tingkat tambahan hanya untuk mendapatkan ke database!

Interop WPF

Kami menggunakan Microsoft.Extensions.Logging di semua aplikasi desktop kami hari ini- abstraksi logging itu sendiri perlu di-proc, bahkan jika implementasinya tidak.

Adapun apa yang kami gunakan sebelumnya ASP.NET Core - ASP.NET MVC! Kita bisa kembali tetapi akan sangat disayangkan untuk melepaskan semua keuntungannya.

Sebagai seorang arsitek, saya bingung untuk tidak melihat apakah "ASP.NET Core berjalan pada kerangka kerja penuh" akan bertahan di luar versi pertama. Sejujurnya tidak pernah terpikir oleh saya bahwa itu tidak akan terjadi. Saya hanya tidak membayangkan kemungkinan bahwa pada awal 2018 mungkin, misalnya, tidak ada versi yang didukung yang dapat memuat dokumen Office...

Satu hal yang saya tidak jelas adalah di mana ASP.NET Core digunakan di setiap skenario yang Anda sebutkan.

NTLM/AD

Yang ini masuk akal dan saya ingin memahami API yang akhirnya dipetakan. Apakah ini hanya System.DirectoryServices? Yang itu sedang aktif dikerjakan (Anda bisa melihatnya di corefx).

Sistem.Gambar

Ini adalah celah yang diketahui yang sedang kami tangani. Saya belum memiliki jawaban di sini dan saya tidak akan menyarankan menulis ulang menggunakan ImageSharp (meskipun itu adalah opsi). Ini perlu ditangani.

VSIX

Di mana ASP.NET Core di sini? Apakah itu berjalan di dalam ekstensi studio visual?

Kripto

Apakah ada masalah corefx untuk yang satu ini? Mengapa tidak porting saja? Tidak seperti .NET Framework, rilis .NET Core dipisahkan dari OS sehingga hal ini mungkin terjadi lebih cepat daripada nanti jika dianggap penting. (Penafian: Saya tidak cukup tahu tentang crypto untuk memahami implikasi dari melakukan lintas platform ini).

Oracle ADO.NET

Di mana ASP.NET Core masuk ke sini? Apakah Anda hanya mengatakan bahwa penyedia Oracle belum di-porting ke .NET Core?

Kami menggunakan Microsoft.Extensions.Logging di semua aplikasi desktop kami hari ini- abstraksi logging itu sendiri perlu di-proc, bahkan jika implementasinya tidak.

Microsoft.Extensions.* akan tetap standar bersih sehingga Anda tercakup di sana.

Mengapa tidak ada pengumuman/diskusi?
Saya suka apa yang dilakukan tim inti aspnet/.net, tetapi saya memiliki ketakutan yang sama dengan @jhurdlow.

Senang mendengar tentang MEL Di poin lain-

NTLM

Inilah satu kelas yang digunakan di sebagian besar aplikasi kita. Itu membuat penggunaan API yang cukup sepele, hal-hal yang diharapkan dapat porting secara teori (tetapi belum).
https://Gist.github.com/gulbanana/70fe791735ee884169e2eee354a32ad2

VSIX

Template codegen khusus untuk inti asp.net menggunakan sistem aksi/perutean (IFileProvider dll) untuk menemukan pengontrol dan tampilan dll dan mengisi perancah kami. Kami tidak menghosting hosting ASP.NET di dalam visual studio, hanya mengintrospeksi aplikasi ASP.NET.

Kripto

Saya menduga algoritme yang kami gunakan akan di-porting, tetapi belum. Ini semua akan terlihat jauh berbeda jika premisnya adalah, seperti, pengumuman rencana jangka panjang untuk menghentikan dukungan untuk asp.net-core-on-netfx dan diskusi tentang kapan itu mungkin!

Peramal

Ya, ini akan diselesaikan jika port Oracle terjadi (dengan asumsi itu berfitur lengkap dan sebagainya).

Satu lagi kasus penggunaan:
Salah satu aplikasi kami mengimpor data lama dari aplikasi Access. Saat ini proses impor berjalan di server di situs web inti asp.net. Ia menggunakan interop COM untuk memuat acedao.dll dari mesin accdb/jet yang dapat didistribusikan kembali, membaca tabel ke dalam abstraksi entitas kami, lalu menyimpannya ke dalam database SQL yang lebih modern.

Ini adalah kasus lain dari 'bisa keluar dari proc, tapi mengapa harus begitu'. Kami pada dasarnya akan menggunakan AN-C sebagai antarmuka ke situs web WebAPI 2 atau sesuatu, dalam hal ini kami telah kembali ke ketergantungan itu di masa lalu :(

Secara keseluruhan, tujuan kami adalah untuk memindahkan sebagian besar dari apa yang kami lakukan ke .NET Core. Kami ingin interop sebanyak mungkin selama mungkin selagi kami memindahkan barang-barang...

WTF!!! 😨.
Apakah Anda mengatakan bahwa ASP.NET Core 2 tidak akan menargetkan Full .NET framework 4.x lagi !!!
Kami baru saja memulai proyek 1 bulan yang lalu dengan ASP.NET Core 1.1 dan kami menargetkan .NET 4.6 karena kami mereferensikan beberapa Lib .NET Lengkap. Dan kami akan meningkatkan ke ASP.NET Core 2. Tapi apa yang saya dengar dari posting ini...
Begini, kami memilih ASP.NET Core karena kelebihannya (DI, gabungan API dan MVC, ... kuat), jadi, tolong berikan sebagai gantinya.

Kami baru saja memulai proyek 1 bulan yang lalu dengan ASP.NET Core 1.1 dan kami menargetkan .NET 4.6 karena kami mereferensikan beberapa Lib .NET Lengkap

Apa yang dilakukan perpustakaan-perpustakaan itu? Apakah Anda membaca balasan awal @shanselman https://github.com/aspnet/Home/issues/2022#issuecomment -299536123? Dimungkinkan untuk mereferensikan beberapa pustaka .NET Framework di .NET Core 2.0 (dengan asumsi mereka tetap berada dalam subset API).

Apa yang dilakukan perpustakaan-perpustakaan itu? Apakah Anda membaca balasan awal @shanselman # 2022 (komentar)? Dimungkinkan untuk mereferensikan beberapa pustaka .NET Framework di .NET Core 2.0 (dengan asumsi mereka tetap berada dalam subset API).

@davidfowl ya saya membaca komentar @shanselman , kami menggunakan beberapa Lib yang dibuat oleh perusahaan beberapa dari lib tersebut menggunakan WCF, semua Lib tersebut stabil, mereka menargetkan .NET 3.5, dan kami tidak dapat menyentuhnya.

Ini akan menjadi situasi yang sangat umum. Saya ingin tahu apakah ada informasi yang telah dikumpulkan (telemetri?) tentang berapa banyak pengguna ASP.NET Core sejauh ini di .NET Core vs .NET Framework.

Saya pribadi tidak emosional tentang ini, tetapi beberapa pengamatan:

• sebagian besar pelanggan yang saya miliki saat ini menggunakan kombinasi kerangka kerja asp.net core 1.x/full karena mereka takut untuk melakukan semua hal yang baru
• mengatakan dari nomor unduhan paket nuget, adopsi asp.net core tidak bagus. Dengan langkah itu, akan lebih sulit untuk menjual sesuatu yang tidak laku saat ini.
• sangat bagus bahwa Anda telah mengidentifikasi hal-hal LDAP sebagai celah (saya pikir saya tidak pernah melihat siapa pun dalam 10 tahun terakhir menggunakan perpustakaan itu tetapi mungkin itu hanya saya). Masalah yang lebih besar adalah lib pihak ke-3. Ini akan menjadi alasan sebenarnya mengapa orang tidak akan pindah ke .net core

Seluruh situasi ini sekali lagi merupakan contoh bagus lain dari MS yang hanya membuat keputusan tanpa ada petunjuk. Hanya karena beberapa orang mengikuti check-in, utas ini ada di sini.

Saya mungkin salah, tetapi saya pikir .NET Core sekarang berada di bawah tata kelola DNF - jadi keputusan ini bukan lagi murni internal MS.

Hal-hal LDAP/AD jelas merupakan alasan mengapa saya harus tetap berada di atas net462 sekarang. Saya ingin benar-benar pergi, BAM -> NetCore sepenuhnya, tetapi ini adalah kelemahannya.

Saya juga menggunakan XML-RPC.net di salah satu proyek saya. Ini menggunakan beberapa Reflection.Emit yang serius di dalamnya, dan saya tidak yakin apakah NetCore 2 akan mendukungnya sepenuhnya. Saya harus mencoba Portability Analyzer untuk memastikannya.

Saya menemukan seluruh situasi ini sedikit mengecewakan dengan betapa cepat dan mudahnya keputusan penting seperti ini yang mempengaruhi masa depan .NET dapat terjadi tanpa transparansi, pada menit terakhir, lagi. Banyak energi telah diinvestasikan dalam menjual ekosistem .NET yang ada saat bermigrasi ke ASP.NET Core dengan pesan (dari pemahaman saya) adalah bahwa .NET Standard 2.0 akan fokus pada kompatibilitas dan akan menjadi rilis yang menjembatani kesenjangan dengan .NET v4.x untuk akhirnya menghasilkan platform .NET yang solid dan stabil yang akhirnya dapat diandalkan oleh ekosistem. Saya pribadi tidak percaya .NET Core akan benar-benar lepas landas sampai setelah .NET Standard 2.0 dirilis karena saya mengantisipasinya sebagai "tanah stabil yang dijanjikan" yang kita semua tunggu - sekarang saya tidak tahu apa ".NET Standard 2.0" artinya, apa sebenarnya yang akan dibahas dan perpustakaan mana yang direncanakan untuk menjadi .NET Core saja.

Karena belum ada pengumuman resmi sebelumnya, permintaan untuk umpan balik, polling atau alasan yang diberikan, keputusan ini "tampaknya" telah dilakukan tanpa keterlibatan komunitas atau analisis dampak terhadap ekosistem .NET yang ada dan kemungkinan akan memecah seluruh ekosistem untuk banyak orang. tahun yang akan datang. Menghapus dukungan .NET v4.x menghapus jalur migrasi yang mulus bagi banyak perusahaan untuk dapat memigrasi basis kode yang ada ke model pengembangan baru ASP.NET. Ini tidak akan mendorong mereka untuk melompat ke .NET Core lebih cepat, ini secara efektif mencegah mereka bahkan mencoba, menyebabkan fragmentasi besar-besaran yang akan memecah ekosistem .NET menjadi dua. Saya tidak melihat bagaimana ini akan menjadi berbeda dari Python 2/3 yang telah dirusak secara permanen oleh fragmentasi yang masih belum dapat dipulihkan dalam hampir satu dekade.

Sebagian besar basis kode .NET yang ada adalah brownfield yang sedang dikembangkan di belakang layar oleh "materi gelap" pengembang .NET, yang sebagian besar tidak akan tahu bahwa keputusan ini dibuat mengingat .NET Core 1.1 mendukung .NET v4.x dan pesan untuk .NET Standard 2.0 menjanjikan peningkatan kompatibilitas. Saya mengharapkan reaksi besar-besaran setelah berita dan dampak dari keputusan ini akhirnya sampai ke rumah. Banyak pengembang yang telah menjual adopsi .NET Core secara internal dalam organisasi mereka akan merasa dikhianati karena mereka telah secara efektif bermigrasi ke platform buntu (jika mereka tidak dapat sepenuhnya bermigrasi ke .NET Core karena alasan apa pun ) kenyataan pahit yang harus mereka hadapi tepat setelah mereka berhasil dalam keputusan monumental untuk meyakinkan pemangku kepentingan dalam organisasi mereka untuk menyetujui sumber daya yang diperlukan untuk migrasi mereka saat ini.

Sebagian besar organisasi perlu memigrasikan basis kode yang ada "dalam penerbangan" di mana mereka perlu terus menerapkan sistem yang ada sambil memigrasi basis kode mereka "secara paralel" yang akan ingin digunakan ke .NET v4.x terlebih dahulu, lalu setelah semuanya stabil dan semua masalah telah diselesaikan, mereka kemudian dapat merencanakan migrasi penuh ke .NET Core dari sana.

Keputusan ini juga dibuat dalam konteks bertahun-tahun melanggar perubahan pada ASP.NET yang IMO telah mengikis kepercayaan bahwa .NET adalah platform stabil yang dapat diandalkan oleh organisasi. Saya suka model pengembangan baru .NET Core, tetapi IMO yang paling kami butuhkan adalah platform stabil yang dapat kami andalkan sehingga ekosistem lainnya dapat mengejar. .NET Core masih di lembah yang luar biasa, dengan perkakas yang belum matang, dependensi yang tidak kompatibel, masalah runtime, dokumentasi kedaluwarsa, dll - Saya belum pernah melihat .NET ini tidak stabil sejak hari-hari awal ketika pertama kali dirilis.

Mengapa tidak menjalankan polling tentang apa yang diinginkan lebih banyak oleh .NET devs? yaitu platform yang kokoh dan stabil atau platform "bergerak cepat" yang menghadirkan fitur baru lebih cepat? Saya mengerti itu akan membutuhkan lebih sedikit usaha untuk tidak perlu khawatir tentang fitur back-porting ke .NET v4.x tetapi akan sangat berharga untuk memiliki versi ASP.NET Core yang berfokus terutama pada penyediaan platform yang kompatibel dan stabil dengan panjang dukungan istilah yang dapat berjalan di .NET v4.x atau .NET Core.

Apakah kapal ini berlayar atau apakah ada opsi untuk mempertahankan ASP.NET Core 2.0 seperti apa adanya? yaitu dengan sebagian besar perpustakaan dan abstraksi yang dicakup oleh .NET Standard 2.0 dan kemudian di rilis ASP.NET Core 3.0 berikutnya mengumumkan bahwa platform berikutnya hanya .NET Core? Ini akan memungkinkan organisasi untuk terus bergerak maju dan mengadopsi ASP.NET Core 2.0 dan memungkinkan ekosistem lainnya untuk mengejar ketinggalan, dengan alat dan pustaka yang stabil dan didukung dengan baik, sementara memiliki pemisahan yang bersih dari tempat .NET Core saja platform/ fitur mulai.

Dimungkinkan untuk mereferensikan beberapa pustaka .NET Framework di .NET Core 2.0 (dengan asumsi mereka tetap berada dalam subset API).

Ini menimbulkan ketidakpastian, sangat sedikit orang yang mau mempertaruhkan reputasi dan kesehatan serta stabilitas sistem mereka dan mencoba migrasi penuh ke .NET Core ketika ada ketidakpastian pada dependensi mana yang akan dan tidak akan dapat dijalankan. .NET Core, yang berarti lebih banyak orang tetap menggunakan .NET v4.x di masa mendatang.

Saya tidak benar-benar tahu bagaimana hal ini pada akhirnya akan terjadi dan apa dampak sebenarnya dari keputusan ini terhadap seluruh ekosistem .NET, tetapi fakta bahwa keputusan penting seperti ini dengan dampak luas dapat terjadi tanpa keterlibatan komunitas eksternal adalah mengkhawatirkan.

Saya berharap kalian tidak terlalu bertekad untuk membagi dua basis pengguna Anda.

Sudut pandang saya saat membuat perpustakaan adalah membuatnya mudah digunakan, untuk sebanyak mungkin orang, di sebanyak mungkin tempat. Ini adalah rasa sakit di leher (cari #if arahan kompiler di Newtonsoft.Json dan Anda mendapatkan 1300+ hasil) tetapi "Ini hanya berfungsi" adalah nilai jual yang kuat.

Mengapa tidak menjalankan polling tentang apa yang diinginkan lebih banyak oleh .NET devs? yaitu platform yang kokoh dan stabil atau platform "bergerak cepat" yang menghadirkan fitur baru lebih cepat? Saya mengerti itu akan membutuhkan lebih sedikit usaha untuk tidak perlu khawatir tentang fitur back-porting ke .NET v4.x tetapi akan sangat berharga untuk memiliki versi ASP.NET Core yang berfokus terutama pada penyediaan platform yang kompatibel dan stabil dengan panjang dukungan istilah yang dapat berjalan di .NET v4.x atau .NET Core.

Pertanyaan asli, ASP.NET Core 1.x saat ini mendukung .NET Framework dan .NET Core. Katakanlah itu adalah platform stabil yang Anda sebutkan di atas, yang kami perbaiki dan dukung bug pada kedua runtime tetapi tidak mendapatkan lebih banyak fitur. Apakah itu cukup?

ASP.NET Core dan .NET Core adalah platform kaya fitur yang bergerak cepat untuk .NET saat ini. Ini adalah versi .NET yang tidak terikat dengan sistem operasi apa pun dan memberi kami kelincahan yang dibutuhkan untuk berinovasi dengan cepat dan merilis lebih cepat.

Apakah kapal ini berlayar atau apakah ada opsi untuk mempertahankan ASP.NET Core 2.0 seperti apa adanya? yaitu dengan sebagian besar perpustakaan dan abstraksi yang dicakup oleh .NET Standard 2.0 dan kemudian di rilis ASP.NET Core 3.0 berikutnya mengumumkan bahwa platform berikutnya hanya .NET Core? Ini akan memungkinkan organisasi untuk terus bergerak maju dan mengadopsi ASP.NET Core 2.0 dan memungkinkan ekosistem lainnya untuk mengejar ketinggalan, dengan alat dan pustaka yang stabil dan didukung dengan baik, sementara memiliki pemisahan yang bersih dari tempat .NET Core saja platform/ fitur mulai.

Kami selalu terbuka untuk umpan balik dan ASP.NET Core 2.0 belum dikirimkan. Jika ASP.NET Core 3.0 adalah rilis yang menjatuhkan .NET Framework, apakah itu akan membuat segalanya lebih baik? Jika Anda melihat beberapa umpan balik dari @gulbanana dan @ikourfaln , ada teknologi yang kemungkinan tidak akan pernah di-porting dan karenanya tidak akan pernah berfungsi di .NET Core, bukankah itu berarti mendukung .NET Framework selamanya? Bukankah kita akan mengadakan diskusi yang sama setahun dari sekarang? Mungkin saat itu ekosistem atau library yang mendukung .NET Core akan lebih besar sehingga dampaknya lebih kecil? Bagaimana dengan perpustakaan perusahaan yang tidak akan pernah diperbarui (atau di mana kode sumbernya hilang)? Apakah itu akan berubah dalam setahun?

Sudut pandang saya saat membuat perpustakaan adalah membuatnya mudah digunakan, untuk sebanyak mungkin orang, di sebanyak mungkin tempat. Ini adalah rasa sakit di leher (cari #if arahan kompiler di Newtonsoft.Json dan Anda mendapatkan 1300+ hasil) tetapi "Itu hanya berfungsi" adalah nilai jual yang kuat.

Jangan tersinggung @JamesNK tetapi JSON.NET adalah parser JSON dan sebagian besar satu paket (saya tahu ada beberapa lagi). ASP.NET Core memiliki > 200 paket.

Jangan tersinggung tapi saya seorang pria yang bekerja paruh waktu. Masalah Anda lebih sulit tetapi Anda memiliki lebih banyak sumber daya secara eksponensial.

Setelah membaca ini dan melihat melalui dependensi yang kita miliki, saya kurang yakin ini adalah ide yang bagus.

Sesuai rencana, kami tidak dapat mem-port salah satu aplikasi kami ke netstandard / netcoreapp hingga System.DirectoryServices tersedia ( Masalah CoreFX #2089 di sini ). Jadi sementara kita bisa port ke ASP.NET Core 1.x, kita tidak bisa pergi ke 2.0. Melihat aplikasi di sini: Opserver, Stack Overflow itu sendiri, aplikasi internal kami...tidak ada yang siap karena 2.0 sudah siap untuk saat ini. Menurut standup minggu ini, hal-hal penting seperti DirectoryServices masih akan mengikuti dalam rilis 2.x kemudian.

Jadi antara 1.0 dan 2.0 itu berubah dari sesuatu yang saya sedang bersiap untuk pindah, menjadi sesuatu yang saya tidak bisa pergi. Jadi ya, saya akan mengatakan itu belum siap. ASP.NET adalah cara untuk mengekspos bit yang saya butuhkan melalui HTTP. ASP.NET Bukan hal yang saya butuhkan dalam dirinya sendiri. Saya tidak menggunakan .NET hanya untuk bit web, saya menggunakannya untuk platform... seperti kebanyakan orang. Platform tidak siap untuk berbagai kasus penggunaan yang diminta pengguna, sehingga memaksa pengguna ke platform itu menyebabkan rasa sakit dan pemblokiran.

Intinya adalah jika kita membutuhkan AD auth (sebagian besar platform), kita baru saja ditinggalkan pada baris 1.x. Di situlah saya menuju dengan aplikasi kami ... tetapi jika ini adalah arahnya maka tidak ada gunanya berusaha di sini sampai bit yang saya butuhkan tersedia di tujuan.

Jika kita dapat mengatakan hal-hal penting seperti System.DirectoryServices , System.Drawing , dan item teratas lainnya yang dibutuhkan orang akan siap dengan ASP.NET Core 2.0, pendapat saya banyak berubah. Jika itu adalah renungan (seperti yang ditunjukkan oleh jadwal saat ini), silakan lanjutkan mendukung .NET Framework sampai selesai.

Bergerak cepat itu bagus. Aku menyukainya. Saya menjalankan alfa dalam produksi sekarang. Tetapi tidak ada yang penting jika itu tidak berfungsi untuk kasus penggunaan Anda sejak awal.

Satu hal yang secara pribadi saya perjuangkan adalah hal "platform stabil" vs "fitur baru". Di satu sisi, kami ingin platform stabil dan andal serta kompatibel, di sisi lain tidak ada yang ingin tetap menggunakan 1.x karena tidak memiliki fitur 2.x. Apakah ada fitur super menarik di ASP.NET Core 2.x yang menarik orang ke arah itu atau hanya fakta bahwa kami memiliki lebih banyak fitur daripada yang kami miliki di 1.x (karena baru dan mengkilap)?

Jika yang terakhir, lalu apakah orang-orang itu peduli dengan stabilitas? Jika jawabannya ya, lalu mengapa ASP.NET Core 1.x tidak mencukupi?

Saya tidak menggunakan .NET hanya untuk bit web, saya menggunakannya untuk platform... seperti kebanyakan orang. Platform tidak siap untuk berbagai kasus penggunaan yang diminta pengguna, sehingga memaksa pengguna ke platform itu menyebabkan rasa sakit dan pemblokiran.

Setuju, tetapi menurut Anda, bagaimana hubungannya dengan ASP.NET Core 2.x menjatuhkan dukungan .NET Framework? Ketika lebih banyak dependensi online, mereka akan bekerja di mana-mana sehingga dalam arti tertentu, saat platform bergerak maju, rangkaian runtime yang luas akan mendapatkan manfaatnya. Semua versi aplikasi ASP.NET Core tiba-tiba dapat memanfaatkan fitur-fitur tersebut.

Jika yang terakhir, lalu apakah orang-orang itu peduli dengan stabilitas? Jika jawabannya ya, lalu mengapa ASP.NET Core 1.x tidak mencukupi?

Semua orang selalu menginginkan fitur baru, kemungkinan fitur baru, atau setidaknya mengetahui bahwa mereka akan memiliki opsi untuk mendapatkan lebih banyak barang di kemudian hari. Saat Anda menutup platform dan memasukkannya ke dalam mode "stabil"/"pemeliharaan, orang-orang melihatnya sebagai tidak lagi diperhatikan.

Apakah ada fitur super menarik di ASP.NET Core 2.x yang menarik orang ke arah itu atau hanya fakta bahwa kami memiliki lebih banyak fitur daripada yang kami miliki di 1.x (karena baru dan mengkilap)?

Dukungan - itulah yang kami bayar.

Jika jawabannya ya, lalu mengapa ASP.NET Core 1.x tidak mencukupi?

Karena dukungan berakhir hanya sekitar satu tahun setelah rilis (menurut Scott di atas). Dan saya mungkin hampir tidak akan selesai mem-porting Stack Overflow saat itu.

bagaimana hubungannya dengan ASP.NET Core 2.x menjatuhkan dukungan .NET Framework?

Karena perpustakaan yang harus saya miliki tidak ada. Dan saya tidak tahu kapan mereka akan datang. Jadi saya akan terjebak di 1.x dan saya punya bom waktu sampai dukungan berakhir. Apakah saya akan memiliki cukup waktu untuk melakukan port dari 1.0 ke 2.x (atau 3.x) sebelum dukungan berakhir? Mungkin tidak.

Basis kode besar tidak bisa hanya berhenti dan port, mereka membutuhkan waktu, itu perlu terjadi secara bertahap. Melakukan port .NET 4.6.x ke ASP.NET Core layak sebagai langkah perantara. Pergi ke inti sekaligus jauh lebih sulit, membutuhkan waktu lebih lama, dan membutuhkan cabang yang berumur lebih lama dan lebih banyak rasa sakit. Jika kita tidak dapat melakukan ini secara bertahap, sejujurnya saya tidak dapat melihat kita pernah pindah dari jalur ASP.NET 5 yang sekarang ditinggalkan. Tidak mungkin saya bisa membenarkan waktu, biaya, dan dampak pengembangan yang akan terjadi.

Saya pikir banyak penulis OSS seperti saya juga - ini adalah perpanjangan dari pekerjaan sehari-hari kami. Jika kita tidak menggunakan platform atau melakukan dogfood, perpustakaan jauh lebih buruk atau tidak dibuat. Dan kami tidak dapat membenarkan waktu untuk mempertahankannya dengan jam kerja yang kami habiskan hari ini. Dan setiap perpustakaan yang kami buat berasal dari kebutuhan yang kami tekan dalam produksi. Kasus penggunaan penurunan ekosistem memiliki banyak dampak hilir yang tidak tiba-tiba, tetapi masih bertambah.

Saat ini pandangan saya adalah ini: ada platform baru yang berfungsi hingga sekitar Juli 2018. Setelah itu: Saya tidak tahu apa-apa, saya hanya berharap apa yang saya butuhkan tersedia di netstandard / netcoreapp saat itu. Dan semoga saya punya cukup waktu untuk melakukan port sebelum dukungan berakhir. Saya tidak dibayar untuk berharap, saya dibayar untuk membuat keputusan platform untuk perusahaan kami, dan ASP.NET Core adalah taruhan yang buruk (bagi kami) dengan perubahan ini dan tidak ada tanggal untuk versi yang akan berfungsi.

Izinkan saya menawarkan ringkasan satu baris: tanpa dukungan .NET Full Framework, ASP.NET Core tidak menawarkan platform yang didukung untuk kasus penggunaan kami selama 2 tahun ke depan.

Sebagai versi singkat, ini dia:

Prioritas 1: Ini harus bekerja pada net461 , tidak peduli apa ifdefs, perf yang ada.
Prioritas 2. Jika Anda dapat membuatnya 10x lebih cepat di .NET Core 2.0, maka itu luar biasa. Ini adalah alasan bagus bagi orang untuk memilih platform dan/atau bermigrasi jika mereka bisa.

Kuncinya di sini adalah bahwa untuk dukungan jangka panjang, ia masih harus bekerja pada kerangka kerja penuh, meskipun lebih lambat di sana.

Prioritas 1: Ini harus bekerja di net461

Dan jika .NET Core sepenuhnya kompatibel dengan net461 (dalam alasan); jadi apa pun yang ditulis untuk net461 berfungsi di Core; apakah itu akan baik-baik saja?

Pada dasarnya, pada saat itu Anda memiliki platform yang lebih stabil daripada net4x karena Anda dapat melakukannya secara berdampingan dan mandiri (sentuhan x-plat juga). Sedangkan net461 memiliki perubahan seluruh mesin menjadi 4.6.1, 4.6.2, 4.7 dll

Jelas sesuatu tidak akan pernah berhasil; seperti kepercayaan parsial - tetapi itu tidak pernah berhasil.

Pertanyaan asli, ASP.NET Core 1.x saat ini mendukung .NET Framework dan .NET Core. Katakanlah itu adalah platform stabil yang Anda sebutkan di atas, yang kami perbaiki dan dukung bug pada kedua runtime tetapi tidak mendapatkan lebih banyak fitur. Apakah itu cukup?

Saya ingin melihat rilis LTS dari ASP.NET Core 2.0 seperti yang dilakukan Ubuntu/Redhat dengan rilis LTS mereka yang mereka dukung selama 5+ tahun. Ini akan memberikan target yang kompatibel dan solid sehingga ekosistem lainnya dapat memiliki kepercayaan diri untuk berkomitmen untuk mengadopsi.

Saya pribadi lebih tertarik pada .NET Standard 2.0 yang stabil lebih dari fitur .NET Core-only masa depan mana pun karena saya ingin kembali ke pengembangan .NET di mana semuanya berfungsi kembali, perkakas tidak rusak, .NET yang populer. Semua paket .NET menyediakan dukungan untuk, penyebaran di sekitarnya dan solusi hosting dipoles dan ada banyak dokumen, posting, video, dan basis pengetahuan yang tersedia untuk ASP.NET Core yang stabil, tempat kami dapat mulai membangun solusi.

Bukankah kita akan mengadakan diskusi yang sama setahun dari sekarang? Mungkin saat itu ekosistem atau library yang mendukung .NET Core akan lebih besar sehingga dampaknya lebih kecil? Bagaimana dengan perpustakaan perusahaan yang tidak akan pernah diperbarui (atau di mana kode sumbernya hilang)? Apakah itu akan berubah dalam setahun?

Dalam dunia yang ideal .NET v4.x dan .NET Core keduanya akan mendukung ASP.NET Core di masa mendatang dan itu hanya fitur .NET Core-only baru yang hanya akan tersedia dalam paket .NET Core-only. Tetapi jika MS ditakdirkan untuk meninggalkan .NET 4.x di belakang, maka rilis ASP.NET 2.0 LTS sebelum Anda secara resmi berpisah akan menjadi hal terbaik berikutnya. Menurut definisi, tidak ada yang bergantung pada fitur baru yang belum ada sehingga tidak ada yang akan dipaksa untuk meningkatkan ke .NET Core-only v3.0.

Dengan kebebasan hanya harus mendukung 1 platform, Anda berpotensi menghadirkan fitur baru yang akan menarik pengembang untuk mengadopsi versi terbaru dan terhebat berikutnya dengan aliran fitur baru yang berkelanjutan, secara pribadi saya senang dengan fungsionalitas yang dimiliki ASP.NET sekarang dan seterusnya Saya lebih tertarik pada versi stabil di mana semuanya dipoles sehingga saya dapat kembali produktif lagi dan fokus pada pengembangan solusi daripada mengejar platform yang selalu bergerak.

Pertama, terima kasih @davidfowl untuk melompat ke thread dan berdiri/mengajukan pertanyaan, dll. Ketika ada komunitas yang panas menanyakan banyak Q, mudah untuk tidak masuk dan menghindari menjadi 'target'. Jadi terima kasih telah terlibat, secara konstruktif. /me salut padamu.

Saya melihat dua poin/utas utama yang keluar dari percakapan ini:

1. Permintaan untuk mendukung desktop .NET di vnext. (itu 99% dari balasan di sini)
2. Kurangnya konsultasi masyarakat atas keputusan penting tersebut. (2 atau 3 balasan di sini).

TL; DR;

• Bisakah kita lebih terbuka dengan perubahan besar yang penting berikutnya.
• Alokasikan waktu untuk beberapa RFC dari komunitas tentang perubahan vnext ini.

@mythz menyatakannya dengan baik dalam kalimat pembukanya (pada titik ini), ~most recent~ 2nd last comment:

Saya menemukan seluruh situasi ini sedikit mengecewakan dengan betapa cepat dan mudahnya keputusan penting seperti ini yang mempengaruhi masa depan .NET dapat terjadi tanpa transparansi, pada menit terakhir, lagi.

Inilah yang benar-benar memukul saya secara pribadi dan saya akan menyukai beberapa balasan/komentar resmi dari orang-orang yang tepat di MS yang melakukan panggilan ini. "Kami" telah berada di sekitar komunitas ini untuk waktu yang lama - wajah yang familiar, nama yang familiar dan cukup adil untuk dikatakan - semuanya mengikuti tujuan positif yang sama. Saya bahkan melanjutkan dengan mengatakan "kami" adalah keluarga besar yang cukup besar, kutil-dan-semuanya.

Jadi saya merasa bahwa dengan arah baru yang telah diambil MS (OSS-all-the-things, dll) dan dengan beberapa mega-uber-.NET-threads baru-baru ini dalam 12/18 bulan terakhir (baca: belajar dari pengalaman diskusi komunitas tersebut ) ... bahwa "kita" semua bersama-sama dan bahwa beberapa dari Hal-Hal Besar ™️ ini akan dibahas secara terbuka, jauh sebelumnya.

Jadi - bisakah kita membicarakan beberapa keputusan besar ini secara terbuka, sebelumnya? Dapatkan beberapa konsultasi dan diskusi komunitas yang positif?

Catatan: Saya menerima bahwa proyek ini bukan demokrasi dan _keputusan_ dibuat oleh MS. Tidak masalah. Saya tidak mengkritik _that_. Saya berbicara tentang langkah-langkah sebelum itu. Juga, saya tidak meminta _everything_ disiapkan untuk RFC, dll. Hanya item tiket utama yang aneh - seperti apa yang telah dimulai utas ini.

Tetapi jika MS ditakdirkan untuk meninggalkan .NET 4.x di belakang, maka rilis ASP.NET 2.0 LTS sebelum Anda secara resmi berpisah akan menjadi hal terbaik berikutnya. Menurut definisi, tidak ada yang bergantung pada fitur baru yang belum ada sehingga tidak ada yang akan dipaksa untuk meningkatkan ke .NET Core-only v3.0.

Saya tidak mengerti. Tidak ada yang bergantung pada fitur di ASP.NET 2.0 karena fitur tersebut tidak ada dalam rilis. Jadi bukankah ASP.NET Core 1.x versi itu? Ini berjalan pada kerangka kerja penuh, inti 1.0 dan inti 2.0 dan dapat bertindak sebagai batu loncatan ke ASP.NET Core 2.x?

@onovotny

Semua orang selalu menginginkan fitur baru, kemungkinan fitur baru, atau setidaknya mengetahui bahwa mereka akan memiliki opsi untuk mendapatkan lebih banyak barang di kemudian hari. Saat Anda menutup platform dan memasukkannya ke dalam mode "stabil"/"pemeliharaan, orang-orang melihatnya sebagai tidak lagi diperhatikan.

Ya, tetapi sangat sulit untuk menjamin tingkat kualitas yang sama ketika .NET Framework adalah stabil besar yang didukung terkait dengan komponen OS. Seperti yang dikatakan @terrajobst , beberapa hal pasti akan di-porting di beberapa titik tetapi yang lain perlu diketahui. Faktanya adalah, ASP.NET Core berjalan paling baik di .NET Core karena kami memiliki kemampuan untuk memutar seluruh tumpukan sekaligus. Sejauh ini, ada perbedaan kinerja yang besar antara 2 runtime dan kami belum mengambil ketergantungan pada API baru karena dukungan .NET Framework. Saat kami bergerak maju, kami akan menambahkan API baru yang mungkin atau mungkin tidak muncul di .NET Framework di beberapa titik dan kami tidak ingin meningkatkan kecepatan runtime bergerak paling stabil dan paling lambat (.NET Framework).

@NickCraver

Karena dukungan berakhir hanya sekitar satu tahun setelah rilis (menurut Scott di atas). Dan saya mungkin hampir tidak akan selesai mem-porting Stack Overflow saat itu.

Saya tidak yakin itu sepenuhnya akurat. Ketika 2.0 tersedia, 1.1 akan tetap didukung. Jadi apa "dukungan" yang Anda bicarakan ini? Maksud Anda dukungan berbayar atau maksud Anda kami akan memperbaiki masalah saat muncul?

Karena perpustakaan yang harus saya miliki tidak ada. Dan saya tidak tahu kapan mereka akan datang. Jadi saya akan terjebak di 1.x dan saya punya bom waktu sampai dukungan berakhir. Apakah saya akan memiliki cukup waktu untuk melakukan port dari 1.0 ke 2.x (atau 3.x) sebelum dukungan berakhir? Mungkin tidak.

Seperti yang saya katakan, perpustakaan itu akan menyala terlepas dari versi .NET Core. Saya pikir apa yang Anda katakan adalah bahwa Anda ingin menggunakan versi terbaru ASP.NET Core (apa pun itu) dan Anda ingin itu didukung di .NET Framework sampai ada cukup perpustakaan di .NET Core sehingga port mudah untuk Anda skenario tertentu.

Basis kode besar tidak bisa hanya berhenti dan port, mereka membutuhkan waktu, itu perlu terjadi secara bertahap. Melakukan port .NET 4.6.x ke ASP.NET Core layak sebagai langkah perantara. Pergi ke inti sekaligus jauh lebih sulit, membutuhkan waktu lebih lama, dan membutuhkan cabang yang berumur lebih lama dan lebih banyak rasa sakit. Jika kita tidak dapat melakukan ini secara bertahap, sejujurnya saya tidak dapat melihat kita pernah pindah dari jalur ASP.NET 5 yang sekarang ditinggalkan. Tidak mungkin saya bisa membenarkan waktu, biaya, dan dampak pengembangan yang akan terjadi.

Bagaimana versi revving ASP.NET Core memengaruhi itu? Jika kami menjatuhkan dukungan .NET Framework di 3.0 (seperti yang tampaknya dihindari orang di utas ini), bukankah Anda akan berada di jalan buntu yang sama? Anda akan menjalankan aplikasi ASP.NET Core 2.0 pada kerangka kerja selama satu tahun dan ketika 3.0 keluar, Anda tidak akan dapat memutakhirkan. Anda tetap dapat melakukan ini dengan ASP.NET Core 1.1.x yang berjalan pada .NET Framework dan didukung bahkan ketika ASP.NET Core 2.0 keluar.

Saat ini pandangan saya adalah ini: ada platform baru yang berfungsi hingga sekitar Juli 2018. Setelah itu: Saya tidak tahu apa-apa, saya hanya berharap apa yang saya butuhkan tersedia di netstandard/netcoreapp saat itu. Dan semoga saya punya cukup waktu untuk melakukan port sebelum dukungan berakhir. Saya tidak dibayar untuk berharap, saya dibayar untuk membuat keputusan platform untuk perusahaan kami, dan ASP.NET Core adalah taruhan yang buruk (bagi kami) dengan perubahan ini dan tidak ada tanggal untuk versi yang akan berfungsi.

Jadi satu tahun lagi adalah waktu yang cukup untuk semua orang? Itu bukan perasaan yang saya dapatkan dari utas ini.

Prioritas 1: Ini harus bekerja pada net461, tidak peduli apa ifdefs, perf yang ada.
Prioritas 2. Jika Anda dapat membuatnya 10x lebih cepat di .NET Core 2.0, maka itu luar biasa. Ini adalah alasan bagus bagi orang untuk memilih platform dan/atau bermigrasi jika mereka bisa.

Kuncinya di sini adalah bahwa untuk dukungan jangka panjang, ia masih harus bekerja pada kerangka kerja penuh, meskipun lebih lambat di sana.

Satu-satunya alasan .NET Framework berfungsi sebaik saat ini adalah karena kami sengaja mendukungnya. Itu tidak datang secara gratis, itu bukan "hanya lebih cepat pada inti", kami harus dengan sengaja merancang sistem sehingga memungkinkan untuk membuatnya bekerja di .NET Framework. Meskipun Anda belum melihatnya, kesenjangan fitur akan tumbuh antara 2 setelah kami memutuskan (dan kami telah memutuskan) untuk mengambil ketergantungan pada API yang belum ada di .NET Framework. Kita bisa melakukan apa yang @PinpointTownes katakan dan mulai melempar NotSupportedException ketika celah fitur itu muncul tapi IMO itu pengalaman yang sangat buruk.

Kami menghabiskan anggaran pengembangan yang besar untuk mem-porting aplikasi ASP.net MVC5 kami ke kerangka lengkap inti ASP.net agar berfungsi dengan baik dengan Azure Service Fabric. Seluruh proyek adalah multi-bulan di mana ada beberapa minggu yang didedikasikan untuk mem-porting aplikasi web kami (dan terus terang, bergulat dengan alat VS2015 yang canggung).

Satu-satunya alasan yang berhasil adalah karena kerangka kerja penuh didukung, karena kami saat ini menjalankan SignalR pada inti ASP.net (untuk keputusasaan @davidfowl ). Sejauh yang saya tahu, SignalR masih tidak didukung di Asp.net Core?

Kemudian kami menghabiskan sekitar satu minggu untuk bermigrasi ke alat VS2017 yang baru. Bagus.

_Perhatikan bahwa hingga saat ini tidak ada peningkatan sama sekali pada produk, hanya menyesuaikan bentuk kode agar sesuai dengan platform Microsoft dan persyaratan perkakas._

Sekarang Anda memberi tahu saya bahwa dalam 12 bulan saya harus melakukan lebih banyak upaya pengembangan tanpa fitur tanpa jaminan bahwa saya bahkan akan dapat melakukannya, tergantung pada sekelompok lambaian tangan dan harus mampu? Tidak, terima kasih.

Pertama, dapatkan semua yang bermerek Microsoft yang digunakan orang di ASP.net core full framework hari ini bekerja di ASP.net core saja. Kedua, cari tahu apa lagi (jika ada) yang akan menghalangi ekosistem dari mengadopsi inti ASP.net seperti yang diinginkan. Kemudian, dan baru kemudian, hentikan dukungan untuk Netfx seperti yang sedang dibahas.

Kita bisa melakukan apa yang @PinpointTownes katakan dan mulai melempar NotSupportedException ketika celah fitur itu muncul tapi IMO itu pengalaman yang sangat buruk.

Bukan itu yang saya katakan: ketika menggunakan kompilasi silang, ifdefs pasti harus menjadi opsi yang lebih disukai untuk mengecualikan API yang tidak tersedia pada platform tertentu, tetapi jika karena alasan apa pun Anda benar-benar HARUS memiliki tanda tangan API ini di publik kontrak, maka Anda dapat menggunakan NotSupportedException .

Saya tidak mengerti. Belum ada yang bergantung pada fitur di ASP.NET 2.0

Saya berharap sebagian besar pengembang sedang menunggu .NET Standard 2.0 yang stabil dan sangat kompatibel yang didukung oleh dependensi mereka sebelum mereka berkomitmen untuk bermigrasi ke ASP.NET Core. Mereka tidak akan mau mengadopsi .NET Core 1.1 sekarang karena mengetahui itu telah EOL'ed dan MS tidak memiliki sejarah yang baik dalam memberikan dukungan jangka panjang untuk versi DNX/.NET Core lama. Jika ada rilis LTS stabil yang sangat kompatibel yang dapat diadopsi oleh ekosistem lainnya dengan aman, perusahaan harus memiliki semua yang mereka butuhkan untuk menjalankan sistem mereka dan mereka tidak akan merasa berkewajiban untuk meningkatkan ke .NET Core vNext karena mereka akan memiliki semua yang mereka butuhkan. perlu di v2.0 dan ketika saatnya tiba, akan jauh lebih mudah untuk merencanakan migrasi mereka dari ASP.NET Core 2.0/.NET v4.6 ke versi .NET Core saja di masa mendatang.

@mythz

Saya pribadi lebih tertarik pada .NET Standard 2.0 yang stabil lebih dari fitur .NET Core-only masa depan mana pun karena saya ingin kembali ke pengembangan .NET di mana semuanya berfungsi kembali, perkakas tidak rusak, .NET yang populer. Semua paket .NET menyediakan dukungan untuk, penyebaran di sekitarnya dan solusi hosting dipoles dan ada banyak dokumen, posting, video, dan basis pengetahuan yang tersedia untuk ASP.NET Core yang stabil, tempat kami dapat mulai membangun solusi.

Setuju dengan semua yang ada di sana, tetapi saya tidak melihat bagaimana keputusan ini memengaruhi apa pun yang Anda katakan. Saya ingin semua hal yang sama 👍 .

Dengan kebebasan hanya harus mendukung 1 platform, Anda berpotensi menghadirkan fitur baru yang akan menarik pengembang untuk mengadopsi versi terbaru dan terhebat berikutnya dengan aliran fitur baru yang berkelanjutan, secara pribadi saya senang dengan fungsionalitas yang dimiliki ASP.NET sekarang dan seterusnya Saya lebih tertarik pada versi stabil di mana semuanya dipoles sehingga saya dapat kembali produktif lagi dan fokus pada pengembangan solusi daripada mengejar platform yang selalu bergerak.

Benar, bukankah itu ASP.NET Core 1.x? Jika dukungan diperpanjang pada 1.x tidakkah itu cukup? Kami hanya bisa memastikan bahwa ASP.NET Core 1. yang merupakan netstandard 1.x berjalan di .NET Core 2.0 (yang sudah dilakukan) dan mendukungnya untuk sekitar satu tahun lagi.

Bukan itu yang saya katakan: ketika menggunakan kompilasi silang, ifdefs pasti harus menjadi opsi yang lebih disukai untuk mengecualikan API yang tidak tersedia pada platform tertentu, tetapi jika karena alasan apa pun Anda perlu memiliki tanda tangan API ini dalam kontrak publik, maka Anda bisa pergi dengan NotSupportedException.

Saya bahkan tidak berbicara tentang mengekspos API publik. Saya berbicara tentang API yang perlu kita panggil yang tidak akan ada di netstandard. #ifdefs tidak membantu di sini. Kami hanya akan melempar saat celah bertambah.

@davidfowl Pertanyaan yang benar-benar valid - jawaban:

Maksud Anda dukungan berbayar atau maksud Anda kami akan memperbaiki masalah saat muncul?

Perbaikan aktif untuk masalah - apakah 1.x akan menerima perbaikan untuk semua hal yang kami rusak, atau akankah kami diminta untuk meningkatkan versi untuk perbaikan dalam beberapa kasus? (catatan: itu adalah pemutakhiran yang tidak dapat kami lakukan sampai perpustakaan kami seperti Layanan Direktori ada di sana ... Kami besar, kami cepat, kami akan menemukan celah dalam kerangka kerja. Kami memiliki untuk setiap rilis besar dan kecil selama bertahun-tahun. Dukungan sangat penting bagi kami.

Saya pikir apa yang Anda katakan adalah bahwa Anda ingin menggunakan versi terbaru dari ASP.NET Core

Tidak, saya ingin versi yang berfungsi dan jalur ke depan. Dengan 1.x, kami hanya memiliki paruh pertama. Sampai masalah ini, yang kedua agak diasumsikan.

Bagaimana versi revving ASP.NET Core memengaruhi itu?

Karena jika Anda menghentikan dukungan untuk kerangka kerja penuh, kami terpaksa membuat perubahan besar untuk tetap mendukung.

Jika kami menjatuhkan dukungan .NET Framework di 3.0 (seperti yang tampaknya dihindari orang di utas ini), bukankah Anda akan berada di jalan buntu yang sama?

Mungkin? Intinya adalah memiliki paritas dalam kasus penggunaan sebelum melakukan penyelaman. Ini karir saya, saya tidak bisa memberitahu perusahaan kami untuk melompat ketika pihak lain mungkin tidak mendukung kami. Itu hanya tidak bertanggung jawab di pihak saya. Jika kasus penggunaan kami didukung dalam jangka waktu 2.x, maka ada jalur yang jelas ke depan dan jauh lebih aman untuk bertaruh di ASP.NET Core.

Jadi satu tahun lagi adalah waktu yang cukup untuk semua orang?

Panjang waktu absolut tidak terlalu penting - itu harus kompatibilitas kasus penggunaan + waktu (IMO). Jika kasus penggunaan kami berfungsi hari ini (misalnya auth AD), maka 2 tahun sudah cukup, ya. Tapi saat ini bukan itu masalahnya, jadi menyetujui titik waktu yang sewenang-wenang dari sekarang tidak apa-apa, paling banter, terlalu dini.

Itu tidak datang secara gratis, itu bukan "hanya lebih cepat pada inti", kami harus dengan sengaja merancang sistem sehingga memungkinkan untuk membuatnya bekerja di .NET Framework. Meskipun Anda belum melihatnya, kesenjangan fitur akan tumbuh antara 2 setelah kami memutuskan (dan kami telah memutuskan) untuk mengambil ketergantungan pada API yang belum ada di .NET Framework.

Maka jangan tersinggung, tetapi mengapa tidak mengatakan itu saja dan menutup masalah? Pernyataan itu sepertinya tidak ada lagi yang perlu didiskusikan, dan waktu kita lebih baik dihabiskan di tempat lain. Jika bukan itu masalahnya, tolong jelaskan?

Masalah utamanya adalah kami tidak dapat memindahkan beban kerja kami ke netstandard hari ini , atau, seperti yang diusulkan saat ini, saat peluncuran. Jika apa yang sudah kita miliki tidak berfungsi, mengapa kita peduli dengan fitur baru? Tim terus berbicara tentang kinerja (dan itu luar biasa, sungguh), tetapi sesuatu yang tidak dapat saya gunakan dengan berlari cepat tidak terlalu menjadi masalah.

Sebagai pemimpin arsitektur/platform, saya harus memutuskan taruhan apa yang kami buat. Saat ini, ini adalah taruhan yang buruk. Ketika versi 1 mendukung Anda tetapi versi 2 tidak, tetapi semoga suatu hari nanti , itu adalah pertaruhan yang sangat buruk dengan waktu dan uang orang lain. Setidaknya bagi kami, kami memilih .NET untuk fitur, ekosistem, dan dukungannya. Saat ini, dalam kata baru kami telah beralih dari ketiganya menjadi 1. Ekosistemnya belum ada (permukaan API, lib), dan dukungannya jauh lebih pendek daripada yang biasa kami lakukan, tanpa jalur peningkatan yang dijamin dan jumlah waktu yang tidak diketahui untuk melakukannya.

@jahmai

Satu-satunya alasan yang berhasil adalah karena kerangka kerja penuh didukung, karena kami saat ini menjalankan SignalR pada inti ASP.net (untuk keputusasaan @davidfowl ). Sejauh yang saya tahu, SignalR masih tidak didukung di Asp.net Core?

Bahkan SignalR 2 tidak didukung di ASP.NET Core (meskipun orang telah meretasnya untuk membuatnya berfungsi). SignalR masih dalam pengembangan dan bahkan tidak akan keluar dengan ASP.NET Core 2.0, itu akan datang nanti.

Sekarang Anda memberi tahu saya bahwa dalam 12 bulan saya harus melakukan lebih banyak upaya pengembangan tanpa fitur tanpa jaminan bahwa saya bahkan akan dapat melakukannya, tergantung pada sekelompok lambaian tangan dan harus mampu? Tidak, terima kasih.

Apakah ada fitur yang Anda butuhkan di ASP.NET Core 2.0? Atau apakah Anda hanya berspekulasi bahwa pada akhirnya Anda harus memutakhirkan ke ASP.NET Core berikutnya dan pada saat itu semuanya tidak akan berfungsi di .NET Framework?

Pertama, dapatkan semua yang bermerek Microsoft yang digunakan orang di ASP.net core full framework hari ini bekerja di ASP.net core saja. Kedua, cari tahu apa lagi (jika ada) yang akan menghalangi ekosistem dari mengadopsi inti ASP.net seperti yang diinginkan. Kemudian, dan baru kemudian, hentikan dukungan untuk Netfx seperti yang sedang dibahas.

Sebagai bagian dari netstandard 2.0, banyak pekerjaan yang telah dilakukan untuk mengidentifikasi API penting untuk dibawa kembali sehingga perpustakaan yang menargetkan .NET Framework sebagian besar kompatibel dengan biner. Tentu saja ada area yang tidak berfungsi seperti WCF, WPF, dll. Tetapi ini akan membantu ketika kami melakukan riset dan ~ 60% perpustakaan kompatibel dengan API dengan netstandard 2.0 (koreksi saya jika saya salah pada nomor itu @terrajobst) dan mungkin hanya bekerja pada .NET Core 2.0.

Benar, bukankah itu ASP.NET Core 1.x? Jika dukungan diperpanjang pada 1.x tidakkah itu cukup?

Saya berharap .NET Standard 2.0 akan menjadi platform stabil yang menjembatani kompatibilitas dengan .NET 4.x sehingga lebih masuk akal dukungan LTS akan ada di sekitar itu. Tidak ada yang mengharapkan 1.1/.NET v4.x menjadi EOL'ed mid-release sehingga akan terhormat untuk mengumumkan LTS pada versi terbaru saat dirilis, tidak menarik dukungan .NET 4.x sebelum dirilis, tidak seseorang melakukan LTS dalam retrospektif ke versi lama seperti itu.

Saya tahu kami memelihara paket .NET Core kami dalam paket *.Core terpisah sehingga kami dapat tetap menggunakan irama rilis terpisah yang mengikuti versi .NET Core terbaru saat kami bergabung ke dalam paket NuGet utama artinya kami berkomitmen untuk rilis stabil yang akan kami dukung secara resmi, jadi kami harus sangat yakin bahwa kami memiliki versi yang dapat kami dukung untuk masa mendatang yang saya harapkan dari .NET Standard 2.0, bukan .NET Standard saat ini 1.1/1.3/1.6 campuran. Saya ingat ada juga waktu di mana akan ada 1.7/8 stop gap rilis yang tidak kompatibel dengan 2.0 yang melanggar ekspektasi versi .NET Standard yang bukan merupakan sinyal dari platform yang stabil.

Saya sudah cemas mengharapkan .NET Standard 2.0 ditakdirkan untuk menyediakan banyak dicari luas permukaan yang sangat kompatibel dan stabilitas yang sangat dibutuhkan.

Bahkan SignalR 2 tidak didukung di ASP.NET Core (meskipun orang telah meretasnya untuk membuatnya berfungsi). SignalR masih dalam pengembangan dan bahkan tidak akan keluar dengan ASP.NET Core 2.0, itu akan datang nanti.

Tidak yakin bagaimana Anda memaksudkan pernyataan itu, tetapi saya merasa itu hanya memperkuat kekhawatiran saya.

Apakah ada fitur yang Anda butuhkan di ASP.NET Core 2.0? Atau apakah Anda hanya berspekulasi bahwa pada akhirnya Anda harus memutakhirkan ke ASP.NET Core berikutnya dan pada saat itu semuanya tidak akan berfungsi di .NET Framework?

Saya ingin pindah ke netstandard2 di beberapa titik karena suatu alasan. Saya harus pindah untuk memindahkan aplikasi web saya ke asp.net core 2 untuk itu, bukan?

Sebagai bagian dari netstandard 2.0, banyak pekerjaan yang telah dilakukan untuk mengidentifikasi API penting untuk dibawa kembali sehingga perpustakaan yang menargetkan .NET Framework sebagian besar kompatibel dengan biner. <...>

Tentu, dan saya suka apa yang dilakukan dengan netstandard, tetapi jika ada sesuatu yang hilang dari netstandard, Anda dapat mengatasinya karena Anda dapat menargetkan kerangka kerja penuh dalam aplikasi yang membutuhkannya. Kami sekarang memiliki beberapa pustaka netstandard 1.3 murni (sumber kami) yang dibagikan di: Xamarin.iOS, Xamarin.Android, net46, Asp.net core 1.1 - karena kami dapat melengkapi fungsionalitas yang hilang di netstandard dengan pustaka penargetan kerangka kerja tertentu, termasuk hal-hal net46 di aplikasi web inti asp.net kami.

Alasan _ only _ kami memiliki pustaka standar bersih ini adalah karena kami perlu mem-porting aplikasi web besar kami (seperti yang saya sebutkan sebelumnya). Saya _suka_ tidak perlu memperluas basis kode khusus platform kami untuk platform lain, dan sebagai gantinya terus naik ke rantai standar bersih. Saya benar-benar tidak ingin terjebak di netstandard 1.3 karena tidak ada jalur untuk pindah ke asp.net core 2.

Perbaikan aktif untuk masalah - apakah 1.x akan menerima perbaikan untuk semua hal yang kami rusak, atau akankah kami diminta untuk meningkatkan versi untuk perbaikan dalam beberapa kasus? (catatan: itu adalah pemutakhiran yang tidak dapat kami lakukan sampai perpustakaan kami seperti Layanan Direktori ada di sana ... Kami besar, kami cepat, kami akan menemukan celah dalam kerangka kerja. Kami memiliki untuk setiap rilis besar dan kecil selama bertahun-tahun. Dukungan sangat penting bagi kami.

Saya tidak berpikir ada masalah dengan dukungan. Saya sebenarnya tidak berpikir ini akan menjadi masalah besar dan jika itu membuat orang merasa lebih percaya diri dalam bertaruh maka mungkin ada baiknya memperluas dukungan untuk 1.x ke jangka waktu yang lebih lama.

Tidak, saya ingin versi yang berfungsi dan jalur ke depan. Dengan 1.x, kami hanya memiliki paruh pertama. Sampai masalah ini, yang kedua agak diasumsikan.

Itu hanya berarti Anda harus tetap menggunakan 1.x sampai semua dependensi Anda di-porting, bukan?

@NickCraver Semua keluhan Anda berbicara tentang hal-hal yang hilang di .NET Core daripada ASP.NET Core. Dalam .NET Core 1.x dan ASP.NET Core 1.x, 2 entitas tersebut dikirimkan bersama tetapi sepenuhnya dipisahkan. Saya belum pernah mendengar satu alasan pun untuk ingin menggunakan ASP.NET Core 2.0 secara khusus selain kekhawatiran yang valid tentang v1 yang mendukung sesuatu dan v2 tidak mendukungnya. Saya pikir kita akan melakukan diskusi yang sama persis dalam setahun jika ada alasan lain Anda tidak dapat melakukan port ke .NET Core saja (mungkin selama pengembangan ASP.NET Core pada kerangka kerja penuh Anda mengambil beberapa dependensi baru yang tidak akan pernah porting sebagai contoh).

Maka jangan tersinggung, tetapi mengapa tidak mengatakan itu saja dan menutup masalah? Pernyataan itu sepertinya tidak ada lagi yang perlu didiskusikan, dan waktu kita lebih baik dihabiskan di tempat lain. Jika bukan itu masalahnya, tolong jelaskan?

Saya di sini menjawab dan membalas karena saya mencoba mencari tahu mengapa kita perlu mendukung .NET Framework jika demikian, untuk berapa lama. Saya masih mendapatkan getaran campuran di utas ini tentang kerangka waktu itu. Juga ada ketakutan umum yang dapat saya pahami tentang "diturunkan ke ASP.NET Core 1.x" tetapi tidak ada yang konkret dalam hal fitur spesifik yang diperlukan di 2.x.

Salah satu hal utama yang saya suka tentang menggabungkan .NET Core dan ASP.NET Core adalah bahwa ia memecahkan beberapa kegilaan versi dan penamaan. Banyak orang bahkan tidak tahu ASP.NET Core berjalan di .NET Framework (bahkan membingungkan pendatang baru ke tumpukan). Yang mengatakan, kami memiliki banyak pelanggan dengan banyak kebutuhan yang berbeda dan kami mendengarkan umpan balik mereka.

@mythz

Saya sudah cemas mengharapkan .NET Standard 2.0 ditakdirkan untuk menyediakan banyak dicari luas permukaan yang sangat kompatibel dan stabilitas yang sangat dibutuhkan.

Tentu, tapi seperti yang saya katakan, ASP.NET Core, .NET Core dan .NET Standard di 1.x benar-benar dipisahkan. Anda dapat menggunakan pustaka .NET Standard apa pun pada versi .NET Core apa pun yang mendukungnya. Jadi jika .NET Core 2.0 adalah LTS baru, kami masih dapat menyatakan bahwa ASP.NET Core 1.x didukung di dalamnya.

@jahmai

Saya ingin pindah ke netstandard2 di beberapa titik karena suatu alasan. Saya harus pindah untuk memindahkan aplikasi web saya ke asp.net core 2 untuk itu, bukan?

Tidak, itu tidak benar. Anda dapat pindah ke netstandard 2 kapan pun Anda mau tanpa memindahkan aplikasi web Anda ke ASP.NET Core 2.0.

Satu-satunya alasan kami memiliki pustaka standar bersih ini adalah karena kami perlu mem-porting aplikasi web besar kami (seperti yang saya sebutkan sebelumnya). Saya ingin tidak perlu memperluas basis kode khusus platform kami untuk platform lain, dan sebagai gantinya terus naik ke rantai standar bersih. Saya benar-benar tidak ingin terjebak di netstandard 1.3 karena tidak ada jalur untuk pindah ke asp.net core 2.

Anda tidak perlu terjebak di netstandard 1.3. 2 hal tersebut tidak berhubungan.

Ketika versi 1 mendukung Anda tetapi versi 2 tidak tetapi _semoga suatu hari nanti_, itu pertaruhan yang sangat buruk....

Ini menurut saya inti masalahnya. Kami mendapat komentar bahwa _beberapa_ celah ( DirectoryService , dkk.) diketahui dan akan ditangani. Kami membutuhkan sesuatu yang lebih konkret dari itu.

Saya setuju dengan ASP.NET Core yang menargetkan .NET Core dan dengan kami kehilangan kapal 2.0 jika roadmap jelas tentang kapan kami dapat mengharapkan celah ini (dan celah mana) akan diatasi (sekali lagi, dengan asumsi ada cukup waktu untuk port sebelumnya 1.X menjadi tidak didukung).

Seperti yang terjadi saat ini, masalah yang kami blokir untuk WCF telah stagnan sejak Mei 2015 dan mungkin tidak akan pernah ditangani.. Meninggalkan kami secara efektif terdampar.

@davidfowl

Tidak, itu tidak benar. Anda dapat pindah ke netstandard 2 kapan pun Anda mau tanpa memindahkan aplikasi web Anda ke ASP.NET Core 2.0.

Bagus sekali. Dalam hal ini, selama Microsoft memastikan bahwa 1.x didukung (semua jenis perbaikan bug dan dukungan operasional) hingga menawarkan kepada pelanggan jalur migrasi 2.x yang tepat (misalnya SignalR), maka saya akan menunggu dengan nyaman sampai kami butuh asp.net core 2.

Itu hanya berarti Anda harus tetap menggunakan 1.x sampai semua dependensi Anda di-porting, bukan?

Benar, tetapi itu harus menjadi kerangka waktu yang diketahui. Kami tidak memiliki tanggal, satu-satunya hal yang kami telah diberitahu sejauh ini adalah "tidak di 2.0"...jadi itu tidak baik. Misalnya, System.DirectoryServices telah diminta sejak Pertengahan 2015, dan masih hilang namun sering diulang sebagai yang paling dicari oleh pengguna (diikuti oleh System.Drawing ). Mengatakan kami membawa .NET Standard 2.0 ke ~60% API paritas tetapi melewatkan bit yang diminta pengguna pasti mengirimkan sinyal campuran tentang apa yang penting.

Semua keluhan Anda berbicara tentang hal-hal yang hilang di .NET Core daripada ASP.NET Core.

Itu tidak benar. Saya membutuhkan bit yang perlu kita jalankan (misalnya AD auth) pada platform yang didukung. Hal yang hilang adalah dukungan dari yang terakhir. Dukungan untuk 1.x tentu menjadi perhatian utama saya. Kami tidak memiliki jalur maju yang didukung atau garis waktu apa pun ketika kami dapat mengharapkannya.

Saya pikir kita akan melakukan diskusi yang sama persis dalam setahun

Saya tidak berpikir itu masalahnya. Masalahnya adalah kami tidak dapat melakukan port hari ini . API tidak ada di sana. Selama tidak ada satu titik waktu pun yang bisa kami porting, diskusi tentang masa depan agak diperdebatkan. Saya berharap dukungan kerangka kerja penuh .NET di ASP.NET Core tidak digunakan lagi setelah ada paritas dan sebagian besar pengguna dapat pindah. Dan saya berharap rilis itu memiliki jangka waktu dukungan yang lama bagi orang-orang untuk pindah.

Jika DirectoryServices, Drawing, dll. masuk 2.x maka luar biasa. Rilis itu harus mendukung .NET Framework, dan menjadi rilis LTS. Dan 3.x harus menghentikan dukungan kerangka kerja penuh.

Salah satu hal utama yang saya suka tentang menggabungkan .NET Core dan ASP.NET Core adalah bahwa ia memecahkan beberapa kegilaan versi dan penamaan. Banyak orang bahkan tidak tahu ASP.NET Core berjalan di .NET Framework (bahkan membingungkan pendatang baru ke tumpukan). Yang mengatakan, kami memiliki banyak pelanggan dengan banyak kebutuhan yang berbeda dan kami mendengarkan umpan balik mereka.

Cukup adil, tetapi semua kegilaan di sana adalah sekunder dari "apakah itu berhasil?". Saat ini, itu adalah perusahaan no. ASP.NET dan .NET Core/Standard/apa pun mungkin 2 set hal di dalam Microsoft (dan saya benar-benar mengerti), tetapi untuk pengembang itu masih 1 platform. Sisi ASP.NET membutuhkan API agar berguna bagi banyak orang, dan mereka belum ada di sana. Langkah ini semakin mengurangi API yang tersedia. Tim ASP.NET mungkin mendapatkan yang mereka inginkan, tetapi dengan mengorbankan yang kita butuhkan.

@ctolkien @NickCraver

Ini menurut saya inti masalahnya. Kami telah mendapat komentar bahwa beberapa celah (DirectoryService, dkk.) telah diketahui dan akan diatasi. Kami membutuhkan sesuatu yang lebih konkret dari itu.

Benar, tetapi itu harus menjadi kerangka waktu yang diketahui. Kami tidak memiliki tanggal, satu-satunya hal yang kami telah diberitahu sejauh ini adalah "tidak di 2.0"...jadi itu tidak baik. Sebagai contoh, System.DirectoryServices telah diminta sejak Pertengahan 2015, dan masih hilang namun sering diulang sebagai yang paling dicari oleh pengguna (diikuti oleh System.Drawing).

Kesenjangan ini terkait dengan .NET Core itu sendiri dan saya dapat memahami kecemasan tidak mengetahui kapan dependensi tersebut akan tersedia dan itulah mengapa membantu kami memprioritaskan ini akan menjadi baik. Kabar baiknya adalah bahwa netstandard 2.0 dan netcoreapp2.0 meletakkan kerja kelompok untuk membuat perpustakaan lain lebih mudah untuk port. Saya berharap bahwa setelah kami mengirimkan 2.0, akan lebih mudah untuk memunculkan dependensi lain dengan mem-porting petak kode di atas basis kami yang sangat kompatibel.

Apakah OMSK akan berjalan di netcore 2? Itu akan menjadi penghalang besar bagi kami dan satu area yang belum pernah saya dengar.

@davidfowl Saya sangat berharap itu juga terjadi, tetapi saya tidak mempertaruhkan perusahaan kami untuk itu. Menjatuhkan dukungan sebelum itu terjadi, dan bukan setelahnya, saya sangat tidak setuju. Saya pikir ini terjadi dalam jangka waktu 3.x setelah API penting bagi banyak konsumen itu benar-benar valid. Melakukannya sebelum mereka siap hanya menghentikan adopsi kami.

Saya berada di jalur untuk mengadopsi 1.0 dengan asumsi bahwa 2.x (atau apa pun yang dikembangkan/diperbaiki secara aktif) akan mendukung kerangka kerja penuh hingga API kritis tersebut siap (saya serius - Anda tahu berapa banyak pekerjaan yang telah saya lakukan di perpustakaan ). Tetapi pada titik ini, saya tidak bisa melakukannya di Stack...itu adalah asumsi yang buruk. Saya tidak dapat dengan hati nurani memberi tahu tim kami untuk menggunakan .NET Core sementara masa depan port apa pun sangat tidak pasti. Saya benar-benar berharap saya bisa, tetapi itu tidak sebanding dengan risiko dan rasa sakit saat ini.

@NickCraver

Saya berharap dukungan kerangka kerja penuh .NET di ASP.NET Core tidak digunakan lagi setelah ada paritas dan sebagian besar pengguna dapat pindah. Dan saya berharap rilis itu memiliki jangka waktu dukungan yang lama bagi orang-orang untuk pindah.

Apa ukuran "sebagian besar pengguna" di sini? Apa daftar dependensi yang perlu dicakup hingga kami dapat menghentikan dukungan? Daftar Anda berbeda dari pengguna lain di daftar ini. Saya juga berharap beberapa orang akan mengatakan selamanya atau sampai .NET Core mencapai paritas .NET Framework (yang tidak realistis). Saya masih akan menyatakan bahwa ASP.NET Core 1.x cukup baik untuk tujuan itu dan kita harus melihat perluasan dukungan untuk itu sampai waktu tersebut.

Itu tidak benar. Saya membutuhkan bit yang perlu kita jalankan (misalnya AD auth) pada platform yang didukung. Hal yang hilang adalah dukungan dari yang terakhir. Dukungan untuk 1.x tentu menjadi perhatian utama saya. Kami tidak memiliki jalur maju yang didukung atau garis waktu apa pun ketika kami dapat mengharapkannya.

Komponen ASP.NET apa yang hilang untuk skenario ini? Ketika Anda mengatakan 1.x vs 2.x, akan berguna jika Anda menyebutkan ASP.NET Core vs .NET Core.

Jika DirectoryServices, Drawing, dll. masuk 2.x maka luar biasa. Rilis itu harus mendukung .NET Framework, dan menjadi rilis LTS. Dan 3.x harus menghentikan dukungan kerangka kerja penuh.

Saya menyebutkan ini sebelumnya, fitur ASP.NET Core apa yang Anda perlukan sehingga ASP.NET Core 1.x tidak cukup untuk ini?

ASP.NET dan .NET Core/Standard/apa pun mungkin 2 set hal di dalam Microsoft (dan saya benar-benar mengerti), tetapi untuk pengembang itu masih 1 platform

Setuju tetapi kita perlu menjernihkan FUD dalam diskusi ini sehingga kita dapat mengevaluasi dampaknya dengan benar. ASP.NET Core 1.x menargetkan .NET Standard 1.x (1.0 - 1.6) dan .NET Framework 4.5.1. Ini berarti dapat berjalan pada platform apa pun yang mendukung versi netstandard dan .NET Framework tersebut. Artinya ASP.NET Core 1.x akan berjalan di .NET Core 2.0.

@smbecker

Apakah OMSK akan berjalan di netcore 2? Itu akan menjadi penghalang besar bagi kami dan satu area yang belum pernah saya dengar.

Saya tidak tahu apa itu. Apakah ini https://msdn.microsoft.com/en-us/library/ff798388.aspx? Jika demikian, tidak ada pekerjaan yang dilakukan untuk mendukungnya secara eksplisit. Ini mungkin hanya bekerja berdasarkan kompatibilitas .NET Framework di .NET Core 2.0 tetapi dugaan saya adalah bahwa itu tidak akan pernah di-porting ke .NET Core (hanya berdasarkan 5 menit saya melihatnya), tetapi saya bisa saja salah.

Apa ukuran "sebagian besar pengguna" di sini? Apa daftar dependensi yang perlu dicakup hingga kami dapat menghentikan dukungan? Daftar Anda berbeda dari pengguna lain di daftar ini. Saya juga berharap beberapa orang akan mengatakan selamanya atau sampai .NET Core mencapai paritas .NET Framework (yang tidak realistis). Saya masih akan menyatakan bahwa ASP.NET Core 1.x cukup baik untuk tujuan itu dan kita harus melihat perluasan dukungan untuk itu sampai waktu tersebut.

Mari kita mulai dengan API teratas yang hilang - itulah yang menyebabkan pemblokiran bagi kebanyakan orang. Bagi kami, itu DiretoryServices, yang merupakan nomor 1. Jika itu tidak ada, itu pertanda buruk bagi komunitas. Saya setuju daftarnya berbeda, tetapi jika kita bahkan tidak memasukkan nomor 1 ...

Komponen ASP.NET apa yang hilang untuk skenario ini? Ketika Anda mengatakan 1.x vs 2.x, akan berguna jika Anda menyebutkan ASP.NET Core vs .NET Core.

Saya menyebutkan ini sebelumnya, fitur ASP.NET Core apa yang Anda perlukan sehingga ASP.NET Core 1.x tidak cukup untuk ini?

Maksud saya dukungan untuk ASP.NET Core terbaru yang mendukung Full Framework (dan oleh karena itu perpustakaan yang saya butuhkan). Saya harap itu 2.x, seperti yang kami inginkan modul, halaman pisau cukur, dll. Kami menggunakan banyak fitur 2.x. Tapi sepertinya satu-satunya pilihan kami adalah 1.x saat ini. Kami tidak dapat melakukan lompatan dari ASP.NET 5 ke ASP.NET Core dan dari kerangka kerja penuh dengan semua lib kami yang berfungsi ke netcoreapp dalam 1 langkah. Ini terlalu banyak. Ini terlalu mahal. Ini terlalu berisiko. Dan sekarang kami tidak yakin apakah kami dapat melakukan langkah yang mahal dan berisiko itu di dalam jendela dukungan. Itu situasi yang buruk - sangat buruk sehingga lebih baik tidak bergerak (seperti yang terjadi hari ini). Saya pikir itu sangat disayangkan.

Komponen ASP.NET apa yang hilang untuk skenario ini? Ketika Anda mengatakan 1.x vs 2.x, akan berguna jika Anda menyebutkan ASP.NET Core vs .NET Core.

• Kecuali jika ada cara untuk menangani otentikasi/kueri AD melalui beberapa paket Microsoft.Authentication.* NuGet, maka itu adalah satu hal besar. Saat ini saya berada di kapal yang sama, tetapi karena saya menjalankan .NET Core 1.1 di atas .NET 462, saya dapat melakukannya. Di luar itu, bagaimana saya bisa menanyakan grup AD apa pun, metadata melalui cara yang didukung? Saya telah melihat di repo corefx bahwa ada banyak pekerjaan yang terjadi pada System.DirectoryServices , jadi saya senang tentang itu setidaknya.

• System.Data.Common.DbDataAdapter / SqlClient.SqlDataAdapter . Saat ini, saya hanya dapat mengaksesnya saat menjalankan .NET Core di atas .NET Framework penuh. Saya kira ini lebih merupakan hal yang nyaman, karena saya masih dapat menggunakan DbDataReader / SqlDataReader .

Pada dasarnya saya perlu tahu bahwa akan ada jaminan BEBERAPA cara yang didukung untuk menangani Otentikasi AD saat menggunakan ASP.NET Core 2.x, tanpa memerlukan .NET Framework penuh.

Saya telah banyak memikirkan hal ini hari ini dan saya menemukan bahwa kekhawatiran saya berbeda dari kebanyakan yang ada di sini (bukan karena kekhawatiran itu tidak sama pentingnya, jika tidak lebih dari itu).

Saya masih terjebak dalam kasus penggunaan menggunakan paket ASP.NET Core pada netstandard . Sampai masalah ini saya berasumsi (mungkin salah) bahwa netstandard adalah target de-facto untuk perpustakaan. Dengan kata lain, perilaku yang dimaksudkan untuk penulis perpustakaan adalah menargetkan netstandard kecuali ada alasan yang perlu dan kuat untuk tidak melakukannya. Ini memastikan tidak hanya kompatibilitas dengan Framework tetapi platform lain seperti Xamarin dan UWP. Pekerjaan pada .NET Standard 2.0 tampaknya mendukung hal ini dengan mencoba menyatukan area permukaan API dari berbagai runtime menjadi target umum yang tidak perlu dipikirkan.

Bagi saya, perubahan ini menandakan sesuatu yang berbeda. Memang, pada akhirnya ASP.NET Core hanyalah sebuah perpustakaan dan mungkin memiliki "alasan yang perlu dan kuat" untuk tidak mendukung area permukaan netstandard yang umum. Tapi itu juga salah satu perpustakaan .NET yang dikembangkan Microsoft yang paling terlihat dan dengan mengatakan "kami menginginkan yang terbaru dan terbaik sehingga kami akan berhenti mendukung netstandard " itu memberi sinyal kepada semua pengembang perpustakaan lainnya (atau di setidaknya itu berlaku untuk saya) bahwa mungkin mereka harus berhenti berusaha keras untuk mendukung netstandard dan mulai menargetkan runtime Core. Mengapa repot-repot dengan semua hal kompatibilitas ketika Microsoft bahkan tidak terlalu peduli tentang itu? .NET Core 4 lyfe. Dan mungkin itu yang terbaik - ini tentu berbeda dari yang saya pikir kami tuju dengan beberapa runtime dan sebagian besar area permukaan API terpadu.

Kekhawatiran ini semakin dalam ketika mempertimbangkan bahwa ASP.NET Core berisi banyak, banyak perpustakaan yang berguna di luar konteks ASP.NET secara langsung. Mungkin salah untuk berasumsi bahwa itu pernah dimaksudkan untuk digunakan secara terpisah, tetapi akan sangat memalukan untuk kehilangannya. Penulis perpustakaan yang ingin menggunakannya harus memutuskan untuk mengalihkan penargetan mereka sendiri ke .NET Core juga atau tetap menggunakan netstandard dan kehilangan akses ke sana. Saya menduga banyak yang akan memilih yang pertama, dukungan perpustakaan yang terpecah-pecah lebih lanjut untuk platform alternatif. Setidaknya jika saya mengerti komentar di sini bahwa menargetkan platform yang berbeda untuk perpustakaan pendukung terlalu sulit.

Akhirnya, saya agak (meskipun sedikit kurang) khawatir tentang komentar di sini bahwa segera mungkin API baru akan ditambahkan ke Core untuk rev dalam hubungannya dengan ASP.NET. Khususnya bahwa API baru tersebut mungkin tidak akan pernah berhasil masuk ke netstandard atau .NET Framework. Saya tentu mengerti bahwa mungkin ada beberapa hal menarik yang dapat dilakukan jika masalah warisan dan kompatibilitas dihilangkan atau dilonggarkan. Tapi sejujurnya, saya mendapat kesan bahwa tim Inti ASP.NET sering di depan sana. Itu tidak selalu merupakan hal yang buruk, tetapi juga menyebabkan sejumlah keputusan yang lebih luas yang harus berjalan kembali. Mau tidak mau saya bertanya-tanya apakah ini, dan evolusi cepat berikutnya dari runtime Core, akan menghasilkan retakan besar pada rangkaian runtime dari waktu ke waktu (dan sekali lagi, bukan hanya Windows/Framework yang akan ditinggalkan - ada juga Xamarin, Mono, UWP, dll).

Seluruh utas ini telah menyebabkan saya mengarahkan kembali pemahaman saya tentang masa depan .NET di sekitar .NET Core alih-alih netstandard . Mungkin saya bersikap ekstrem dan itu akan melunak dalam beberapa minggu mendatang, atau mungkin itu bahkan posisi yang diinginkan dan itu semua untuk yang terbaik - bagaimanapun, saya saat ini tergoda untuk keluar dan menargetkan .NET Core untuk saya sendiri hal-hal dan hanya fokus pada itu maju dari semua yang saya baca di sini.

@NickCraver

Maksud saya dukungan untuk ASP.NET Core terbaru yang mendukung Full Framework (dan oleh karena itu perpustakaan yang saya butuhkan). Saya harap itu 2.x, seperti yang kami inginkan modul, halaman pisau cukur, dll. Kami menggunakan banyak fitur 2.x.

Saat ini 1.1.1 (tidak ada modul di 2.0), Razor Pages bagus, yang lain adalah SignalR. Itu adalah 2 hal yang saya lihat paling menyakitkan sebagai bagian dari ini.

Kami tidak dapat melakukan lompatan dari ASP.NET 5 ke ASP.NET Core dan dari kerangka kerja penuh dengan semua lib kami yang berfungsi ke netcoreapp dalam 1 langkah. Ini terlalu banyak. Ini terlalu mahal. Ini terlalu berisiko. Dan sekarang kami tidak yakin apakah kami dapat melakukan langkah yang mahal dan berisiko itu di dalam jendela dukungan. Itu situasi yang buruk - sangat buruk sehingga lebih baik tidak bergerak (seperti yang terjadi hari ini). Saya pikir itu sangat disayangkan.

Apakah itu? Perpindahan dari ASP.NET Core 1.x ke 2.x atau 3.x dengan asumsi dependensi Anda telah di-porting akan menjadi hal yang sepele. Jika Anda berencana untuk pindah ke ASP.NET Core secara umum, pindah ke 1.1 adalah langkah pertama yang baik dan Anda tidak akan menyimpan pekerjaan apa pun untuk menghindarinya.

@snickler

Pada dasarnya saya perlu tahu bahwa akan ada jaminan BEBERAPA cara yang didukung untuk menangani Otentikasi AD saat menggunakan ASP.NET Core 2.x, tanpa memerlukan .NET Framework penuh.

Sampai System.DirectoryServices didukung di .NET Core, lalu apakah ada alasan Anda tidak dapat menggunakan ASP.NET Core 1.x di .NET Framework?

Sampai System.DirectoryServices didukung di .NET Core, lalu apakah ada alasan Anda tidak dapat menggunakan ASP.NET Core 1.x di .NET Framework?

Itulah yang sedang saya lakukan saat ini. Saya hanya melihat ke depan dengan harapan bahwa saya tidak perlu khawatir tentang .NET Framework jika saya tidak perlu. Saat ini, ini membatasi saya untuk mesin Windows saya karena namespace System.DirectoryServices.AccountManagement tidak ada di Mono. Dalam hal yang sama, apakah akan ada System.DirectoryServices.AccountManagement tersedia di luar batasan Windows? Bagian kecil itu memaksa saya untuk melompat di antara mesin saat men-debug proyek MVC saya dan aplikasi Xamarin.iOS saya secara lokal.

Jika Anda berencana untuk pindah ke ASP.NET Core secara umum, pindah ke 1.1 adalah langkah pertama yang baik dan Anda tidak akan menyimpan pekerjaan apa pun untuk menghindarinya.

Saya sangat setuju, jika kami tahu dukungan ada di sana sampai kami meningkatkan ke platform lain yang berfungsi . Saat ini, kami tidak tahu kapan bit yang diperlukan akan tersedia di dunia .NET Core jadi menetapkan batas waktu sekarang dan tidak tahu kapan bit itu akan datang nanti adalah saya bertaruh pada sebuah janji. Itu masalah intinya. Jika kami memiliki rilis yang didukung dan tumpang tindih yang memungkinkan porting maka saya akan siap dan senang untuk berinvestasi. Jika dukungan dihentikan sebelum API ada, kami melompati celah karena keyakinan, dengan jumlah landasan yang tidak diketahui.

Saya terus merujuk DirectoryServices karena itulah yang saya tahu tidak berfungsi pada netcoreapp2.0 hari ini. Tentu saja akan ada hal-hal lain yang kita temukan yang jatuh di perahu yang sama. Kami membutuhkan ASP.NET Core + full framework + support selama beberapa tahun di beberapa platform. Dengan 1.x, kami tidak mendapatkan banyak keuntungan, kami sebenarnya mendapatkan sangat sedikit. Performa bukanlah argumen yang luar biasa karena kami telah merender halaman dalam ~18 md dan dikerdilkan oleh waktu transportasi. 2.0 namun, menawarkan beberapa item bagus. Halaman Razor dan prospek plugin membuatnya sangat menarik untuk porting. Sedemikian rupa sehingga dapat dibenarkan.

Saat ini, satu-satunya versi yang mendukung (1.1.x dengan dukungan yang lebih lama, yang saya harapkan setelah membaca utas ini) tidak layak untuk dipindahkan. Pada dasarnya akan banyak waktu dan usaha untuk sampai ke tempat kita hari ini. 2.x setidaknya menawarkan beberapa peningkatan yang layak dan kami ingin memanfaatkannya. Mereka membantu membenarkan biaya pindah.

Performa bukanlah argumen yang luar biasa karena kami telah merender halaman dalam ~18 md

Pada kata-kata kasar OT kecil, saya ingin tahu bagaimana Anda dapat membuat halaman dalam ~18ms @NickCraver . Itu luar biasa

@daveaglick

Saya masih terjebak dalam kasus penggunaan paket ASP.NET Core di netstandard. Sampai masalah ini saya berasumsi (mungkin salah) bahwa netstandard adalah target de-facto untuk perpustakaan. Dengan kata lain, perilaku yang dimaksudkan untuk penulis perpustakaan adalah menargetkan standar bersih kecuali ada alasan yang perlu dan kuat untuk tidak melakukannya. Ini memastikan tidak hanya kompatibilitas dengan Framework tetapi platform lain seperti Xamarin dan UWP. Pekerjaan pada .NET Standard 2.0 tampaknya mendukung hal ini dengan mencoba menyatukan area permukaan API dari berbagai runtime menjadi target umum yang tidak perlu dipikirkan.

Tidak ada yang berubah di sini. Sebenarnya banyak perpustakaan kami yang ingin kami jalankan di platform lain masih standar bersih. Jika Anda membaca kembali beberapa hal di atas:

• Microsoft.Extensions.* (Logging, DI, Konfigurasi, FIleProviders dll)
• kerangka kerja entitas
• Klien SignalR (mereka harus berjalan di .NET Framework, Xamarin, UWP dll).

.NET Standard adalah cara de facto untuk menulis perpustakaan yang berjalan di mana-mana. Penulis perpustakaan harus menargetkan standar net jika memungkinkan untuk mendapatkan jangkauan platform terluas. Penulis perpustakaan harus memutuskan apakah mereka ingin memiliki jangkauan atau tidak. Itu sebabnya perpustakaan seperti JSON.NET mendukung netstandard1.x dan .NET framework 2.0. Mereka bekerja ekstra untuk membuat segalanya "berfungsi" seperti yang disebutkan @JamesNK di atas.

ASP.NET Core menjauh dari netstandard di beberapa tempat lebih merupakan pernyataan bahwa API ini tidak dimaksudkan untuk aplikasi UWP dan kami tentu saja tidak mengujinya di sana (sebagai contoh). Itu juga mencoba untuk memperkuat bahwa .NET Core dan ASP.NET Core adalah satu produk yang versinya sama (karena memiliki Core dalam namanya). Dengan ASP.NET Core 1.x yang mendukung .NET Core dan .NET Framework, pesan itu sedikit kabur dan menyebabkan kebingungan bagi banyak orang (terutama pengembang baru) dan kami melakukannya untuk mengurangi masalah celah perpustakaan.

Kekhawatiran ini semakin dalam ketika mempertimbangkan bahwa ASP.NET Core berisi banyak, banyak perpustakaan yang berguna di luar konteks ASP.NET secara langsung. Mungkin salah untuk berasumsi bahwa itu pernah dimaksudkan untuk digunakan secara terpisah, tetapi akan sangat memalukan untuk kehilangannya. Penulis perpustakaan yang ingin menggunakannya harus memutuskan untuk mengalihkan penargetan mereka sendiri ke .NET Core juga atau tetap menggunakan standar bersih dan akses longgar ke sana. Saya menduga banyak yang akan memilih yang pertama, dukungan perpustakaan yang terpecah-pecah lebih lanjut untuk platform alternatif. Setidaknya jika saya mengerti komentar di sini bahwa menargetkan platform yang berbeda untuk perpustakaan pendukung terlalu sulit.

Saya kira itu masih standar bersih. Yang mana yang tidak?

Mau tidak mau saya bertanya-tanya apakah ini, dan evolusi cepat berikutnya dari runtime Core, akan menghasilkan retakan besar pada rangkaian runtime dari waktu ke waktu (dan sekali lagi, bukan hanya Windows/Framework yang akan ditinggalkan - ada juga Xamarin, Mono, UWP, dll).

Saya pikir netstandard akan berkembang, tetapi .NET Framework akan selalu menjadi yang terakhir untuk mendapatkan API baru (Xamarin dan Mono cukup cepat untuk menambahkan sesuatu).

@snickler

Itulah yang sedang saya lakukan saat ini. Saya hanya melihat ke depan dengan harapan bahwa saya tidak perlu khawatir tentang .NET Framework jika saya tidak perlu. Saat ini, ini membatasi saya untuk mesin Windows saya karena namespace System.DirectoryServices.AccountManagement tidak ada di Mono. Dalam hal yang sama, apakah akan ada System.DirectoryServices.AccountManagement yang tersedia di luar batasan Windows? Bagian kecil itu memaksa saya untuk melompat di antara mesin saat men-debug proyek MVC saya dan aplikasi Xamarin.iOS saya secara lokal.

Pastikan Anda mengajukan masalah seperti itu di dotnet/corefx. Dengan asumsi dependensi Anda akan di-porting (kecuali jika sangat populer) adalah hal yang salah untuk dilakukan.

@davidfowl Pertanyaan: Saya ingin Mengajukan -> Proyek Baru dengan ASP.NET Core 2.0 dan mengautentikasi terhadap AD. Apakah ini mungkin? Saya tidak bisa membayangkan pengiriman platform Microsoft tanpa kemampuan untuk melakukan ini.

Setuju dengan semua yang ada di sana, tetapi saya tidak melihat bagaimana keputusan ini memengaruhi apa pun yang Anda katakan. Saya ingin semua hal yang sama

Dengan menjatuhkan dukungan untuk .NET v4.x itu akan membunuh jalur migrasi populer dan memecah ekosistem .NET lebih jauh dan mencegah banyak pengembang dan organisasi untuk dapat mengadopsinya yang akan mengurangi kumpulan pengetahuan dan investasi komunitas yang lebih luas di ASP. .NET Core karena banyak pengembang .NET perlu mendukung basis kode ASP.NET v4.x yang ada tanpa batas waktu (yang mereka dibayar untuk bekerja penuh waktu).

Semakin kecil pangsa pasar yang dimiliki .NET Core, semakin rendah prioritas bagi pengelola perpustakaan untuk mendukungnya dan beberapa kemungkinan tidak akan pernah melakukannya jika mereka bekerja untuk organisasi yang tidak lagi dapat mempertimbangkan untuk bermigrasi ke ASP.NET Core karena this, yang pada gilirannya mempengaruhi orang lain tergantung pada paket mereka, dan seterusnya. Ini semua adalah efek samping dari peningkatan beban dalam mengadopsi ASP.NET Core, dengan tidak memiliki platform yang stabil, jaminan dukungan jangka panjang dan sekarang mematikan jalur migrasi yang populer.

Saya percaya semua orang di sini ingin ekosistem .NET berkembang tetapi tampaknya kami berselisih dengan tim MS tentang cara terbaik untuk mencapainya karena saya sangat yakin menjatuhkan .NET v4.x ini lebih awal sebelum jumlah yang diketahui, sangat kompatibel, rilis stabil LTS tersedia adalah kesalahan yang akan memiliki efek merugikan selama bertahun-tahun yang akan datang.

@davidfowl Terima kasih - komentar Anda sangat membantu. Saya (tampaknya salah) mengumpulkan bahwa sebagian besar/semua perpustakaan pendukung dipindahkan dari netstandard sebagai bagian dari perubahan ini. Saya menggunakan beberapa, dan tahu orang lain yang melakukannya juga, jadi mendengar bahwa mereka tidak adalah kabar baik.

@NickCraver jenis auth apa yang Anda gunakan terhadap AD hari ini? OpenIdConnect, WsFed, NTLM, lainnya?

@Tratcher AD auth, melalui DirectoryServices (kita perlu menanyakan keanggotaan grup, dll. - bit standar)

@mythz Saya pikir itu masuk akal dan saya pikir memperpanjang masa dukungan ASP.NET Core 1.x akan cukup untuk menutupi sebagian besar kasus.

Saya mengerti mengapa Anda harus membuat keputusan ini di beberapa titik, tetapi saya juga percaya itu terlalu dini dan akan lebih bahagia dengan:

• ASP.NET Core 2.x menjadi LTS dan terakhir untuk mendukung Kerangka Penuh (pasti karena kami sudah dalam pratinjau, Anda tidak terlalu jauh) dengan juga SignalR mengikuti di akhir tahun yang mendukungnya sehingga kerangka kerja target untuk membuat lompatan dari ASP.NET ke ASP.NET Core
• 3.x menjatuhkan dukungan untuk Kerangka Penuh dan dirilis saat dependensi teratas dimigrasikan

Hanya memperluas dukungan untuk ASP.NET Core 1.1 dalam pandangan saya tidak akan cukup karena platform itu tidak cukup matang/diadopsi untuk menjadi target bagi banyak migrasi ASP.NET (dalam kasus saya SignalR menjadi pemblokir).

Hanya untuk istirahat, saya mencoba menggunakan EntityFramework 6 - yang telah saya lihat digunakan secara besar-besaran di aplikasi ASP.NET Core 1.0 yang telah saya kerjakan - dengan preview2 .NET Core nightly build terbaru. Tebak apa...

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <NetStandardImplicitPackageVersion>2.0.0-*</NetStandardImplicitPackageVersion>
    <RuntimeFrameworkVersion>2.0.0-preview2-002093-00</RuntimeFrameworkVersion>
    <PackageTargetFallback>net45;net461</PackageTargetFallback>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="EntityFramework" Version="6.1.3" />
    <PackageReference Include="System.Configuration.ConfigurationManager" Version="4.4.0-*" />
  </ItemGroup>

</Project>

Berhenti berpura-pura rakitan yang dirancang dan dikompilasi untuk kerangka kerja lengkap akan bekerja dengan sempurna di .NET Core: kasus-kasus sepele (baca aplikasi hello world) mungkin akan berfungsi, tetapi dalam banyak kasus, Anda akhirnya akan diblokir oleh API yang hilang atau API yang tidak berfungsi .

Apa yang benar-benar mengerikan adalah Anda hanya akan menyadari bahwa itu tidak berfungsi saat runtime. Dalam beberapa kasus, itu bahkan tidak akan terlihat sama sekali. Misalnya, SqlClient .NET Core tidak mendukung pendaftaran transaksi ambient atau transaksi terdistribusi dengan TransactionScope : bahkan jika Anda menemukan cara untuk membuat EF 6 berfungsi, TransactionScope Anda tidak akan efektif sama sekali dan panggilan DB Anda tidak akan menggunakan tingkat isolasi yang Anda butuhkan.

Saya merasa perlu untuk menambahkan dua sen saya di sini sejauh keprihatinan saya dengan langkah ini. Kami memiliki aplikasi desktop yang utamanya adalah Windows Forms dengan beberapa area baru yang dikembangkan di WPF. Ada lebih dari 15 tahun upaya dalam aplikasi itu dan akan memakan waktu bertahun-tahun untuk benar-benar menjauh dari WinForms. Saya berharap itu tidak terjadi tetapi memang demikian. Kami telah bekerja untuk membangun lebih banyak modularitas ke dalam basis kode sehingga kami dapat menggunakan lapisan akses bisnis dan data di antarmuka web yang lebih baru dan aplikasi WinForms yang ada. Saya bermaksud untuk segera pindah ke ASP.NET Core untuk aplikasi web baru kami, tetapi seperti yang baru saja saya nyatakan, saya perlu menggunakan sebagian besar basis kode kami yang ada yang menargetkan .NET v4.6.x. Saya tahu pasti kita menggunakan System.Drawing dan System.Security.Cryptography. Kami juga banyak menggunakan TransactionScope dengan cara yang disebutkan di atas.

Saya sangat menantikan untuk mendapatkan beberapa manfaat dari ASP.NET Core seperti kemampuan untuk merangkum area aplikasi web kami menjadi rakitan terpisah tanpa harus bergantung pada MEF untuk menyatukan semuanya. Ada banyak alasan tambahan tetapi itu adalah hal yang membuatnya sangat bagus. Namun, jika saya mentransisikan aplikasi kami ke ASP.NET Core, saya kemungkinan besar akan terjebak pada 1.x di masa mendatang karena kami harus menjaga portabilitas pada kode backend kami dengan WinForms. Saya telah berfokus terutama pada produk Web jadi saya tidak dapat memberi tahu Anda di mana kami terhubung ke hal-hal seperti WMI, dll, dan jika itu berdampak pada pertanyaan tentang portabilitas, tetapi saya tahu kami berada dalam basis kode kami. Kami berada dalam fase yang sangat menarik sekarang dan hal terakhir yang ingin saya lakukan adalah mengembangkan semua versi Web dari fitur kami ke ASP.NET MVC 5 dan mengumpulkan banyak kode warisan baru yang perlu di-porting di beberapa usaha masa depan.

Saya yakin kita akan memiliki banyak penggunaan yang akan menjauhkan kita dari penargetan .NET Standard bahkan jika/ketika kita tidak lagi menggunakan WinForms. Kami adalah Mitra Microsoft dan kami bekerja secara langsung dengan Microsoft untuk produk kami dalam beberapa cara, jadi saya tidak ingin membahas terlalu detail tentang apa yang kami lakukan di sini, tetapi saya akan senang untuk berdiskusi lebih pribadi dengan @ shanselman atau @davidfowl jika Anda memerlukan detail lebih lanjut tentang apa yang kami lakukan. Saya juga akan berada di MS Build dan dapat bertemu dan berbicara dengan salah satu dari Anda di sana jika Anda hadir.

Saya pikir Anda belum mempertimbangkan perusahaan yang menggunakan tumpukan Anda dengan tantangan semacam ini. Namun, penafian penuh: Saya bermaksud menjalankan penganalisis portabilitas yang disebutkan sebelumnya untuk melihat di mana kita benar-benar terjebak karena kebutuhan untuk mempertahankan portabilitas itu dalam basis kode kita. Saya akan dengan senang hati memberi Anda daftar API .NET Framework apa pun yang gagal dalam pemeriksaan itu.

muahaha. Entah aku harus tertawa atau menangis...

Inilah laporan yang dihasilkan oleh alat analisis ApiPort untuk aplikasi EF 6 23 baris sepele saya yang tidak berfungsi:

Cross-compiling merupakan overhead yang harus diimbangi dengan kebutuhan pelanggan dan produk. Inilah sebabnya mengapa kami ingin mendapatkan umpan balik ini sehingga kami dapat lebih konkret mendefinisikan seperti apa lanskap bagi pelanggan kami dan kami saat kami terus mengembangkan ASP.NET Core bergerak maju.

Sebelum masalah ini dibuka, apakah ada proses umpan balik?

Kita semua berbicara tentang kerangka waktu dan dukungan untuk 1.1 tetapi fakta bahwa ASP.NET Core akan menjatuhkan kerangka kerja penuh sama sekali telah menjadi kejutan besar bagi saya.

Pemahaman saya adalah bahwa kerangka inti adalah permainan lintas platform, kerangka kerja baru yang terdiri dari subset kerangka kerja lengkap yang tidak digabungkan ke Windows. Rilis 2.0 adalah yang kita semua telah menunggu di mana kita mendapatkan sebagian besar kembali API.

ASP.NET Core adalah makanan anjing untuk kerangka kerja baru ini, kerangka kerja web baru yang bergantung pada area permukaan yang begitu kecil dari kerangka kerja API sehingga dapat berjalan di mana-mana.

Saya mengharapkan bahwa setelah kerangka inti membuat paritas yang dekat dengan kerangka kerja penuh, semua API baru akan ditambahkan ke standar bersih dan akhirnya membuatnya menjadi kedua kerangka kerja. Kita semua akan mulai menargetkan standar bersih dan semuanya akan menjadi pelangi dan unicorn.

Sekarang untuk menemukan ASP.NET bahkan tidak akan dogfood netstandard dan akan kerangka kerja khusus eh :/

@rohatsu

Hanya memperluas dukungan untuk ASP.NET Core 1.1 dalam pandangan saya tidak akan cukup karena platform itu tidak cukup matang/diadopsi untuk menjadi target bagi banyak migrasi ASP.NET (dalam kasus saya SignalR menjadi pemblokir).

Bagaimana jika SignalR bekerja pada ASP.NET Core 1.x? Apa lagi yang belum matang tentang platform yang Anda butuhkan?

@millman82 Terima kasih telah berbagi itu. Kedengarannya Anda akan terjebak pada versi sebelum dukungan .NET Framework dihentikan untuk sementara waktu. Jadi beberapa saran di sini di mana kami menjaga 2.x kompatibel dan 3.x akan menjatuhkannya bahkan mungkin tidak bekerja untuk Anda. Mengapa tidak tetap menggunakan ASP.NET Core 1.x? Apa yang hilang darinya yang Anda butuhkan di port Anda? Atau hanya kekhawatiran yang sama dengan @NickCraver (bahwa 2.x tidak mendukungnya membuat Anda gugup untuk bertaruh).

@jkells

Saya mengharapkan bahwa setelah kerangka inti membuat paritas yang dekat dengan kerangka kerja penuh, semua API baru akan ditambahkan ke standar bersih dan akhirnya membuatnya menjadi kedua kerangka kerja. Kita semua akan mulai menargetkan standar bersih dan semuanya akan menjadi pelangi dan unicorn.

Itu tidak terlalu jauh, hanya saja kehilangan komponen waktu. Pada akhirnya akan membuatnya menjadi semua kerangka yang masing-masing kapal sesuai jadwal mereka sendiri.

Sekarang untuk menemukan ASP.NET bahkan tidak akan dogfood netstandard dan akan kerangka kerja khusus eh :/

Sebagian masih menargetkan standar bersih seperti yang disebutkan beberapa kali di utas ini.

Mengapa tidak tetap menggunakan ASP.NET Core 1.x?

Anda tidak bisa - tidak ada dukungan 1 tahun sejak 2.0 turun (dengan asumsi 2.0 adalah LTS berikutnya).

@davidfowl Ini jelas merupakan bagian besar dari itu. Kami juga menggunakan OData dan SignalR di aplikasi web kami saat ini dan itu harus ada di ASP.NET Core sebelum kami dapat pindah. Namun, satu hal yang saya tidak ingin terjadi adalah terjebak dalam limbo ketika dukungan untuk ASP.NET Core 1.x dihentikan dan tidak ada jalur migrasi dengan bagian kerangka kerja yang kami gunakan yang saat ini tidak didukung. Saya memperkirakan ASP.NET Core menggantikan ASP.NET grosir. Mungkin ada di suatu tempat di ujung jalan tetapi itu akan datang. Mengetahui bahwa saya tidak suka menulis ulang UI kami sekarang di ASP.NET MVC 5 (kami memiliki beberapa hal di sana sekarang tetapi mudah untuk dipindahkan karena kecil) hanya untuk beberapa tahun kemudian menulis ulang lagi di ASP.NET Core setelah akhir masa pakai ASP.NET tiba.

Kami berpotensi menyiapkan diri untuk terbakar parah jika jalur migrasi itu tidak ada ketika EOL dari ASP.NET Core 1.x tiba jika diperpanjang untuk sementara jika kami menargetkan Core 1.x sekarang. Kami mungkin dapat menavigasi beberapa di antaranya dengan layanan mikro, namun, itu tentu saja memiliki kekhawatirannya sendiri.

@ctolkien

Anda tidak bisa - tidak ada dukungan 1 tahun sejak 2.0 turun (dengan asumsi 2.0 adalah LTS berikutnya).

Asumsikan sejenak bahwa itu tidak keluar dari dukungan ketika 2.0 turun. Apakah itu tidak cukup?

Namun, satu hal yang saya tidak ingin terjadi adalah terjebak dalam limbo ketika dukungan untuk ASP.NET Core 1.x dijatuhkan dan tidak ada jalur migrasi dengan bagian kerangka kerja yang kami gunakan yang saat ini tidak didukung

Ganti 1.x dengan 2.x pada kalimat tersebut. Apakah Anda berpikir bahwa dalam setahun semua dependensi Anda akan di-porting?

Ganti 1.x dengan 2.x pada kalimat tersebut. Apakah Anda berpikir bahwa dalam setahun semua dependensi Anda akan di-porting?

Tidak sama sekali, bagaimanapun, saya berharap bahwa ketika tidak lagi dapat menargetkan .NET Penuh mereka akan. Saya mengerti mengapa Anda ingin mendorongnya, tetapi saya tidak berpikir Anda dapat mengharapkan perusahaan untuk mengadopsi sesuatu yang akan kehilangan dukungan tanpa berarti transisi ke versi yang lebih baru karena dependensi yang hilang belum di-porting.

Saya tidak berpikir Anda dapat mengharapkan perusahaan untuk mengadopsi sesuatu yang akan kehilangan dukungan tanpa berarti transisi ke versi yang lebih baru karena dependensi yang hilang belum porting.

Mengapa itu akan jatuh dari dukungan? Di dunia hipotetis saya, kami akan mendukung ASP.NET Core 1.x di .NET Framework lebih lama.

Mengapa itu akan jatuh dari dukungan? Di dunia hipotetis saya, kami akan mendukung ASP.NET Core 1.x di .NET Framework lebih lama.

Pertanyaan saya berapa lama lagi? Juga, apakah tim cukup besar untuk membawa dependensi yang diperlukan seperti SignalR dan OData ke ASP.NET Core 1.x dan mempertahankan dukungan hingga semua dependensi yang hilang itu, pada kenyataannya, telah di-porting? Sepertinya itu melawan argumen yang dibuat sebelumnya tentang mengapa Anda ingin menjatuhkan .NET Dukungan penuh sekarang. Pertanyaan jujur...

Pertanyaan saya berapa lama lagi? Juga, apakah tim cukup besar untuk membawa dependensi yang diperlukan seperti SignalR dan OData ke ASP.NET Core 1.x dan mempertahankan dukungan hingga semua dependensi yang hilang itu, pada kenyataannya, telah di-porting? Sepertinya itu melawan argumen yang dibuat lebih awal tentang mengapa Anda ingin menjatuhkan .NET Dukungan penuh sekarang. Pertanyaan jujur...

Saya akan membuang nomor acak, 3 tahun. Tim ASP.NET tidak memiliki integrasi Odata, tim odata melakukannya, jadi saya tidak bisa menjawabnya. Adapun SignalR, saya pikir mungkin untuk menargetkan ASP.NET Core 1.x.

Masalah yang saya lihat adalah bahwa setiap orang memiliki kumpulan "ketergantungan yang hilang" yang berbeda yang membuat tidak mungkin untuk mempertimbangkan kapan bahkan "ok" untuk menjatuhkan dukungan .NET Framework untuk semua orang. Kemungkinan juga beberapa dari dependensi tersebut mungkin tidak pernah di-porting (seperti OMSK).
Tentu saja berada di kereta 1.x Anda akan mendapatkan perbaikan bug dan fitur kecil tetapi sebagian besar pekerjaan masih akan terjadi di utama terbaru dari ASP.NET Core.

Juga tidak ada yang mencegah Anda menggunakan .NET Core 2.0 atau .NET Standard 2.0 dengan ASP.NET Core 1.x. Saya hanya ingin memastikan semua orang menyadari hal itu karena konstanta utas ini menggabungkan ASP.NET Core dengan .NET Core (yang merupakan salah satu alasan kami ingin menargetkan .NET Core saja).

Masalah yang saya lihat adalah bahwa setiap orang memiliki kumpulan "ketergantungan yang hilang" yang berbeda yang membuat tidak mungkin untuk mempertimbangkan kapan bahkan "ok" untuk menjatuhkan dukungan .NET Framework untuk semua orang.

Libatkan sistem lingkungan untuk mencari tahu apa daftarnya (tidak, masalah ini bukan tempatnya). Jika itu adalah ketergantungan yang dimiliki Microsoft, port itu. Jika tidak, hubungi pemilik untuk memberi tahu mereka tentang rencana tersebut dan bantu dengan panduan migrasi (jika mereka tidak melakukan apa pun, bukan kesalahan Microsoft). Dalam waktu yang diperlukan untuk melalui proses ini, dukung ASP.net core 1.x. Saya tidak dapat melihat cara lain untuk mencapai tujuan Anda tanpa mengecewakan banyak orang. Ini adalah hal besar yang diusulkan yang membutuhkan perawatan dan perhatian tingkat tinggi untuk melakukan yang benar.

Secara pribadi, saya pikir ada lebih banyak kebingungan seputar .NET Framework vs .NET Standard vs .NET Core. Ketika saya melihat saya dapat menargetkan .NET Framework, saya tidak pernah berkata, "tetapi ini adalah ASP.NET Core jadi mengapa saya dapat menggunakan .NET Framework". Perbedaan antara di atas jauh lebih membingungkan bagi sebagian besar basis pelanggan Anda. Saya suka semua yang dilakukan ASP.NET Core. Juga suka arahan dengan .NET mengenai independensi platform. Saya hanya berpikir domain kebingungan tidak dinyatakan dengan benar. Saya akan mengatakan sebagian besar basis pengguna Anda akan memiliki sejumlah kode yang tidak portabel karena sifat dari apa yang dilakukannya dan API yang ditargetkan dalam Kerangka.

Preferensi saya adalah bekerja menuju paritas API dalam .NET Core dan .NET Standard dan .NET Framework. Juga, cari tahu mana yang harus ditargetkan oleh orang-orang. Seperti yang saya yakini telah dinyatakan sebelumnya, mungkin dengan cara yang sedikit berbeda, .NET Standard terasa seperti bandaid. Akhirnya, saya berharap .NET Core menjadi satu-satunya opsi "kerangka" dan ketika itu terjadi, .NET Framework dan .NET Standard pergi begitu saja. Saya sendiri, dan saya pikir sebagian besar yang telah berbicara sejak pengumuman tersebut, ingin dapat terus mendapatkan manfaat dari pekerjaan yang Anda lakukan di sisi ASP.NET Core tanpa memiliki kebebasan untuk menjalankan kode mereka di atas dari dihapus.

Saya pikir kasus yang dianggap luar biasa, seperti saya di mana saya memiliki ketergantungan pada hal-hal seperti WMI tidak luar biasa seperti yang tim pikirkan. Sekali lagi, saya akan melakukan penelitian dan melihat apa yang hilang (walaupun posting sebelumnya memberikan hasil portabilitas yang salah membuat saya sedikit khawatir dengan keakuratannya) dan saya dengan senang hati akan melaporkannya kepada Anda dalam media yang lebih pribadi.

Intinya, kami bersemangat tentang ini karena kami ingin menggunakannya.

Secara pribadi, saya pikir ada lebih banyak kebingungan seputar .NET Framework vs .NET Standard vs .NET Core. Ketika saya melihat saya dapat menargetkan .NET Framework, saya tidak pernah berkata, "tetapi ini adalah ASP.NET Core jadi mengapa saya dapat menggunakan .NET Framework". Perbedaan antara di atas jauh lebih membingungkan bagi sebagian besar basis pelanggan Anda. Saya suka semua yang dilakukan ASP.NET Core. Juga suka arahan dengan .NET mengenai independensi platform. Saya hanya berpikir domain kebingungan tidak dinyatakan dengan benar. Saya akan mengatakan sebagian besar basis pengguna Anda akan memiliki sejumlah kode yang tidak portabel karena sifat dari apa yang dilakukannya dan API yang ditargetkan dalam Kerangka.

Kami memiliki banyak pelanggan dan kami memiliki pengembang baru yang belum pernah melihat .NET dalam hidup mereka. Kami perlu melayani semua orang karena itulah yang kami coba lakukan sebagai Microsoft. Orang-orang yang menjalankan .NET Framework mengetahui, menyukai, dan memahaminya bekerja, jadi yakinlah Anda memahami bahwa ASP.NET Core berjalan di .NET Framework tetapi sebagai pengembang baru yang mendekati platform, saya berharap untuk tidak pernah menyebutkannya karena ini memperkeruh cerita dibandingkan dengan sesuatu seperti go atau node (yang memiliki cukup banyak 0 warisan pada saat ini).

Preferensi saya adalah bekerja menuju paritas API dalam .NET Core dan .NET Standard dan .NET Framework. Juga, cari tahu mana yang harus ditargetkan oleh orang-orang. Seperti yang saya yakini telah dinyatakan sebelumnya, mungkin dengan cara yang sedikit berbeda, .NET Standard terasa seperti bandaid. Akhirnya, saya berharap .NET Core menjadi satu-satunya opsi "kerangka" dan ketika itu terjadi, .NET Framework dan .NET Standard pergi begitu saja. Saya sendiri, dan saya pikir sebagian besar yang telah berbicara sejak pengumuman tersebut, ingin dapat terus mendapatkan manfaat dari pekerjaan yang Anda lakukan di sisi ASP.NET Core tanpa memiliki kebebasan untuk menjalankan kode mereka di atas dari dihapus.

Semua ini terjadi secara paralel. ASP.NET Core tidak berhenti bekerja pada fitur sampai "semuanya" di-porting ke .NET Core dari .NET Framework. ASP.NET akan terus berinovasi dan memanfaatkan API yang tersedia di .NET Core karena kami mengirimkannya sebagai bagian dari kotak yang sama.

Saya melihat beberapa ide yang sedang tren di utas ini dari:

• Saya ingin Anda mendukung .NET Framework selamanya.
• Saya ingin Anda mendukung .NET Framework hingga dependensi yang saya perlukan untuk aplikasi saya di-porting.
• Saya hanya perlu 1 tahun lagi, itu akan menjadi waktu yang cukup bagi saya untuk menghentikan dukungan .NET Framework (ASP.NET Core 3.x).

Ada juga fakta bahwa kami tidak menulis pengumuman (yang merupakan kesalahan kami) tetapi satu akan datang (saya berjanji, saya menyalahkan akhir pekan).

Saya juga tidak tahu seperti apa paritas API bagi kebanyakan orang di sini, tebakan saya berbeda untuk orang yang berbeda. .NET Framework adalah teknologi perusahaan yang solid, andal, berusia 15+ tahun yang terkait dengan Windows.
.NET Core dibuat untuk menulis layanan mikro lintas platform ringan yang modern dan perlahan-lahan berkembang menjadi lebih kompatibel sehingga porting library menjadi lebih mudah. Yang mengatakan, saya tidak tahu apa artinya mendekati .NET Framework dalam hal kompatibilitas atau apakah itu bahkan tujuan (awalnya tidak). Pada titik tertentu Anda tidak akan dapat menggunakan ASP.NET Core di atas .NET Framework dan akan ada beberapa ketergantungan yang tidak dapat ditulis ulang yang tidak kompatibel dengan .NET Core. Aplikasi perlu memperhitungkan hal itu ketika dirancang dengan mempertimbangkan ASP.NET Core (dalam waktu dekat).

Sehubungan dengan proyek yang saya kerjakan, periode dukungan yang lebih lama untuk 1.1 akan menjadi mitigasi yang layak. Sepertinya kami tidak dapat menghapus ketergantungan netfx dalam 1 tahun tetapi jauh lebih mungkin dengan +3 tahun yang Anda sarankan sebagai strawman. Akan sangat menyenangkan untuk memiliki rilis di mana semuanya datang bersama-sama pada level 2.0 terlebih dahulu - itulah titik di mana semuanya seharusnya menjadi lebih mudah untuk port! Saya hanya berbicara untuk satu organisasi tetapi "2.0 akan menjadi rilis LTS; 3.0 akan menjatuhkan netfx" pada dasarnya akan menjadi bisnis seperti biasa bagi kami alih-alih menjadi penyebab FUD.

Saya juga ingin mengulangi apa yang @PureKrome katakan tentang menghargai pertunangan ini, ini adalah diskusi yang sangat informatif.

Pada topik paritas - Saya sebelumnya berasumsi bahwa .net core tidak akan pernah mendekati tingkat kompatibilitas .net framework, tetapi ini baik-baik saja karena asp .net core akan terus mendukung keduanya.

Saya pikir sebagai komunitas kami pada dasarnya menggunakan .net core untuk menggunakan asp.net core, bukan untuk keuntungannya sendiri. Seperti yang Anda katakan, mereka adalah satu produk, dan saya menganggap inti clr sebagai bagian opsional dari produk itu dengan manfaat dan kerugian jika dipilih.

Setelah tidur di atasnya selama satu malam -

Saya pribadi berpikir itu adalah ide yang baik untuk meninggalkan kerangka .net lama dan menulis kerangka web terbaik untuk runtime modern.

Tetapi Anda tahu bahwa itu pasti berisiko dan Anda mungkin kehilangan beberapa pelanggan Anda di sini di sepanjang jalan (saya harap tidak - tetapi saya melakukan banyak konsultasi - dan .NET Core untuk banyak perusahaan di luar jangkauan sekarang - mari berharap 2.0 mengubah itu).

..dan ya - komunikasi seputar ini adalah (seperti biasa) sesuatu yang dapat Anda tingkatkan (versi paling sopan dari kalimat ini untuk orang Jerman) ;)

+1

Saya pribadi berpikir itu adalah ide yang baik untuk meninggalkan kerangka .net lama dan menulis kerangka web terbaik untuk runtime modern.

Saya sangat setuju. Harapan saya adalah bahwa wold ini telah menjadi perubahan bertahap, misalnya Kestrel menjatuhkan dukungan pertama untuk perf (hosting berbasis http.sys tersisa), kemudian mvc/* mengikuti untuk API dan peningkatan fungsionalitas saat porting / upaya pengujian kompatibilitas untuk netstandard2.0 dimulai.

Bagus sekali. Dalam hal ini, selama Microsoft memastikan bahwa 1.x didukung (semua jenis perbaikan bug dan >dukungan operasional) sampai ia menawarkan jalur migrasi 2.x yang tepat kepada pelanggan (misalnya SignalR), maka saya > nyaman menunggu waktu saya sampai kita membutuhkan asp.net core 2.

+1

dapat melakukan port ke .NET Core saja (mungkin selama pengembangan ASP.NET Core pada kerangka kerja penuh Anda mengambil beberapa dependensi baru yang tidak akan pernah di-porting sebagai contoh).

Setuju.
Saat ini saya pikir itu adalah keputusan yang baik. Saya pikir dalam skenario ideal kami membutuhkan dukungan lebih dari 1 tahun, saya tidak tahu mungkin 2-3 tahun, dan informasi tentang apa yang akan diangkut, untuk kepercayaan masyarakat.
Tidak ada dukungan .net 461.

@dasMulli

Saya sangat setuju. Harapan saya adalah bahwa wold ini telah menjadi perubahan bertahap, misalnya Kestrel menjatuhkan dukungan pertama untuk perf (hosting berbasis http.sys tersisa), kemudian mvc/* mengikuti untuk API dan peningkatan fungsionalitas saat porting / upaya pengujian kompatibilitas untuk netstandard2.0 dimulai.

Kami bahkan tidak menjalankan tes kinerja pada .NET Framework... Pengujian porting dan peningkatan ke .NET Core dan .NET Standard akan tetap terjadi, bahwa IMO tidak menentukan apakah dukungan .NET Framework dihentikan atau tidak. Jika ada, itu membuat kami fokus pada skenario itu karena itu satu - satunya target.

@gulbanana

Akan sangat menyenangkan untuk memiliki rilis di mana semuanya datang bersama-sama pada level 2.0 terlebih dahulu - itulah titik di mana semuanya seharusnya menjadi lebih mudah untuk port! Saya hanya berbicara untuk satu organisasi tetapi "2.0 akan menjadi rilis LTS; 3.0 akan menjatuhkan netfx" pada dasarnya akan menjadi bisnis seperti biasa bagi kami alih-alih menjadi penyebab FUD.

Mengapa Anda membutuhkan ASP.NET Core 2.0 (lupakan .NET Standard dan .NET Core 2.0)?

Kami tidak terlalu membutuhkan fitur di asp.net core 2.0. Saya sangat ingin memiliki proses pembuatan dan interop yang lebih sederhana yang disertakan dengan gelombang 2.0.. akankah asp.net core 1.1, jika berjalan di netcoreapp2.0, dapat menggunakan pustaka netstandard2.0? Apakah itu akan dianggap sebagai skenario 'standar' dan didukung daripada sesuatu yang tidak diuji atau diperhatikan oleh siapa pun?

Pada dasarnya jika 1.1 menjadi LTS, saya khawatir masalah akan ditutup delapan belas bulan dari sekarang dengan 'yah, Anda dapat melakukan ini menggunakan api 2.0'..

Kami tidak terlalu membutuhkan fitur di asp.net core 2.0. Saya sangat ingin memiliki proses pembuatan dan interop yang lebih sederhana yang disertakan dengan gelombang 2.0.. akankah asp.net core 1.1, jika berjalan di netcoreapp2.0, dapat menggunakan pustaka netstandard2.0? Apakah itu akan dianggap sebagai skenario 'standar' dan didukung daripada sesuatu yang tidak diuji atau diperhatikan oleh siapa pun?

Tentu saja itu akan berhasil. Seperti yang telah saya katakan selama ini 3 hal benar-benar dipisahkan hari ini. Berikut adalah contoh proyek yang menjalankan ASP.NET Core 1.1 di .NET Core 2.0 menggunakan versi System.Configuration API yang telah di-porting ke paket .NET Standard 2.0:

https://github.com/davidfowl/AspNetCore1OnNetCore2

Saya akan lebih senang menerima ini jika ada lapisan interop otomatis antara .NET Core dan .NET Framework (bukan yang saat ini yang dapat memberikan pengecualian saat runtime, dan bukan panggilan WebAPI internal yang dibuat sendiri) - semacam pembungkus ("WowNET"?) yang akan memaksa kita untuk menyimpan kode 4.6-dependen di .dlls terpisah tetapi memungkinkan menjalankan warisan dengan mengorbankan kinerja (yang dalam hal aplikasi LOB bukan perhatian utama). Apakah menurut Anda ini secara teknis mungkin?

Saya juga bertanya-tanya apakah perubahan ini berarti bahwa kerangka kerja penuh itu sendiri mendekati akhir masa pakainya dan tidak akan melakukan peran penting lainnya selain menjadi komponen warisan setelah sebagian besar API dipindahkan ke .NET Standard.

Pada dasarnya jika 1.1 menjadi LTS, saya khawatir masalah akan ditutup delapan belas bulan dari sekarang dengan 'yah, Anda dapat melakukan ini menggunakan api 2.0'..

Itu selalu menjadi perhatian. Jawabannya selalu "tergantung". Perbaikan bug ditimbang sesuai dan fitur-fitur besar cenderung lebih sering masuk ke dalam ember itu daripada tidak.

@rohatsu

Saya akan lebih senang menerima ini jika ada lapisan interop otomatis antara .NET Core dan .NET Framework (bukan yang sekarang yang dapat memberikan pengecualian saat runtime, dan bukan panggilan WebAPI internal yang dibuat sendiri) - semacam pembungkus ("WowNET"?) yang akan memaksa kami untuk menyimpan kode yang bergantung pada 4.6 di .dll yang terpisah tetapi memungkinkan untuk menjalankan warisan dengan mengorbankan kinerja (yang dalam hal aplikasi LOB bukanlah perhatian utama). Apakah menurut Anda ini secara teknis mungkin?

Agak seperti ini https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root tetapi untuk .NET Core dan .NET Framework. Kami melakukan sesuatu yang sangat mirip ketika kami ASP.NET mendukung Helios, shim .NET Framework yang digunakan untuk meningkatkan coreclr di IIS. Peretasan untuk membuatnya bekerja cukup buruk meskipun itu adalah campuran COM dan meneruskan struktur ke metode Utama melalui string[] args. Semua secara teknis layak sekalipun. Saya tidak yakin kesetiaan seperti apa yang Anda harapkan, karena mereka bukan runtime yang sama dan Anda tidak dapat meneruskan objek bolak-balik. Anda juga akan menjalankan 2 GC, 2 Jits ton lebih dll dalam proses yang sama dan saya tidak yakin apa yang Anda peroleh dari melakukan sesuatu di luar proc.

Saya juga bertanya-tanya apakah perubahan ini berarti bahwa kerangka kerja penuh itu sendiri mendekati akhir masa pakainya dan tidak akan melakukan peran penting lainnya selain menjadi komponen warisan setelah sebagian besar API dipindahkan ke .NET Standard.

Jauh dari. .NET Framework berkembang dan dikirimkan dengan kecepatan windows karena merupakan komponen windows. Kami baru saja merilis .NET Framework 4.7 (https://blogs.msdn.microsoft.com/dotnet/2017/04/05/announcing-the-net-framework-4-7/) juga dengan banyak fitur baru. Faktanya adalah .NET Core dapat dan akan dikirimkan lebih cepat karena tidak terikat dengan hal lain, jadi API, fitur runtime, dll akan muncul terlebih dahulu di sana. Itu tidak berarti hal-hal pada akhirnya tidak akan sampai ke .NET Standard dan .NET Framework. Ini hanya akan memakan waktu lebih lama untuk sampai ke sana. Fakta bahwa pembaruan .NET Framework di tempat adalah alasan kami sangat berhati-hati saat mem-porting perubahan. Perubahan apa pun dapat merusak aplikasi apa pun saat pembaruan didorong secara otomatis ke satu miliar mesin . Dengan .NET Core, kerangka kerja berdampingan sehingga aplikasi perlu memilih versi yang lebih baru untuk mendapatkan fitur atau perbaikan yang lebih baru. Ada lebih banyak kebebasan di sana.

Hanya untuk menimbang dengan perpustakaan net4x kami saat ini hari ini di ASP.NET Core 1.x, itu tidak akan berfungsi di 2.0: EntityFramework 6. EFCore hanya memiliki banyak fitur yang hilang yang kami gunakan hilang (misalnya kait intersepsi/siklus hidup). Jadi kita terjebak di EF6 untuk sementara waktu.

Dan menurut posting @PinpointTownes , EF6 tidak berfungsi dengan versi ASP.NET Core 2.x saat ini (dalam pengembangan).

@nphmuller maka Anda akan tetap menggunakan ASP.NET Core 1.x hingga lebih banyak dependensi dipindahkan (saya tidak tahu berapa banyak hal yang Anda butuhkan dari EF Core dan apa statusnya).

@davidfowl Tentu, jika jendela dukungan dari ASP.NET Core 1.x tidak lewat selama waktu itu.
Fitur utama adalah intersepsi (kait siklus hidup). Fitur lain yang hilang dapat diatasi dengan lebih mudah bagi kami. Intersepsi ada dalam simpanan mereka, tetapi tidak terikat pada pelepasan. Dan naluri saya mengatakan itu tidak akan diterapkan untuk sementara waktu.

@gulbanana : Saya pikir sebagai komunitas pada dasarnya kami menggunakan .net core untuk menggunakan asp.net core, bukan untuk kelebihannya sendiri.

Bicaralah untuk dirimu sendiri. Ada beberapa dari kita yang manfaat utama .NET Core adalah keluar dari Windows di server.

Dan, kurasa, kalian semua hippie pemilik Mac yang kotor. 😝.

@bradwilson Dan, saya kira, Anda semua hippie pemilik Mac yang kotor.

Bicaralah sendiri, beberapa dari kita bukan hippie ;P

Tapi ya, keluar dari Windows (atau sebenarnya, IIS dan http.sys) adalah apa yang saya inginkan .NET Core untuk di samping penyebaran xcopy, perf, dll.

Mengisolasi kode lama dalam layanan terpisah atau porting ke ASP.NET Core tidak membayar untuk alasan selain baru dan mengkilap.

@PinpointTownes adalah kesalahan referensi, apa yang terjadi jika Anda mereferensikan System.Configuration sesuai https://github.com/aspnet/Home/issues/2022#issuecomment -299810945? EF6 mengatakan itu tidak memiliki ketergantungan karena semuanya ada di bundel GAC/Kerangka Penuh Anda yang lama

@benaadams dan @PinpointTownes alasan kegagalannya adalah karena System.Configuration.ConfigurationManager bukan nama DLL yang diharapkan .NET Framework. Saya tidak yakin apakah port System.Configuration valid.

      "system.configuration.configurationmanager/4.4.0-preview2-25308-01": {
        "dependencies": {
          "System.Security.Cryptography.ProtectedData": "4.4.0-preview2-25308-01"
        },
        "runtime": {
          "lib/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        },
        "compile": {
          "ref/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        }

Ya, dapat menjalankan server non-windows adalah hal yang hebat dan menarik.. tetapi tanpa asp.net core apa yang akan Anda jalankan di server tersebut? Bahkan Nancy untuk .net core bergantung pada asp.net core melalui kestrel, UseOwin(), dll.

Saya telah membuat beberapa layanan mikro yang tidak menggunakan ASP.NET Core. Mereka adalah hal-hal seperti proses pekerja yang melakukan polling antrian untuk melakukan pekerjaannya.

Ini tidak adil, kami mengikuti peta jalan, dan Anda tidak mengatakan apa-apa tentang itu sebelumnya !!
Jika Anda mengatakan itu sebelumnya, kami tidak akan menggunakan ASP.NET Core dalam proyek kami karena kami membutuhkan .NET 4.x Libs.
Perencanaan kami termasuk memperbarui proyek kami ke ASP.NET Core 2 karena fungsionalitas baru yang dibutuhkan.
Kami membutuhkan ASP.NET Core 2 untuk menargetkan .NET 4.x juga. jika tidak memungkinkan, bagaimana dengan dukungan ASP.NET Core 1.x, apakah Anda berencana untuk menambahkan semua fungsi baru juga atau hanya memperbaiki bug.

Perencanaan kami termasuk memperbarui proyek kami ke ASP.NET Core 2 karena fungsionalitas baru yang dibutuhkan.

Yang mana?

@PinpointTownes adalah kesalahan referensi, apa yang terjadi jika Anda mereferensikan System.Configuration sesuai # 2022 (komentar)?

Menambahkan <Reference Include="System.Configuration" /> tidak berpengaruh (yaitu pengecualian yang sama dilemparkan), karena tampaknya tidak dapat diselesaikan dari GAC (tidak yakin itu benar-benar mengejutkan, tho'):

Saya tidak yakin apakah port System.Configuration valid.

Jadi kesimpulan resminya adalah... Anda tidak dapat menggunakan perpustakaan yang ditulis untuk .NET Framework 4.x di .NET Core jika menggunakan System.Configuration ?

@PinpointTownes Saya bahkan tidak yakin bahwa versi System.Configuration dikirim (yang ada dalam paket). Mungkin ya, mungkin tidak (itu diskusi untuk memulai di corefx). Saya hanya memberi tahu Anda mengapa sampel Anda rusak seperti itu.

menambahkan tidak berpengaruh (yaitu pengecualian yang sama dilemparkan), karena tampaknya tidak dapat diselesaikan dari GAC (tidak yakin itu benar-benar mengejutkan, tho'):

AFAIK, tidak ada dukungan default untuk referensi GAC dalam proyek SDK. Lihat https://github.com/dotnet/sdk/issues/987#issuecomment -286307697 untuk melihat cara mengaktifkannya.

Jadi kesimpulan resminya adalah... Anda tidak dapat menggunakan pustaka yang ditulis untuk .NET Framework 4.x di .NET Core jika menggunakan System.Configuration?

Kesimpulan saya adalah Anda harus membuka masalah di CoreFX dengan sampel yang Anda berikan di atas.

@davidfowl terima kasih atas jawabannya
Beberapa fitur dan helper yang dibutuhkan pada EF Core direncanakan di 2.0 terutama untuk pemetaan data (Self-contained type mappings)...
Bagaimanapun, saya hanya perlu memiliki gagasan yang jelas tentang peta jalan ASP.NET Core 1.x, tim kami bingung dan khawatir.

Satu hal yang secara pribadi saya perjuangkan adalah hal "platform stabil" vs "fitur baru". Di satu sisi, kami ingin platform stabil dan andal serta kompatibel, di sisi lain tidak ada yang ingin tetap menggunakan 1.x karena tidak memiliki fitur 2.x. Apakah ada fitur super menarik di ASP.NET Core 2.x yang menarik orang ke arah itu atau hanya fakta bahwa kami memiliki lebih banyak fitur daripada yang kami miliki di 1.x (karena baru dan mengkilap)?

@davidfowl Saya pikir signlarR adalah salah satu fitur seperti itu, setidaknya ada di proyek saya sebelumnya. Namun saya juga berpikir banyak kekhawatiran adalah karena jendela dukungan yang relatif singkat untuk 1.1 (2018?) juga ditutupi untuk tambalan yang akan menenangkan orang sedikit.

Saya juga berpikir bahwa dukungan asp.net core 1.1 pada .net core 2.0 lebih berharga lagi, ini memberi orang (apa yang saya pikirkan) jalur migrasi yang baik: asp.net 5 pada 46 >asp.net core 1.x pada 46 > asp.net core 1.x di .net core 2.0 > asp.net core 2 di .net core 2. Itu akan menjadi jalan yang akan mengurangi risiko yang dikhawatirkan banyak orang.

Saya telah mengikuti ini sejak hari pertama dan bahkan setelah semua diskusi dan klarifikasi ini (terima kasih @davidfowl ) saya merasa banyak dari kita dilempar ke bawah bus.

Saya mengerti alasan untuk melepaskan diri dari Full/desktop .NET framework. Sial, saya bahkan setuju bahwa itulah cara untuk memberdayakan ASP.NET, TAPI saya gagal melihat bagaimana ini diputuskan sekarang, bukan dari awal.

Tentu saja kami pelanggan akan mengeluh serius dalam kedua skenario, tetapi saya lebih suka berada di "Saya tidak dapat menggunakan hal baru yang mengkilap" daripada bertaruh pada "Saya dapat menggunakannya, berinvestasi dalam migrasi perlahan dan ganti jika memungkinkan" dan hanya cari tahu itu palsu.

Saya gagal melihat bagaimana ini diputuskan sekarang, bukan dari awal.

Dengan menebak:

Pada .NET Core 1.x Anda tidak dapat menjalankan Pustaka kerangka kerja penuh, jadi itu akan menjadi jeda total.

Pada .NET Core 2.x Anda sebagian besar dapat menjalankan kerangka kerja Penuh dan dapat menjalankan pustaka .NET Standard 1.x - 2.0, jadi ini bukan terobosan besar.

Masalah apa pun dengan menjalankan pustaka kerangka kerja penuh di .NET Core 2.0, mungkin harus diajukan di dotnet/corefx

Jelas bahwa skenario utamanya adalah "aplikasi web modern di cloud", yang sering kali tidak memiliki banyak dependensi pihak ketiga (atau "hanya kode").

Sebagian besar diskusi sejauh ini difokuskan pada ketersediaan BCL, tetapi banyak dari kita bergantung pada komponen pihak ketiga (integrasi tingkat rendah dengan Video kompleks, subsistem Audio misalnya...) yang sering tertinggal di lanskap .NET dan hampir selalu mengandalkan teknologi tingkat rendah yang mungkin tidak didukung.

Dengan ASP.NET Core 1, kami mengembangkan layanan modern kami, menargetkan standar .NET untuk Libs dan memilih untuk menerapkan pada .NET atau .NET Core Penuh per dependensi layanan.

Saya dapat bertaruh pada ini karena dalam hal menemukan fitur/komponen yang tidak didukung, kami dapat dengan mudah menargetkan .NET Penuh. Dan taruhannya adalah pada platform jangka panjang, karena tetap menggunakan .NET Penuh sepertinya keputusan yang harus dihindari dalam beberapa tahun.

_Pada .NET Core 2.x Anda sebagian besar dapat menjalankan kerangka kerja Penuh dan dapat menjalankan pustaka .NET Standard 1.x - 2.0, jadi ini bukan terobosan besar._

@benaadams Ada perbedaan besar antara dapat menggunakan sebagian besar BCL dan dapat menggunakan perpustakaan yang telah dibangun untuk Full .NET (dan secara internal dapat menggunakan fitur yang tidak didukung di .NET Standard 2.0 / type unification).

Saya kira keputusan ini tidak berdampak pada pelonggaran migrasi ke ASP.NET Core 2.0 dari ASP.NET 4?
Cukup banyak aplikasi yang saya kelola benar-benar dapat mengambil untung dari pembaruan ke ASP.NET Core 2.0, tetapi karena tidak ada Dukungan OWIN/Katana untuk ASP.NET Core, saya kira saya perlu bermigrasi secara manual dan itu terlalu banyak pekerjaan atm. @damianh menyarankan yang serupa di https://github.com/aspnet/AspNetKatana/issues/27

Kami menjalankan kerangka kerja penuh karena kami membutuhkan EF6 (untuk spasial) dan layanan direktori dan kami menunggu SignalR yang tepat (saat ini menggunakan versi yang tidak didukung tetapi berfungsi). Saya belum memeriksa pemblokir lain untuk sementara waktu tetapi mungkin ada lebih banyak.

Seperti yang saya pahami, kami sekarang akan diblokir dari pindah ke asp.net core 2.0 dan mendapatkan signalr ketika keluar.

Kami telah bersama untuk perjalanan sejak dnx, RC1 ke RC2 dan proyek json ke csproj dan akhirnya rasanya seperti kami keluar dari hutan ... sekarang tidak begitu banyak.

Saya dapat memahami perubahan ini pada akhirnya tetapi apakah ini benar-benar waktu untuk melakukannya ketika asp.net core mencoba untuk mendapatkan daya tarik? Juga, firasat saya memberi tahu saya bahwa EF Core belum cukup matang (dan tentu saja tidak untuk spasial) dan siapa pun yang bertaruh pada dukungan di inti mengambil risiko lebih besar sehubungan dengan porting lib .... menunggu versi lain untuk transisi ini sepertinya itu akan memberikan stabilitas dan kesempatan bagi EF Core dan port lain untuk mengejar, belum lagi sinyal r pada kerangka kerja penuh.

Saya yakin sebagian besar perusahaan menjalankan inti asp.net (yang sangat bagus) pada kerangka kerja penuh dan mungkin berada dalam posisi yang mirip dengan kami.

Mengingat perpindahan ini ke kereta cepat untuk ASP.NET Core, apakah itu berarti Anda akan memperkenalkan versi LTS dan Saat Ini, dan berapa lama dukungan pada instance ini?

Saya kira saya berada dalam contoh yang beruntung di mana saya sedang mengerjakan solusi greenfield yang tidak memiliki persyaratan untuk berjalan di netfx, _but_ selalu menyenangkan untuk dimiliki jika bisa. Satu-satunya hal yang akan menjadi pemblokir bagi saya adalah layanan windows yang saya targetkan di netfx, tetapi ada rencana untuk itu.

Saya merasa perubahan ini berjalan ke arah yang salah. Saya mengerti beberapa fitur eksklusif inti sampai standar bersih menyusul. Tetapi menempuh rute inti saja ini adalah lereng yang licin untuk menciptakan ekosistem yang retak.

Perubahan ini membuat pernyataan yang saya tidak yakin saya suka: Tidak apa-apa untuk hanya menargetkan netcoreapp.

Saya juga ingin menulis pendapat saya.

Saya percaya bahwa masih terlalu dini untuk menghapus .net framework. Saya tidak tahu apa masalah mendukung .net framework + .net core bersama-sama, tetapi saya yakin keputusan ini akan membuat migrasi ke AspNet Core sedikit lebih sulit. Karena beberapa perusahaan berpikir bahwa: "Mari kita mulai AspNet Core dengan .net core.. jika kita memiliki masalah serius (seperti perpustakaan must-need tidak mendukungnya di masa depan) kita selalu dapat kembali ke .net framework". Tapi sekarang itu tidak mungkin lagi dan perusahaan akan ragu untuk memulai dengan AspNet Core. Juga, keputusan ini dapat menurunkan nilai .netstandard.

@hikalkan

Karena beberapa perusahaan berpikir bahwa: "Mari kita mulai AspNet Core dengan .net core.. jika kita memiliki masalah serius (seperti perpustakaan must-need tidak mendukungnya di masa depan) kita selalu dapat kembali ke .net framework".

Anda selalu dapat menggunakan ASP.NET Core 1.1 bukan?

Juga, keputusan ini dapat menurunkan nilai .netstandard.

Saya tidak melihat mengapa itu akan terjadi. Seperti yang saya katakan sebelumnya, pustaka lintas sektor kami masih menargetkan .NET Standard serta API yang perlu bekerja di semua implementasi .NET.

Tentu, mereka dapat menggunakan asp.net core 1.1. Tetapi tidak baik untuk mengatakan: "Versi terbaru ASP.NET Core adalah 2.x tetapi Anda harus menggunakan ASP.NET Core 1.x jika Anda ingin menargetkan .net framework". Itu tidak jauh berbeda dengan mengatakan "gunakan MVC 5.x" :)

Saya percaya .net core adalah masa depan (bukan masa depan, bahkan sekarang!), tetapi .net framework akan segera dihapus (keputusan ini akan dipahami oleh komunitas seperti .net framework sudah usang).

Anda selalu dapat menggunakan ASP.NET Core 1.1 bukan?

tidak ada manfaat yang jelas. Pertama belum matang, jadi taruhan.
Kedua, pengembang di ASP.Net Core tidak akan mau menulis di alat lama dan tetap ketinggalan.
Saya tertarik pada beberapa hal.

1. Kami sudah bekerja di proyek greenfield sepenuhnya di ASP.Net Core, Dapper, dll.
   Tetapi di proyek lain, logika bisnis kami ada di 4,6 rakitan. Seperti yang saya baca di atas, kita seharusnya tidak memiliki masalah untuk merujuknya. Saya harap, saya mengerti dengan baik tentang.
2. SinyalR . Layanan Direktori, MS Orleans, Azure.
3. mungkin tidak relevan dengan percakapan di atas, tetapi saya ingin meng-host secara lokal ASP.Net Core dengan Kestrel atau HttpListener lainnya sebagai aplikasi desktop UWP atau sebagai jembatan desktop di UWP.

Harus dikatakan saya cukup kecewa dengan komunikasi ini. Saya pikir kita bisa hidup dengan keputusan itu tetapi itu muncul entah dari mana.

Pada bulan Juli, tim saya mulai mengerjakan proyek greenfield 12-18 bulan yang akan berjalan di ASP.NET Core 2.0 dengan semua hal keren yang telah kami baca selama bertahun-tahun di .NET Core.

Namun sementara itu, kami memiliki aplikasi ASP.NET MVC Core 1.0 yang merupakan pusat dari produk lama kami yang pada dasarnya berfungsi sebagai pembungkus untuk memanggil pustaka .NET Framework.

Saya mengonfirmasi dengan tim bahwa rencana mereka adalah memutakhirkan aplikasi ke ASP.NET MVC Core 2.0 dan menjadikannya bagian dari aplikasi baru saat kami menukar komponen .NET Framework. Sekarang kita terjebak dengan ASP.NET MVC Core 1.0 yang akan EOL'ed sebelum kita menyelesaikan proyek.

Tepat sebelum saya menjalankan pendapat saya, saya hanya ingin kejelasan pada satu bagian.
Apakah saya benar dalam membuat asumsi bahwa jika kita ingin terus menggunakan ASP.NET Core,
kami tidak akan dapat mereferensikan dll yang menargetkan .Net 4.5 atau lebih tinggi dan membuatnya berfungsi seperti saat ini?

@louislewis2 Tidak, itu tidak benar. Anda akan dapat menggunakan perpustakaan net45 - net461 , selama mereka tetap berada dalam ruang API yang didukung untuk netstandard2.0 . Anda tidak perlu mengkompilasi ulang pustaka tersebut.

@bradwilson Terima kasih atas klarifikasinya. Itu pasti akan membuatku tidur lebih nyenyak malam ini.
Banyak perpustakaan tidak berada dalam kendali kami, jadi itu akan menjadi masalah besar.

Sangat lega sekarang :)

@shanselman @DamianEdwards @davidfowl Untuk daftar item yang kami gunakan yang belum porting, akan item di system.management dll. Kami menggunakan pengidentifikasi perangkat keras secara khusus, ini digunakan untuk pembuatan tautan otomatis untuk Bus Layanan Azure dan seluruh server lisensi dan paket klien kami. Saya membayangkan bahwa dengan mereka tidak menjadi api saat ini, akankah menyebabkan kita beberapa masalah serius?

https://github.com/dotnet/corefx/issues/3324
https://github.com/dotnet/corefx/issues/14762

Ini adalah perampokan terbesar kami yang membuat kami tetap menjalankan beberapa aplikasi kami pada kerangka kerja penuh.

Ini menempatkan kita dalam situasi yang canggung.

Saya sedang mem-porting layanan mikro kami dari ASP.Net 4.5 yang di-host-sendiri dalam proses di atas Kestrel (alasan kompatibilitas lama), ke ASP.Net Core 1.x yang di-host-sendiri secara penuh. Namun, kita perlu menjalankan hal-hal ini pada kerangka kerja penuh, untuk saat ini. Dan ada alasan bagus untuk itu.

Kami memiliki sejumlah dependensi Windows keras yang sudah menjadi bagian dari infrastruktur kami dan tidak dapat diubah. Itu termasuk NTLM auth, Event Log logging, dll. Jika ASP.Net Core 2.x keluar dari dukungan netstandard, maka saya sebaiknya tidak melakukannya sama sekali. Masalahnya adalah, tidak ada alternatif kerangka kerja lengkap yang dikembangkan secara aktif. Katana sudah mati dan lambat (sebagai perbandingan).

Jika seseorang dapat mengarahkan saya ke server HTTP yang secepat Kestrel untuk .Net Framework, tentu saja. Tapi itu tidak ada. Jadi saya hanya harus menerima bahwa ASP.Net meninggalkan pelanggan produksi aktual seperti saya dengan perubahan ini.

Jika tumpukan membutuhkan semua barang baru, seperti Pipelines dan Span, maka itu harus disediakan sebagai lib standar bersih. API apa yang digunakan ASP.Net Core 2.x yang ada di netcoreapp2.0 yang tidak ada di netstandard2.0, dan mengapa API tersebut tidak dapat dijadikan lib ekstensi netstandard2.0 untuk sementara?

Apakah kami serius mengatakan bahwa MS menghabiskan 2 tahun mengerjakan standar (bersih) di semua kerangka kerja mereka hanya untuk berbalik dan merilis produk unggulan yang tidak menggunakan standar ini?

Saya pikir Tim GitHub akan menambahkan fitur Pagination untuk bagian masalah karena masalah ini.

@mattnischan

Saya sedang mem-porting layanan mikro kami dari ASP.Net 4.5 yang di-host-sendiri dalam proses di atas Kestrel (alasan kompatibilitas lama), ke ASP.Net Core 1.x yang di-host-sendiri secara penuh. Namun, kita perlu menjalankan hal-hal ini pada kerangka kerja penuh, untuk saat ini. Dan ada alasan bagus untuk itu.

Anda dapat tetap menggunakan ASP.NET Core 1.x bukan?

Jika tumpukan membutuhkan semua barang baru, seperti Pipelines dan Span, maka itu harus disediakan sebagai lib standar bersih. API apa yang digunakan ASP.Net Core 2.x yang ada di netcoreapp2.0 yang tidak ada di netstandard2.0, dan mengapa API tersebut tidak dapat dijadikan lib ekstensi netstandard2.0 untuk sementara?

Ketika API muncul di .NET Standard yang tidak ada di .NET Framework, bagaimana Anda akan menggunakannya?

@stefan2410

Anda dapat menggunakan ASP.NET Core 1.x untuk itu kan? Fitur ASP.NET Core 2.0 mana yang Anda butuhkan? Apakah hanya SignalR?

Pertahankan aplikasi apa adanya selama dua tahun ke depan tetapi tukar pustaka .NET Framework dengan yang setara dengan .NET Core setelah selesai. Ini akan menjaga logika bisnis kami, dll., dibagikan di antara kedua aplikasi.
Kami tidak dapat melakukan ini karena Juli 2018 adalah batas waktu untuk dukungan ASP.NET MVC Core 1.0.

Sekali lagi, di dunia hipotetis saya, kami memperpanjang umur 1.x

Tingkatkan aplikasi ke ASP.NET MVC Core 2.0 dan jadikan itu bagian dari aplikasi baru saat kami menukar komponen .NET Framework.
Kami juga tidak dapat melakukan ini, karena Core 2.0 tidak mendukung .NET Framework jadi semuanya atau tidak sama sekali.

Apakah Anda benar-benar membutuhkan ASP.NET Core 2.0? Atau hanya .NET Core 2.0?

Ketika API muncul di .NET Standard yang tidak ada di .NET Framework, bagaimana Anda akan menggunakannya?

Rencana kami adalah: tunggu sampai mereka ada di dalamnya. Anda mengatakan sebelumnya bahwa itu hanya masalah waktu, kan? Lagging tepi pendarahan dengan beberapa jumlah tetap demi stabilitas sudah baik-baik saja. Jauh lebih baik daripada tertinggal secara permanen, setidaknya.

@davidfowl
Saya akan pindah di ASP.Net core 2.0. Saya tidak punya solusi lain. Saya tidak bisa mengatakan kepada tim untuk tetap berada di belakang evolusi, kami menunggu lama ASP.Net Core.
Sejauh kami tidak memiliki masalah dengan referensi rakitan logika bisnis 4.6 kami.
Saya membutuhkan SignalR, DirectoryServices, bukan masalah dengan perpustakaan Azure/Amazon, MS Orleans.
Juga mungkin itu tidak relevan dengan percakapan di atas, tetapi saya ingin aplikasi desktop meng-host secara lokal ASP.Net Core dengan Kestrel / HttpListener sebagai aplikasi desktop UWP atau sebagai jembatan desktop di UWP.
Kami tidak dapat menulis ulang kode untuk XAML dan saya tidak ingin menggunakan Electron.

Anda dapat tetap menggunakan ASP.NET Core 1.x bukan?

Untuk jangka waktu apa? Saya tidak dapat melihat sesuatu seperti Log Peristiwa yang membuatnya menjadi standar bersih.

Ketika API muncul di .NET Standard yang tidak ada di .NET Framework, bagaimana Anda akan menggunakannya?

Apakah ini sesuatu? netstandard20 tampaknya masih berjalan di net461 menurut dokumen. Apakah Anda mengatakan bahwa API di bawah netstandard20 tidak cukup lengkap untuk mengimplementasikan barang baru? Atau, apakah ada rencana untuk memindahkan standar bersih di luar kerangka kerja yang belum diungkapkan?

Rencana kami adalah: tunggu sampai mereka ada di dalamnya. Anda mengatakan sebelumnya bahwa itu hanya masalah waktu, kan? Lagging tepi pendarahan dengan beberapa jumlah tetap demi stabilitas sudah baik-baik saja. Jauh lebih baik daripada tertinggal secara permanen, setidaknya.

Perpustakaan dapat ditulis di atas standar. Ketika hal-hal dalam standar itu sendiri perlu diubah, itu akan memakan waktu lebih lama untuk diadopsi di semua implementasi .NET dan itu termasuk .NET Framework. Ini bisa berarti beberapa hal:

• .NET Standard akan berkembang pada tingkat implementasi paling lambat
• .NET Standard akan berkembang pada beberapa kecepatan lain dan .NET Framework akan menjadi yang terakhir untuk mengejar ketinggalan.

Tentu saja itu tidak berarti bahwa perpustakaan tidak dapat ditulis menentangnya, itu hanya berarti peringatan tersebut perlu dipertimbangkan ketika memilih versi .NET Standard yang ingin Anda dukung.

Juga mungkin itu tidak relevan dengan percakapan di atas, tetapi saya ingin aplikasi desktop meng-host secara lokal ASP.Net Core dengan Kestrel / HttpListener sebagai aplikasi desktop UWP atau sebagai jembatan desktop di UWP.

ASP.NET Core di UWP saat ini tidak ada di peta jalan apa pun jadi saya tidak bisa mengatakan apa yang akan terjadi di sini. HttpListener adalah bagian dari .NET Standard 2.0 jadi mungkin ada kemungkinan itu akan berhasil.

Saya ingin meluangkan waktu untuk berterima kasih kepada semua orang atas komentar dan umpan balik mereka di sini. Kami sangat menghargainya serta kesabaran Anda saat kami mencari jalan ke depan. Perlu diketahui bahwa kami tidak bermaksud agar perubahan ini begitu sulit, sangat terlambat, dan tanpa peringatan. Tinjauan ke belakang adalah 20/20 dan jika kami tahu apa yang kami ketahui sekarang, kami akan mengomunikasikan hal-hal sebelumnya. Kami akan berusaha lebih keras untuk maju.

Kami memiliki rencana berdasarkan umpan balik yang kami terima di sini yang ingin saya bagikan kepada Anda sebelum kami mempostingnya sebagai pengumuman akhir minggu ini dengan rilis 2.0.0-preview1. Ketika itu terjadi, kami akan membuka edisi baru untuk memfasilitasi diskusi seputar rencana itu, tetapi untuk saat ini lanjutkan dan terus bagikan pemikiran dan umpan balik Anda di sini:

• Dukungan untuk ASP.NET Core 1.x pada .NET Framework akan diperpanjang setidaknya selama satu tahun lagi (hingga Juli 2019). Kami akan menilai ulang ini setiap tahun dan berkomitmen untuk memberikan pemberitahuan 12 bulan sebelum mengakhiri dukungan ASP.NET Core 1.x (jadi pada Juli 2018 kami akan mengumumkan apakah kami akan memperpanjang untuk 12 bulan lagi hingga Juli 2020) ( Catatan tambahan: adalah ada yang takut dengan fakta bahwa kita sudah membicarakan tentang 2020? Tidak? Oke, hanya saya. )
• SignalR baru akan menargetkan dan didukung penuh pada ASP.NET Core 1.x (datang akhir tahun ini)
• Kami akan terus memperbarui ASP.NET Core 1.x untuk mendukung versi bahasa baru, dll. seperti yang kami lakukan untuk System.Web
• ASP.NET Core 1.x yang berjalan di .NET Core 1.x akan didukung hingga Juli 2018 (tidak ada perubahan)
• ASP.NET Core 1.x yang berjalan di .NET Core 2+ akan didukung selama ASP.NET Core 1.x di .NET Framework didukung
  
  
  
  • Ini untuk memastikan selalu ada tumpang tindih dari ASP.NET Core yang didukung pada .NET Core yang didukung sementara kami mendukung berjalan di .NET Framework, memungkinkan pelanggan untuk melakukan port dari waktu ke waktu sambil tetap menggunakan bit yang didukung
  
  
• Dukungan .NET Core 1.x (sebagai runtime) tidak berubah. Berakhir pada Juli 2018. Pelanggan yang menjalankan ASP.NET Core 1.x perlu pindah ke .NET Core 2.0 atau berada di .NET Framework pada saat itu (atau pindah ke ASP.NET Core 2.0 di .NET Core 2.0)
• Kami akan port System.DirectoryServices dan System.Drawing ke .NET Core tahun ini (didukung sepenuhnya, lintas platform, pratinjau setidaknya untuk Windows di Musim Panas)
• Daftar hal-hal yang akan di-port ke .NET Core setelah itu saat ini termasuk ServiceBase (untuk mendukung .NET Core Windows Services). Belum ada garis waktu selain yang berikutnya (garis waktu jelas menjadi lebih konkret saat kami menyusun daftar). Kami akan membuat daftar ini berdasarkan umpan balik pelanggan.
• Saat ini kami tidak memiliki rencana untuk mem-port System.ServiceModel (WCF sisi server) ke .NET Core. WCF untuk .NET Core dapat terus ditingkatkan dan memiliki fitur yang ditambahkan berdasarkan umpan balik, misalnya enkripsi pesan HTTP.

@DamianEdwards @davidfowl sebagian besar masalahnya adalah bahwa perlu berbulan-bulan perencanaan dan upaya pengembangan sambil mengorbankan biaya peluang yang sangat besar untuk berkomitmen pindah ke ASP.NET Core di mana banyak organisasi tidak akan dapat pindah dari sekarang .NET 4.x karena ini adalah satu-satunya platform yang mereka yakini dapat menjalankan semua dependensi sistem mereka.

Sampai saat ini MS telah memasarkan .NET Core secara agresif sebagai masa depan ASP.NET di mana tidak jelas apakah pengembangan ASP.NET 4.x telah dihentikan dan apakah semua upaya pengembangan di masa depan akan diinvestasikan di ASP.NET Core. akan ada banyak migrasi yang sedang berlangsung untuk menjaga sistem mereka tetap terkini. Banyak orang akan merasa seperti terlempar ke bawah bus jika pada hasil akhir dari semua upaya mereka, mereka secara efektif bermigrasi ke platform EOL. Ini akan merugikan baik organisasi maupun pengembang/konsultan yang merupakan juara terbesar untuk memulai perpindahan ke .NET Core. Mereka mungkin tidak memerlukan apa pun dari ASP.NET Core 2.0 sekarang, tetapi mereka pasti ingin memiliki ruang kepala untuk sistem mereka dan dapat mengakses beberapa fitur baru untuk semua upaya mereka.

Saya juga tidak mengerti mengapa kode "warisan" yang ada dianggap sebagai kewajiban ketika IMO harus dianggap sebagai salah satu aset terbesar .NET, .NET Core tidak akan menarik jika tidak dapat menjalankan perpustakaan .NET yang ada . Java masih begitu kuat karena ekosistem JVM yang masif dan stabil yang lebih penting daripada kelemahan yang melekat pada bahasa itu sendiri.

Saya tidak berpikir MS bahkan mulai merasakan reaksi dari menjatuhkan dukungan .NET 4.x yang tidak akan diketahui secara luas sampai diumumkan, saya berharap sebagian besar pengembang di sini secara aktif mengikuti pengembangan di GitHub lebih tertarik untuk melihat fitur-fitur baru daripada mereka berada dalam interoperabilitas dan memastikan ada jalur migrasi yang lancar untuk basis kode yang ada. Saya akan sangat terkejut, tetapi jika Anda tidak mendapatkan panas dari keputusan ini setelah diumumkan daripada itu mungkin yang benar karena mungkin tidak akan ada banyak orang yang terluka karenanya.

Apakah terlalu banyak upaya untuk fokus pada rilis stabil/kompatibel ASP.NET Core 2.0, kemudian mengumumkan masa depan .NET Core-only untuk versi berikutnya? Sepertinya itu hal yang adil untuk dilakukan dalam situasi ini mengingat itu benar-benar tidak terduga.

@DamianEdwards terima kasih atas pembaruan dan rencana yang jelas. Saya tidak setuju dengan itu, tapi saya masih menghargai Anda meletakkannya.

Masih ada kesenjangan mendasar yang sangat besar di sini. Port ke 1.x hampir seluruhnya merupakan port lateral, ada beberapa fitur di dalamnya untuk kami. 2.x adalah tempat beberapa peningkatan yang bermanfaat dan kami masih tidak memiliki jaminan bahwa kami dapat melakukan langkah itu. Ada kemungkinan besar bahwa kami menghabiskan banyak waktu, uang, dan upaya untuk porting ke 1.x hanya untuk terdampar di sana karena dependensi kerangka kerja penuh. Saya tidak akan bertaruh dengan perusahaan kami. Kami mungkin berakhir dengan dukungan yang lebih sedikit daripada yang kami miliki di ASP.NET 4.x sekarang.

Kecuali itu berubah, aplikasi kami tidak akan melakukan perjalanan ke ASP.NET Core, dan semua perpustakaan kami akan jauh lebih buruk karena kurangnya dogfooding di dalamnya.

Saya sangat berharap Anda mempertimbangkan kembali keputusan ini. Saya berharap suatu hari kita dapat membuat Stack Overflow memanfaatkan ribuan jam pribadi yang telah kita curahkan untuk membantu mengembangkan platform .NET Core.

@NickCraver

Ada kemungkinan besar bahwa kami menghabiskan banyak waktu, uang, dan upaya untuk porting ke 1.x hanya untuk terdampar di sana karena dependensi kerangka kerja penuh.

Sepanjang utas ini, Anda menyebut System.DirectoryServices sebagai salah satu hal inti. Saya berasumsi Anda memiliki beberapa dependensi yang menurut Anda akan memakan waktu lama untuk di-porting atau yang tidak akan pernah di-porting. Jika 2.0 mendukung .NET Framework, apakah dependensi tersebut akan berpindah dalam setahun?

2.x adalah tempat beberapa peningkatan yang bermanfaat dan kami masih tidak memiliki jaminan bahwa kami dapat melakukan langkah itu.

Yang mana? Akan lebih baik untuk mengetahuinya karena kami sedang mendiskusikan kembali mem-porting beberapa hal yang sangat penting kembali ke ASP.NET Core 1.1 untuk memudahkan transisi.

Kecuali itu berubah, aplikasi kami tidak akan melakukan perjalanan ke ASP.NET Core, dan semua perpustakaan kami akan jauh lebih buruk karena kurangnya dogfooding di dalamnya.

Saya tidak tahu apa-apa tentang stackoverflow.com tetapi apakah mungkin untuk memecah-mecah (saya tidak ingin mengatakan "layanan mikro") sehingga ASP.NET Core dapat digunakan untuk beberapa bagian?

@mythz

Ini akan merugikan baik organisasi maupun pengembang/konsultan yang merupakan juara terbesar untuk memulai perpindahan ke .NET Core

Apakah maksud Anda ASP.NET Core? Atau .NET Core?

@davidfowl Maksud saya ASP.NET Core, tetapi itu juga memengaruhi pengembang yang merencanakan migrasi bertahap dari ASP.NET Core/.NET 4.x terlebih dahulu kemudian .NET Core kemudian.

Omong-omong, saya perhatikan bahwa tidak ada perpustakaan di ASP.NET Core/.NET Core untuk menangani SAML. Saya memiliki persyaratan untuk menangani SSO melalui IdP pihak ketiga, tetapi saya tidak tahu apakah itu mungkin.

@davidfowl Maksud saya ASP.NET Core, tetapi itu juga memengaruhi pengembang yang merencanakan migrasi bertahap dari ASP.NET Core .NET 4.x terlebih dahulu kemudian .NET Core kemudian.

Saya tidak melihat mengapa itu akan terjadi.

Saya pikir rencana itu mungkin akan cukup menarik bagi organisasi saya untuk menghindari pindah dari platform. Hal utama adalah memiliki periode yang lebih lama dengan dukungan (= patch keamanan) di mana sisa netfx deps dapat ditulis ulang atau dihilangkan. Semuanya masih agak tidak pasti dan secara konseptual aneh. Apa yang terjadi jika tiga tahun dari sekarang kita ingin membangun situs web yang dapat mencerna dokumen Excel atau menyematkan server web dalam sebuah aplikasi? Apa yang terjadi pada kerangka kerja lain seperti Orleans yang membangun di atas standar alih-alih netcoreapp?

Saya benar-benar tidak mengerti mengapa begitu banyak pekerjaan yang dilakukan pada netstandard2.0 jika itu tidak akan cukup baik untuk ASP.NET Core untuk benar-benar menggunakannya.

Apa yang terjadi jika tiga tahun dari sekarang kami ingin membangun situs web yang dapat mencerna dokumen Excel?

Sulit untuk dikatakan. Saya tidak dapat berbicara mewakili tim yang memilikinya, tetapi mungkin itu akan di-porting ke .NET Core dan akan bekerja lintas platform.

atau untuk menyematkan server web dalam aplikasi?

HttpListener adalah bagian dari netstandard 2.0.

Apa yang terjadi pada kerangka kerja lain seperti Orleans yang membangun di atas standar alih-alih netcoreapp?

Terserah kerangka kerja untuk memutuskan apakah mereka ingin berjalan di .NET Framework, UWP, .NET Core, mono dll. Itu pilihan. Orleans tidak dikirimkan dengan .NET Core. ASP.NET Core tidak. Produk-produk itu adalah satu dan sama.

Apa yang akan menjadi keputusan sulit bagi kami (dan klien kami) bukanlah tentang perpustakaan yang saya miliki hari ini, tetapi perpustakaan yang saya tidak tahu apakah saya perlu 6 bulan dari sekarang. Ada banyak perpustakaan dan kerangka kerja yang belum mendukung netstandard . Misalnya, satu bulan dalam sebuah proyek, kami menyadari bahwa kami membutuhkan beberapa fitur di NHibernate yang bahkan tidak ada di EF6, apalagi EF Core. Jadi apa pilihan saya di sana - targetkan ASP.NET Core 1.x pada .NET penuh?

Sepertinya saya memiliki beberapa ApiPort di masa depan saya.

Jadi apa pilihan saya di sana - targetkan ASP.NET Core 1.x pada .NET penuh?

Ya.

Sulit untuk dikatakan. Saya tidak dapat berbicara mewakili tim yang memilikinya, tetapi mungkin itu akan di-porting ke .NET Core dan akan bekerja lintas platform.

Benar, tapi pasti itu dalam lingkup tim asp.net untuk memutuskan apakah layak menyediakan akses ke ekosistem perpustakaan yang mungkin tidak di-porting.

Benar, tapi pasti itu dalam lingkup tim asp.net untuk memutuskan apakah layak menyediakan akses ke ekosistem perpustakaan yang mungkin tidak di-porting.

.NET besar dan tua, tidak mungkin Anda tidak mengharapkan tim ASP.NET berbicara dengan nafas perpustakaan yang ada di ekosistem .NET. Ini tidak realistis. Saya baru mengetahui apa itu OMSK (https://msdn.microsoft.com/en-us/library/office/jj163123.aspx) sebagai bagian dari utas ini dan saya ragu itu akan di-porting tetapi saya tidak bisa mengatakan itu untuk Tentu.

Memperluas dukungan untuk ASP.NET 1.1 di .NET Framework membantu mengurangi ini sedikit, tetapi saya pikir itu juga membantu karena beberapa dependensi perlu diisolasi untuk pindah dengan benar ke ASP.NET Core di .NET Core (yang merupakan masa depan yang diinginkan).

Saya akan mengesampingkan perpustakaan karena poin itu sudah dibahas panjang lebar. Dalam kasus kami (amilia.com, e-commerce SaaS) alat pihak ketiga sudah menjadi showstopper, kami bahkan tidak dapat menjalankan ASP.NET Core pada kerangka kerja penuh saat ini. Saya akui ini tidak terdengar seperti alasan yang sah, tetapi ini adalah kendala yang harus kita tangani.

Secara teori, kami dapat mengganti alat tersebut (yaitu profiler, pemantauan, membangun server, dll) dengan alternatif yang mendukung .NET Core, tetapi itu adalah beberapa bulan kerja yang saya lebih suka habiskan untuk memecahkan masalah yang lebih mendesak. Kami akan melakukan migrasi pada akhirnya ke ASP.NET Core/.NET Core, tetapi sekarang ini adalah target yang cukup bergerak.

Sampai saat ini harapan dibuat bahwa ASP.NET Core akan dapat terus berjalan pada kerangka kerja desktop, dan dengan demikian berbicara dengan luasnya dll. Saya tidak tahu jenis daun teh apa yang seharusnya kita baca untuk mengetahuinya. bahwa itu tidak realistis :/

Seperti, untuk lebih jelasnya: gagasan bahwa ASP.NET Core mungkin hanya berjalan di .NET Core itu sendiri tidak gila, tetapi kami tidak pernah mendengar mengintipnya sebelumnya. Semua informasi publik adalah bahwa itu berjalan dengan baik di .NET Framework dan tidak ada indikasi bahwa ini mungkin harus diubah.

.NET besar dan tua, tidak mungkin Anda mengharapkan tim ASP.NET berbicara dengan nafas perpustakaan yang ada di ekosistem .NET. Ini tidak realistis

Bukankah itu alasan yang baik untuk tetap mendukung .NET 4.x? Beban kompatibilitas/interoperabilitas dapat dimuat ke platform .NET 4.x yang dapat menjadi solusi kerja yang dapat meringankan .NET Core dari kebutuhan untuk beroperasi dengan lib yang lebih lama dan mengurangi tekanan untuk mem-port perpustakaan .NET populer yang ada ke .NET Core ( untuk MS dan penulis eksternal).

@mythz

Bukankah itu alasan yang baik untuk tetap mendukung .NET 4.x? Beban kompatibilitas/interoperabilitas dapat dimuat ke platform .NET 4.x yang dapat menjadi solusi kerja yang dapat meringankan .NET Core dari kebutuhan untuk beroperasi dengan lib yang lebih lama dan mengurangi tekanan untuk mem-port perpustakaan .NET populer yang ada ke .NET Core ( untuk MS dan penulis eksternal).

Itu sebabnya masa pakai ASP.NET Core pada 1.1 telah diperpanjang (meskipun tidak secara permanen). Kami akan memastikan bahwa SignalR berfungsi karena itu dinyatakan sebagai salah satu alasan utama untuk menggunakan ASP.NET Core 2.0. Pada saat yang sama, itu bukan di mana ASP.NET Core ingin berada dalam jangka panjang. Tujuannya selalu untuk dikirim sebagai bagian dari platform .NET Core terpadu.

@gulbanana

Sampai saat ini harapan dibuat bahwa ASP.NET Core akan dapat terus berjalan pada kerangka kerja desktop, dan dengan demikian berbicara dengan luasnya dll. Saya tidak tahu jenis daun teh apa yang seharusnya kita baca untuk mengetahuinya. bahwa itu tidak realistis :/

ASP.NET Core di .NET Framework sayangnya tidak pernah dikomunikasikan sebagai solusi stop gap untuk memudahkan porting (itu adalah sesuatu yang kami pesan dengan sangat buruk). Itu tidak pernah dimaksudkan sebagai platform yang didukung selamanya yang merupakan kesimpulan logis jika Anda berasumsi bahwa beberapa dependensi tidak akan pernah porting.

Itu sebabnya masa pakai ASP.NET Core pada 1.1 telah diperpanjang (meskipun tidak secara permanen).

Masalahnya adalah apakah itu cukup atau tidak, versi saat ini pada dasarnya telah EOL sebelum rilis yang kompatibel/stabil bahkan telah dikirimkan.

Saya tidak percaya nilai investasi yang ada sedang dipertimbangkan, siapa yang mau melalui semua upaya untuk bermigrasi ke platform EOL? Pengembang akan bekerja pada sistem brownfield mereka yang ada tanpa batas waktu, mereka pada dasarnya diberitahu bahwa keterampilan ASP.NET v4.x mereka saat ini akan menjadi usang dan mereka tidak dapat bermigrasi ke model pengembangan ASP.NET Core yang baru karena .NET Core. Dukungan .NET 4.x dihentikan dan mereka tidak bertanggung jawab untuk mempertimbangkan atau merekomendasikan migrasi ke platform buntu.

@davidfowl

ASP.NET Core di .NET Framework sayangnya tidak pernah dikomunikasikan sebagai solusi stop gap untuk memudahkan porting (itu adalah sesuatu yang kami pesan dengan sangat buruk). Itu tidak pernah dimaksudkan sebagai platform yang didukung selamanya yang merupakan kesimpulan logis jika Anda berasumsi bahwa beberapa dependensi tidak akan pernah porting.

Kesalahan terjadi, tidak apa-apa. Masalahnya sekarang adalah banyak orang membuat asumsi ini dan hanya menggunakan ASP.NET Core karena kesimpulan logis tetapi salah. Kita lihat saja berapa banyak, kurasa :/

Saya menunggu asp.net core 2/ .net core 2 begitu lama, tetapi hasilnya sangat tertekan.

@mythz

Saya tidak percaya nilai investasi yang ada sedang dipertimbangkan, siapa yang mau melalui semua upaya untuk bermigrasi ke platform EOL?

Tidak bisakah argumen yang sama dibuat tentang ASP.NET Core 2.0 menjadi EOL di .NET Framework tahun depan ketika 3.0 keluar? Jika Anda mengatakan satu tahun tidak cukup di ASP.NET Core 1.1, mengapa Anda menyarankan satu tahun tidak apa-apa di ASP.NET Core 2.0?

Pengembang akan bekerja pada sistem brownfield mereka yang ada tanpa batas waktu, mereka pada dasarnya diberitahu bahwa keterampilan ASP.NET v4.x mereka saat ini akan menjadi usang dan mereka tidak dapat bermigrasi ke model pengembangan ASP.NET Core yang baru karena .NET Core. Dukungan .NET 4.x dihentikan dan mereka tidak bertanggung jawab untuk mempertimbangkan atau merekomendasikan migrasi ke platform buntu.

Siapa yang diberitahu bahwa keterampilan ASP.NET 4.x akan menjadi usang? Jika ada yang kita harapkan mereka tidak. MVC khususnya mendukung kompatibilitas konsep dengan beberapa fitur baru. ASP.NET Core sangat mirip dengan Katana (dan itu tidak salah). Jika Anda berbicara tentang Formulir Web, lalu bagaimana dengan MVC?

Saya tidak memiliki pengalaman konsultasi tetapi saya setuju bahwa jika dependensi tidak tersedia maka saya akan setuju. Entah itu atau aplikasi perlu dirancang ulang untuk mempertimbangkan hal ini.

@xyting bisa di perjelas?

@davidfowl

Tidak bisakah argumen yang sama dibuat tentang ASP.NET Core 2.0 menjadi EOL di .NET Framework tahun depan ketika 3.0 keluar? Jika Anda mengatakan satu tahun tidak cukup di ASP.NET Core 1.1, mengapa Anda menyarankan satu tahun tidak apa-apa di ASP.NET Core 2.0?

Saya berada di bawah asumsi lama bahwa ASP.NET Core 1.1 hanyalah solusi stop-gap untuk ASP.NET Core 2.0 dan .NET Standard 2.0 yang akan menjadi rilis LTS yang berfokus pada kompatibilitas dan stabil yang akan menjembatani kesenjangan dengan sebagian besar fungsionalitas inti hilang dari .NET 4.x - hingga utas ini pada dasarnya menghancurkan asumsi itu. Menjaga kompatibilitas .NET 4.x hingga ASP.NET Core 2.0 tidak ideal, tetapi jauh lebih baik daripada menghentikannya pada rilis saat ini yang tidak diharapkan oleh siapa pun.

Siapa yang diberitahu bahwa keterampilan ASP.NET 4.x akan menjadi usang? Jika ada yang kita harapkan mereka tidak.

MS melakukannya dengan semua pemasaran agresif mereka di .NET Core dengan semua pengumuman dan fitur baru yang tampaknya berfokus pada ASP.NET Core. Apakah ASP.NET WebForms/MVC lama bahkan sedang dikembangkan di tempat terbuka? Berapa proporsi upaya dev yang diinvestasikan pada ASP.NET WebForms/MVC lama vs .NET Core? Saya tidak tahu, semua yang saya lihat baru-baru ini, semua standup mingguan, tutorial video tampaknya hanya terfokus pada ASP.NET Core. Saya tahu saya pasti tidak akan merasa nyaman memulai proyek greenfield baru menggunakan teknologi ASP.NET WebForms atau MVC lama.

Jika Anda berharap mereka bukan MS, Anda harus mengomunikasikannya lebih baik dengan peta jalan yang jelas. Mengingat betapa fluktuatifnya ASP.NET dalam beberapa tahun terakhir (masalah ini menjadi contoh sempurna), mustahil untuk mengetahui seperti apa masa depan tanpa komitmen dan pengumuman resmi.

Apakah ada orang lain yang merasa bahwa akan lebih baik jika versi 1 tidak pernah berjalan pada kerangka kerja penuh? Saya tidak mengharapkannya karena penamaan. Sekarang setelah itu terjadi dan saya sudah merasakannya, saya kecewa kehilangannya.

Saya mengerti dari mana Anda berasal dari ini, Anda ingin mengulangi seluruh tumpukan secepat mungkin. Anda bersaing dengan sejumlah besar kerangka kerja web bidang hijau yang mengontrol seluruh tumpukan dan tidak memiliki beban untuk diseret. Neraka menjatuhkan bagasi System.Web adalah salah satu alasan utama ASP.NET Core begitu menarik.

Setelah tidur di atasnya, saya dapat mengatakan penggunaan kami akan baik-baik saja, dependensi yang kami butuhkan semua harus bekerja pada 2.0.

Pada saat yang sama, itu bukan di mana ASP.NET Core ingin berada dalam jangka panjang. Tujuannya selalu untuk dikirim sebagai bagian dari platform .NET Core terpadu.

Meskipun tidak perlu paranormal untuk mengetahui bahwa .NET Core adalah platform masa depan .NET... jika niat dari awal (atau seperti yang Anda katakan "selalu") adalah untuk memasangkan ASP.NET Core dengan .NET Core. .NET core, yang jelas tidak dikomunikasikan dalam media apa pun yang pernah saya lihat.

Saya benar-benar melihat setiap menit dari setiap standup ASP.NET (termasuk Hanselman dan Glenn memecahkan masalah Docker selama 3 jam ... karena saya tidak punya kehidupan), saya membaca blog, saya selalu di Twitter, saya pergi ke 2+ konferensi setahun, menghadiri grup pengguna, dll. Dan saya belum pernah mendengar itu dikomunikasikan sebagai maksud dari ASP.NET Core. Sebaliknya, saya telah mendengar berulang-ulang "itu berjalan di kedua platform" dan, memang benar, orang merasa seperti seseorang menarik kursi dari bawah mereka. Saya bahkan telah memberikan ceramah tentang ASP.NET Core dan mengatakan "ini berjalan di kedua platform" sendiri, dan sekarang saya merasa bersalah untuk siapa pun yang saya pimpin ke jalan ini. Saya akan mengatakan bahwa orang-orang ITT kemungkinan besar berada di ujung tanduk dan akan menjadi yang paling menerima berita semacam ini, dan ada banyak reaksi di sini. Sepertinya ini hanya akan menjadi lebih buruk karena berita ini mengalir ke pengembang dan manajer mereka yang tidak terhubung, dan kemungkinan lebih konservatif daripada ITT itu.

Selain kurangnya komunikasi dan kurangnya dukungan untuk beberapa skenario, saya pikir banyak reaksi hanya karena waktu pengumuman ini. .NET Core 2 bahkan belum RTM dan sudah dianggap sebagai satu-satunya jalan jangka panjang ke depan, dan pada dasarnya ada bom waktu yang dipasang di Kerangka Penuh untuk ASP.NET Core. Saya pikir banyak ketakutan kita bisa hilang begitu kita memiliki sesuatu yang nyata untuk dimainkan selain nightlies.

Saya benar-benar berpikir perlu ada pengalaman perkakas yang lebih baik daripada "jalankan dan lihat apakah itu berfungsi" ketika merujuk net461+ libs dari .NET Core 2+ di VS, karena saya sudah dapat melihat pesan "kita mungkin dapat menjalankan sebagian besar 461+ rakitanmu juga!" akan dipasarkan sampai mati. Sesuatu yang dapat menganalisis API yang hilang dari apa yang kami referensikan, memberikan kesalahan waktu kompilasi, idealnya bahkan menyarankan compat nupkgs jika ada (seperti System.Configuration dalam contoh EF6 di atas... dan membuatnya berfungsi :smile:). Jelas, tidak semuanya dapat dianalisis pada waktu kompilasi (skenario transaksi terdistribusi yang disebutkan di atas dianggap sebagai sesuatu yang sulit untuk dianalisis sebelumnya), tetapi semakin banyak semakin baik. Sesuatu seperti yang dilakukan Immo di sini untuk PlatformNotSupportedException dan API net461 yang hilang untuk netstandard2 akan menyenangkan.

Hanya 2 sen saya. Saya harap saya hanya bereaksi berlebihan. Pada akhirnya, banyak dari kita hanya kecewa, karena kita menyukai ASP.NET Core, dan kita tidak ingin ada yang menghalangi cara kita menggunakannya. ❤️

Bergabung dengan suara saya untuk masalah yang sudah terdaftar, kami memulai proyek ASP.NET MVC baru bulan depan dan itu akan menjadi .NET Framework biasa dengan ASP.NET MVC, karena pelanggan tidak percaya Microsoft melakukan hal yang benar dalam hal perencanaan jangka panjang.

Organisasi pelanggan masih menggunakan penerapan Windows 7 dan proyek ini merupakan pengecualian, karena sebagian besar proyek web mereka sebenarnya dilakukan di UNIX dengan Java, dengan .NET sebagian besar digunakan pada aplikasi desktop.

Jenis ketidakpastian ini hanya menumpuk pada sejarah yang rusak bahwa Windows 8 .NET stack dan UWP, meningkatkan minat CTO organisasi untuk mencari alternatif yang lebih stabil untuk masa depan .NET.

Jika Anda memaksa jenis organisasi ini untuk menulis modul dari awal untuk bekerja di ASP.NET Core, saya juga dapat menyarankan pelanggan kami untuk mengadopsi sesuatu dengan peta jalan yang lebih stabil, daripada kehilangan muka tentang masalah yang tidak dapat saya kendalikan.

@davidfowl Mungkin perubahan ini akan berfungsi dengan baik untuk 99% proyek. Tapi itu dijual sebagai "ini berjalan di kedua platform" dan "Anda dapat menggunakannya dengan kerangka kerja penuh jika Anda harus". Semua orang tahu bahwa versi kerangka lengkap dari asp.net core adalah untuk proyek yang tidak dapat dimigrasikan, dan itu tidak masalah. Dan orang-orang berencana dengan pemikiran itu.

Perubahan ini mungkin bukan yang terburuk dalam hal kode, tetapi kemungkinan besar akan menciptakan badai besar ketika pengembang reguler melihat berita tersebut. Dan ini bukan tentang kode, ini tentang apa yang dijanjikan. Dan janjinya adalah "jalankan net atau core, dan netstandard untuk menggabungkan semuanya".

@DamianEdwards @davidfowl Terima kasih telah berbagi rencananya.

SignalR pada 1.x sangat melegakan untuk menggantikan versi kami yang tidak didukung dan juga berita bahwa ServiceBase berada di urutan berikutnya dalam daftar karena saat ini kami juga menggunakannya!

Kami sangat bergantung pada EF6 dan spasial jadi kami akan terjebak pada 1.x hingga memiliki set fitur yang kami butuhkan....

Namun, pada catatan sampingan yang semi-lucu, ini akhirnya dapat memaksa penyebaran layanan mikro yang lebih banyak untuk ini. Saya tidak sabar untuk menjelaskan mengapa pelanggan LOB kami perlu menginstal beberapa api lagi di IIS hanya untuk membuat produk kami berfungsi....

Saya benar-benar berharap ini dapat ditahan karena tampaknya terlalu cepat dan seperti yang telah disebutkan oleh beberapa orang, ini akan menghasilkan reaksi yang signifikan ketika posting blog turun.

Juga saya harus mengatakan saya merasa sedikit menjual-down-the-sungai ketika dari awal sentimen ini akan berjalan pada kerangka penuh dan telah mengkhotbahkan hal yang sama kepada rekan-rekan. Menjelaskan pilihan penamaan yang membingungkan dari asp.net core.

@shanselman @davidfowl Titik sakit terbesar saya adalah NHibernate. Bahkan setelah rilis EF Core, itu masih satu-satunya mapper O/R berfitur lengkap paling canggih.

@shanselman @DamianEdwards Saya sedang dalam proses mulai berpikir untuk memutakhirkan situs dari ASP.NET MVC 4 ke versi terbaru apa pun (saya bingung apakah itu 5 atau satu). Saya masih perlu menjalankan kerangka .net lengkap karena saya merujuk pustaka SyncFusion dan Telerik. SyncFusion untuk menampilkan file PDF dan Telerik untuk menghasilkan file Word .docx. Seperti yang telah ditunjukkan oleh orang lain, tidak masuk akal jika strategi Microsoft untuk menangani ini menjadi "cobalah dan lihat apakah itu berhasil". Saya tidak dapat menjamin itu dan produksi semuanya akan berfungsi karena ini adalah basis kode yang besar dari kode pihak ketiga.

Sementara dukungan SyncFusion umumnya sangat baik, dukungan Telerik tidak dan saya akan terkejut jika mereka dapat membuatnya bekerja dengan .net core. Saya tidak tahu Apis apa yang mungkin mereka gunakan yang tidak didukung di .net core - dan sebagai pengguna akhir itulah inti dari produk pihak ketiga, saya hanya mencolokkannya dan melakukan apa yang perlu dilakukan.

Terus terang untuk pelanggan yang tidak terlalu sering berurusan dengan barang (saya kebanyakan melakukan WPF) ini semua sangat membingungkan. Ada terlalu banyak versi yang berbeda, dengan berbagai ketidaksesuaian. Seperti yang telah ditunjukkan seseorang, ini agak mirip dengan UWP XAML - serupa tetapi sama sekali tidak kompatibel dengan WPF XAML.

Tidak baik untuk pengembang dan hanya hal lain yang menyebabkan pengembang kehilangan kepercayaan pada Microsoft (salah satu dari banyak selama beberapa tahun terakhir). Tampaknya bagi saya bahwa ASP.NET pasti harus berjalan pada kerangka .net lengkap, karena ada perpustakaan alat yang sangat besar yang mungkin perlu digunakan orang di server mereka. Dalam kasus saya, saya dapat dengan mudah memperbarui ke versi kerangka .net yang lebih baru jika saya perlu untuk menggunakan barang-barang ASP.net terbaru jika pembaruan diperlukan untuk fungsionalitas ASP.net yang baru.

Pesan apa pun yang dikirim ke pengembang harus lebih jelas, sebelum orang-orang melompat sepenuhnya.

...Stefan

ASP.NET Core di .NET Framework sayangnya tidak pernah dikomunikasikan sebagai solusi stop gap untuk memudahkan porting (itu adalah sesuatu yang kami pesan dengan sangat buruk). Itu tidak pernah dimaksudkan sebagai platform yang didukung selamanya yang merupakan kesimpulan logis jika Anda berasumsi bahwa beberapa dependensi tidak akan pernah porting.

Saya pribadi tidak memiliki masalah dengan perubahan yang tercantum dalam masalah ini, saya mengerti alasannya dan masuk akal, sekarang saya telah membaca banyak tanggapan di sini. Namun, apa yang baru saja Anda katakan menyoroti apa yang pada akhirnya menjadi inti masalah - komunikasi yang buruk dari Microsoft secara keseluruhan (Yang saya hargai bukanlah kesalahan Anda, atau _spesifik_ individu mana pun).

Mungkin saya melewatkan sesuatu, tetapi ada lebih banyak hal untuk "berkembang di tempat terbuka" daripada hanya memiliki kode di github untuk dilihat dan dimainkan semua orang. Masalah ini dibuat karena perubahan muncul dalam kode suatu hari yang mengejutkan orang, tetapi jelas Anda sendiri dan semua orang di tim .net mengetahuinya dan memahaminya - jadi ini sudah lama sekali. Masalahnya adalah bahwa kita semua, manusia biasa, benar-benar dibutakan olehnya.

Lebih buruk lagi, saya menduga sebagian besar pengembang tidak terlalu memperhatikan github untuk mendapatkan pengetahuan dan informasi mereka - jadi perubahan ini akan mengejutkan lebih banyak orang daripada yang sudah berkomentar di sini. Saya hanya menemukan masalah ini sendiri karena muncul di RSS feed saya dari hackernews - yang bukan apa yang saya sebut sumber utama saya untuk berita dan informasi.

Siapa pun yang mengikuti dari posting blog di MSDN akan tahu bahwa 2.0 akan datang dan mereka akan melihatnya sebagai cawan suci untuk menjembatani kesenjangan antara inti asp.net dan semua yang "hilang" sebelumnya, tetapi mereka sama sekali tidak menyadarinya apa yang pada dasarnya merupakan perubahan besar untuk alur kerja tertentu. Ada sedikit detail tentang apa yang sebenarnya terjadi dengan desain asp.net core 2.0. Saya menduga lebih banyak detail akan datang akhir pekan ini di Build? Seseorang hanya bisa berharap.

.net slack adalah sumber informasi lain, tetapi sedikit bising untuk terus mengikuti perkembangan apa yang sebenarnya terjadi. Ini bagus untuk keterlibatan pengembang dan mengajukan pertanyaan, tapi itu bukan sumber berita.

Twitter dan media sosial adalah sumber informasi lain, tetapi sekali lagi sedikit seperti masalah github ini pada saat muncul di sana, biasanya karena seseorang telah menyampaikan kekhawatiran dengan keputusan yang telah dibuat dan membuat orang terkejut.

Ini juga bukan pertama kalinya kami mengalami masalah ini. Ingat kegagalan yang disebabkan oleh perubahan kembali ke csproj? Saya tidak ingin masuk ke perdebatan tentang perubahan itu, tapi ini adalah contoh lain dari perubahan yang mengejutkan orang-orang, yang dikomunikasikan dengan sangat buruk sehingga sampai hari ini, banyak orang tidak menyadari bahwa itu bukan csproj yang sama. dari "masa lalu yang buruk".

Saya tidak sepenuhnya yakin apa yang saya coba sarankan di sini, tetapi pasti ada sesuatu yang "hilang" dari pengembangan terbuka .net. Microsoft melakukan pekerjaan yang baik dalam menyediakan sumber daya dan dokumentasi untuk pengembang, tetapi hanya untuk produk jadi dan hal-hal yang telah dikirimkan. Peta jalan, rapat perencanaan, segala sesuatu yang memutuskan desain dan arah kerangka kerja tampaknya dilakukan secara tertutup, dengan sesekali menyebut "mitra terpilih" dan sejenisnya. Saya tidak mengatakan bahwa setiap pertemuan harus dialirkan dan disiarkan ke seluruh dunia, tetapi pasti ada jalan tengah yang lebih baik di mana keputusan yang dibuat dan alasan di baliknya dikomunikasikan sedini mungkin kepada komunitas, dengan cara yang mudah. bagi kita yang benar-benar _ingin_ mengikuti untuk mencerna dan tetap di atas. Mungkin blog khusus di MSDN (atau di tempat lain) yang diperbarui secara berkala ketika keputusan itu dibuat.

Salah satu masalah terbesar saya dengan ini adalah bahwa di hampir setiap konferensi tahun lalu ASP.NET Core telah disajikan, Anda telah mempresentasikannya dengan slide yang menunjukkan asp.net core berjalan di kedua .net framework dan .net core, hanya lihat ini: Jelajahi pengembangan web dengan Microsoft ASP.NET Core 1.0 dari Ignite tahun lalu. Pada sekitar 7,50, Anda akan melihat slide.

Showstoppers terbesar bagi saya adalah System.DirectoryServices, ServiceBase, EF6 (EF Core belum siap), ClosedXML (untuk membuat lembar excel).

Dukungan untuk ASP.NET Core 1.x pada .NET Framework akan diperpanjang setidaknya selama satu tahun lagi (hingga Juli 2019). Kami akan menilai ulang ini setiap tahun dan berkomitmen untuk memberikan pemberitahuan 12 bulan sebelum mengakhiri dukungan ASP.NET Core 1.x (jadi pada Juli 2018 kami akan mengumumkan apakah kami akan memperpanjang untuk 12 bulan lagi hingga Juli 2020) (Catatan tambahan: adalah ada yang takut dengan fakta bahwa kita sudah membicarakan tentang 2020? Tidak? Oke, hanya saya.)

@DamianEdwards Terima kasih atas pengumumannya.

Saat ini perusahaan kami sedang mengembangkan aplikasi enterprise untuk beberapa klien menggunakan ASP.NET Core 1.1 pada .NET Framework 4.6.2. Mendengar bahwa dukungan untuk kombo kerangka kerja itu didukung setidaknya hingga 2019, dan kemungkinan diperpanjang 2020, sangat melegakan.

Kami akan port System.DirectoryServices dan System.Drawing ke .NET Core tahun ini (didukung sepenuhnya, lintas platform, pratinjau untuk setidaknya Windows di Musim Panas)

Ini adalah dua satu-satunya alasan kami menargetkan .NET Framework sekarang. Jika ini sepenuhnya di-porting ke .NET Core 2, saya yakin kami dapat mem-porting aplikasi kami ke ASP.NET Core 2 dengan aman tahun depan.

Sepertinya banyak ppl telah melanggar aturan utama menjadi pengembang MS - jangan berkomitmen untuk produk/garpu apa pun sampai setidaknya V2.

tapi ya, bicara tentang mengasingkan klien perusahaan Anda! seluruh alasan mereka menggunakan MS adalah untuk kompatibilitas ke belakang.

Mayoritas ppl yang menjalankan ASP.NET TIDAK PEDULI jika dijalankan di linux. Dan jika mereka melihat posting blog, dengan perbandingan kecepatan dengan ASPNET Core, mereka bahkan tidak akan membaca lintas platform sebelumnya jika mereka melihatnya tidak mendukung .NET lama.

lolcat.

Saya pikir ada nilai dalam menjalankan ASP.NET Core 2.0 sepenuhnya di net46x demi memberi banyak orang jalur migrasi yang mulus ke dunia baru. Saya pikir banyak orang sedang menunggu ASP.NET Core 2.0 dan .NET Core 2.0 dengan harapan itu akan menutup banyak celah hari ini dan memungkinkan migrasi. Jika ASP.NET Core 2.0 akan membutuhkan semuanya untuk porting ke netcoreapp2.0, maka itu akan menjadi perlambatan besar untuk tim dan bahkan mungkin membahayakan kelayakan.

Namun, itu tidak berarti bahwa tidak mungkin ada ASP.NET Core 3.0 segera setelah itu hanya akan menargetkan netcoreapp2.0 untuk semua orang yang mengerjakan semua hal baru yang mengkilap dan ingin berada di jalur cepat.

Memiliki dua versi ASP.NET Core (2.0 dan 3.0) berdampingan benar-benar bisa menjadi hal yang baik (setidaknya untuk sementara waktu). Itu dapat memungkinkan MSFT untuk lebih cepat menghapus tumpukan MVC 5 saat ini, karena versi baru MVC pada dasarnya adalah ASP.NET Core MVC 2.0, yang juga akan berjalan pada .NET penuh.

Saya pikir ada nilai dalam menjalankan ASP.NET Core 2.0 sepenuhnya di net46x demi memberi banyak orang jalur migrasi yang mulus ke dunia baru

Apa yang membuatnya lebih lancar daripada porting dari ASP.NET Core 1.x?

Saya pikir banyak orang sedang menunggu ASP.NET Core 2.0 dan .NET Core 2.0 dengan harapan itu akan menutup banyak celah hari ini dan memungkinkan migrasi.

Sebagian besar pekerjaan yang dilakukan untuk membuat hal-hal yang kompatibel dilakukan di .NET Core 2.0 dan .NET Standard 2.0. ASP.NET Core 2.0 sejujurnya tidak memiliki banyak fitur baru. Kami mengatakan bahwa kami akan mem-backport SignalR ke ASP.NET Core 1.x (yang merupakan post 2.0). Apakah itu hanya masalah persepsi?

Memiliki dua versi ASP.NET Core (2.0 dan 3.0) secara berdampingan benar-benar merupakan hal yang baik.

Inilah yang kami lakukan dengan 1.1 dan 2.0 (cukup balikkan angkanya).

Itu dapat memungkinkan MSFT untuk lebih cepat menghapus tumpukan MVC 5 saat ini, karena versi baru MVC pada dasarnya adalah ASP.NET Core MVC 2.0, yang juga akan berjalan pada .NET penuh.

MVC 5 tidak akan pernah hilang, kami tidak mencela apa pun. Ini akan didukung selama .NET Framework ada. Anda masih tidak dapat menjalankan proyek ASP.NET Core di dalam pipa terintegrasi IIS (di System.Web) dan itu tidak melakukan semua hal yang sama seperti MVC 5 di System.Web jadi itu benar-benar bukan pengganti untuk skenario tertentu .

@davidfowl Akankah saya dapat membuat aplikasi ASP.NET Core 1.x, yang menargetkan .NET dan netcoreapp2.0 penuh sehingga saya dapat memigrasikan aplikasi lawas saat ini ke ASP.NET Core terlebih dahulu dengan semua dependensi menjadi net46x dan perlahan-lahan bermigrasi ketergantungan satu demi satu untuk menargetkan netstandard2.0 hingga semuanya ada di netstandard2.0 yang kemudian akan memungkinkan saya untuk memutakhirkan aplikasi ASP.NET Core 1.x ke 2.x (dan menjatuhkan target untuk net46x sebagai bagian dari itu)?

Jika ya, maka saya pikir saya salah memahami utasnya. Saya pikir ini benar-benar apa yang kebanyakan orang cari di sini.

@dustinmoris ya Anda bisa melakukannya. Perhatian utama orang-orang adalah apa yang terjadi jika mereka tidak dimigrasikan ke ASP.NET Core 2.x sebelum dukungan berakhir di ASP.NET Core 1.x, jika memungkinkan bagi mereka untuk bermigrasi sama sekali.

@alexwiese ah ok itu bagus, lalu sebenarnya apa yang kita bahas di sini sekarang? Daripada membahas kerangka kerja apa yang ditargetkan, kita harus mendiskusikan periode dukungan ASP.NET Core 1.x, yang merupakan sesuatu yang dapat dengan mudah diubah MSFT jika mereka mau :)

EDIT:
@DamianEdwards menulis ini sedikit lebih jauh di utas:

Dukungan untuk ASP.NET Core 1.x pada .NET Framework akan diperpanjang setidaknya selama satu tahun lagi (hingga Juli 2019). Kami akan menilai ulang ini setiap tahun dan berkomitmen untuk memberikan pemberitahuan 12 bulan sebelum mengakhiri dukungan ASP.NET Core 1.x (jadi pada Juli 2018 kami akan mengumumkan apakah kami akan memperpanjang untuk 12 bulan lagi hingga Juli 2020) (Catatan tambahan: adalah ada yang takut dengan fakta bahwa kita sudah membicarakan tentang 2020? Tidak? Oke, hanya saya.)

Terdengar bagus untukku. Berkomitmen untuk satu tahun lagi dukungan dan kemudian secara berkala menilai kembali. Masuk akal bagi saya.

Saya sudah membaca setiap posting di utas ini. Masih ada satu pertanyaan yang belum terjawab: mengapa keputusan ini dibuat? Saya hanya bisa menyimpulkan itu diperlukan karena masalah teknis. Jika 'kebingungan' penamaan adalah masalahnya, Microsoft harus mempekerjakan orang PR yang lebih baik dan berhenti mengaduk-aduk omong kosong seperti yang dilakukan tim di utas ini.

Jadi apa masalah teknis yang memblokir ASP.NET core 2.0 di netstandard2.0? Tidak ada yang tidak mungkin di bidang perangkat lunak, jadi tidak mungkin Anda tidak dapat menemukan solusi yang tidak dapat dilakukan di .NET full (dan karenanya tidak dapat dimasukkan dalam netstandard20). Ya itu membutuhkan waktu dan usaha, tetapi saya merasa Anda semua tidak benar-benar menyadari efek samping dari keputusan ini bagi pengguna Anda, berapa banyak waktu/usaha yang harus mereka investasikan karena hal ini.

Keputusan ini memiliki kelemahan lain: ASP.NET Core bukan konsumen standar bersih dan karena itu bukan pendorongnya. Itu membuat standar net menjadi pengikut dan karena inti ASP.NET tidak bergantung padanya, pengikut dengan sedikit arti: .net core 2.0+ API adalah permukaan untuk ditargetkan, karena inti ASP.NET menargetkan permukaan itu , bukan standar bersih 2.0.

Dan, maaf @davidfowl , saya tahu maksud Anda baik, tetapi menyarankan ASP.NET core 1.x kepada orang-orang berulang kali menunjukkan bahwa Anda benar-benar tidak tahu apa situasinya untuk orang-orang yang Anda sarankan: orang-orang tidak dapat bermigrasi ke ASP.NET core 1.x karena mereka tidak tahu apakah ada jalan mulus darinya tanpa tenggat waktu yang pasti: mungkin mereka harus tetap berada di platform itu lebih lama dari yang mereka pikirkan saat ini (dependensi perlu di-porting dll.). Itu saja membuat keputusan untuk pindah ke ASP.NET core 1.xa keputusan berdasarkan tidak lain dari 'janji' dari Microsoft. Ini adalah API yang dimaksudkan untuk kode yang menghadap internet. Mereka perlu tahu apakah mereka dapat menjalankan aplikasi yang dibuat hari ini juga dalam waktu 3 tahun karena Microsoft akan memperbaiki kelemahan keamanan di dalamnya (sebagai contoh).

Terus terang, saya tidak mendapatkan dorongan untuk memulai cluster kekacauan lain dalam ekosistem .NET: kita membutuhkan stabilitas, ketergantungan, keandalan: "kode saya yang ditulis hari ini akan berjalan dalam waktu 5 tahun apa adanya". ya, saya tahu itu terdengar konyol bagi sebagian orang, tetapi itulah kenyataannya: sudah ada lebih banyak paket perangkat lunak di planet ini daripada jumlah pengembang yang memeliharanya dan kesenjangannya semakin lebar. Anda tidak bisa begitu saja berasumsi bahwa suatu organisasi akan memutuskan untuk menggunakan ASP.NET Core sebagai webstack mereka dan berharap kode yang ditulis menggunakan itu akan berjalan dalam waktu 5 tahun, organisasi tidak melakukannya lagi: mereka tahu ada tumpukan di luar sana yang dapat diandalkan dan memberi mereka bahwa: mereka tahu bahwa mereka mungkin tidak dapat menulis ulang seluruh aplikasi dalam jangka waktu tersebut sehingga mereka membutuhkan jaminan itu.

Microsoft telah menunjukkan dengan utas ini dan, maaf, PR mereka yang buruk tentang masalah ini, mereka tidak dapat memberikan jaminan itu. Dan tidak peduli berapa banyak putaran yang Anda coba berikan dalam beberapa hari mendatang di \build, kami di sisi lain pagar telah belajar bahwa Microsoft Marketing != jaminan segalanya akan bekerja besok.

@FransBouma Saya tidak berpikir itu karena ada masalah teknis, sepertinya motivasi untuk hanya menargetkan netcoreapp2.0 adalah karena ini adalah satu-satunya trek yang MSFT dapat bergerak secepat yang mereka suka, yang baik untuk kita setelahnya semua, karena itu berarti ASP.NET Core 2.x dapat bergerak jauh lebih cepat daripada tumpukan web lain di dunia .NET sebelumnya. Jika Anda tidak dapat berkomitmen untuk kereta cepat ini, maka Anda dapat tetap menggunakan ASP.NET Core 1.x lebih lama (saat ini didukung hingga 2019)

@FransBouma sebagai @davidfowl dan @shanselman menyebutkan ada API baru yang ditambahkan dengan kecepatan tinggi di .NET Core, dan ASP.NET Core 2.x akan menggunakan beberapa di antaranya, oleh karena itu keinginan untuk menargetkan netcoreapp20. Jika mereka ingin menambahkan API ini ke netstandard2x maka .NET Framework dan platform lain harus mengejar ketinggalan, dan mereka terkenal lambat bergerak.

Saya akan menambahkan suara saya di sisi debat Ini adalah Hal yang Baik . Inilah alasannya:

• Tim tidak hanya melakukan ini untuk itu. Ada banyak fitur dan pengoptimalan baru yang siap (atau hampir siap) untuk diluncurkan di .NET Core yang sangat berguna bagi orang-orang yang membangun aplikasi web modern, API, dan layanan mikro, dan menunggu fitur tersebut mendarat di Windows .NET Framework penuh akan menunda rilis selama berbulan-bulan.
• Banyak keluhan yang saya lihat di utas ini adalah beberapa variasi "Saya tidak bisa melakukan X di .NET Core 2.0" padahal yang sebenarnya penulis maksud adalah _"Saya harus mengubah cara saya melakukan X di .NET Core 2.0" _. Ya, Anda harus berubah. Tidak, itu bukan hal yang buruk. Jika Anda memiliki sebagian kecil fungsi diskrit di aplikasi ASP.NET MVC Anda yang melakukan sesuatu dengan file PDF atau DOCX, dan Anda _benar-benar_ tidak dapat menemukan cara yang lebih baik untuk melakukan apa pun itu (sudahkah Anda mencoba?), maka hancurkan itu fungsionalitas ke dalam layanan mikro yang berjalan pada .NET penuh pada Windows Server dan menyebutnya sebagai API HTTP dari aplikasi .NET Core Anda. Mengurai aplikasi dan memindahkan fungsionalitas tertentu ke dalam layanan kecil yang mandiri bahkan bukan solusi, _ini adalah praktik terbaik untuk tujuan umum._
  
  
  
  • NB Sejauh yang saya tahu, paket OpenXML sekarang mendukung .NET Standard, jadi bekerja dengan Word/Excel/apa pun seharusnya tidak mustahil.
  
  
• .NET Core 2.0 bahkan belum dalam pratinjau publik yang layak, jadi mengeluh bahwa itu tidak mendapat dukungan untuk LDAP atau apa pun yang tampaknya terlalu dini. Jika RTM muncul di Q3 dan masih tidak ada cara untuk berinteraksi dengan AD atau Kerberos atau apa pun, maka komplainlah (walaupun pikirkan juga tentang migrasi ke sistem otentikasi berbasis token modern karena ini bukan tahun 2008 lagi).
• Ada _is_ migrasi yang lancar dari ASP.NET MVC 4.5 ke ASP.NET Core 2.0. Ini disebut ASP.NET Core 1.0 (dan saya setuju bahwa harus ada janji dukungan jangka panjang untuk 1.0 dalam situasi tersebut). Anda dapat membuat aplikasi menggunakan 1.0 dan menjalankannya di Full .NET dalam Integrated Pipeline di bawah IIS 8.5 di Windows Server 2012 R2 hingga
  
  
  
  • .NET penuh menyusul dan Anda dapat menjalankan ASP.NET Core 2.x di atasnya, atau
  
  
  • Apa pun teknologi pihak ketiga yang Anda andalkan mendukung .NET Core (atau dapat diganti dengan teknologi setara yang mendukung .NET Core).
  
  
• Ingatlah bahwa—sementara tim Anda mungkin dilumpuhkan oleh ketergantungan eksternal atau kebijakan atau politik internal perusahaan atau sekadar kelembaman—ada ratusan ribu, jika bukan jutaan, pengembang di dunia yang ingin membangun aplikasi, layanan, dan API menggunakan modern pola arsitektur dan platform teknologi baru (cloud/edge/IoT/etc), untuk siapa ASP.NET Core 2.0 sangat cocok. Mereka menginginkannya cepat, terukur, dan lintas platform; hal-hal itu penting bagi banyak orang. Meminta Microsoft untuk mengabaikan pasar yang berkembang pesat itu, hanya karena pemasok kontrol pihak ketiga Anda atau proyek sumber terbuka belum mem-porting kode mereka, adalah konyol.

@dustinmoris yang menyarankan netstandard tidak memiliki API untuk membuat webstack cepat. Jika demikian, kita semua memiliki masalah yang lebih besar.

@alexwiese seperti yang saya katakan, saya membaca utas lengkap dan dengan demikian juga posting yang Anda rujuk. Saya tahu apa yang mereka katakan dan dapat mengerti maksud mereka, tetapi keputusan yang dibuat menunjukkan bahwa mereka tidak tahu apa yang dilakukan pengguna mereka dengan barang-barang mereka. Saya membangun produk sendiri, selama bertahun-tahun sekarang, dan tahu bahwa setelah beberapa saat Anda tiba pada titik di mana Anda ingin memotong sesuatu dan bergerak lebih cepat, tanpa cruft lama yang sudah ketinggalan zaman. Tetapi melakukan itu memiliki konsekuensi, dan satu hal yang saya pelajari dalam 14 tahun terakhir adalah bahwa kompatibilitas mundur adalah salah satu fitur terbesar yang dapat dimiliki produk perangkat lunak: dapat menggunakannya dan 'hanya berfungsi' adalah poin kunci untuk banyak banyak orang untuk memutuskan untuk platform Anda. Anda mungkin tidak berpikir itu penting, dan itu baik-baik saja, tetapi ada banyak orang di luar sana yang tidak dapat melihatnya seperti itu karena kenyataan mereka berbeda.

Bukannya tim inti asp.net tidak boleh bergerak cepat, tetapi mereka melakukannya dengan cara yang melanggar asumsi banyak orang ketika mereka pindah ke asp.net core 1.x.

@FransBouma Mengapa menurut Anda Anda memiliki gagasan yang lebih baik tentang apa yang dilakukan pengguna Microsoft dengan barang-barang Microsoft daripada yang dilakukan Microsoft?

@markrendle

Tim tidak hanya melakukan ini untuk itu. Ada banyak fitur dan pengoptimalan baru yang siap (atau hampir siap) untuk diluncurkan di .NET Core yang sangat berguna bagi orang-orang yang membangun aplikasi web modern, API, dan layanan mikro, dan menunggu fitur tersebut mendarat di Windows .NET Framework penuh akan menunda rilis selama berbulan-bulan.

Jadi, beri tahu saya, mengapa tidak membuat API super duper ini sebagai paket .net standar 2.0 dan mempostingnya di nuget?

Menurut Anda, mengapa Anda memiliki gagasan yang lebih baik tentang apa yang dilakukan pengguna Microsoft dengan barang-barang Microsoft daripada yang dilakukan Microsoft?

Oh saya tidak tahu, dengan membaca posting di utas ini?

@FransBouma

yang menunjukkan netstandard tidak memiliki API untuk membuat webstack cepat. Jika demikian, kita semua memiliki masalah yang lebih besar.

Menurut saya netstandard tidak kekurangan apa-apa, karena netstandard tidak lebih dari daftar fitur yang perlu diimplementasikan oleh platform yang ingin mendukung standar tersebut. Secara teori kita dapat memindahkan standar bersih secepat yang kita suka, hanya menambahkan lebih banyak ke spesifikasi, tetapi secara realistis tidak layak untuk semua platform untuk mengejar spesifikasi baru tersebut.

Jadi pertanyaannya adalah, apakah ASP.NET Core 2.x ingin berkomitmen ke netstandard2.0 (tertinggi saat ini) dan kemudian mengetahui bahwa itu macet dengan semua yang telah ditentukan di sana, atau apakah hanya ASP.NET Core 2.x komit ke netcoreapp2.x, yang bisa lebih dari sekadar netstandard2.0. Setelah beberapa saat saya yakin akan ada standar bersih yang lebih baru lagi (3.x?) Yang akan mengejar hal-hal baru yang mengkilap dari netcoreapp, tetapi itu akan memakan lebih banyak waktu dan mengapa SEMUA kerangka kerja asp.net harus dilumpuhkan untuk memperlambat perkembangan . Agak menyenangkan memiliki satu tumpukan ASP.NET Core yang bergerak sangat cepat selama ada juga yang kedua yang memberi orang dukungan jangka panjang yang mematuhi standar net.

@FransBouma Oh, maaf, saya tidak menyadari ukuran sampel Anda begitu besar. 257 komentar dengan bias yang kuat terhadap orang-orang yang tidak menyukai keputusan itu? Sulit untuk berdebat dengan itu.

DISCLAIMER: Saya bukan ahli Big Data.

@davidfowl :

Sepanjang utas ini, Anda menyebut System.DirectoryServices sebagai salah satu hal inti. Saya berasumsi Anda memiliki beberapa dependensi yang menurut Anda akan memakan waktu lama untuk di-porting atau yang tidak akan pernah di-porting. Jika 2.0 mendukung .NET Framework, apakah dependensi tersebut akan berpindah dalam setahun?

Ya, kami memiliki hal-hal lain. Layanan System.Directory adalah apa yang saya tunjukkan karena bahkan namespace yang diminta teratas belum siap. Semua yang lain lebih buruk. Penganalisis portabilitas API bahkan tidak diperbarui untuk VS 2017 tempat kami dapat menjalankannya. Penganalisis untuk melihat apakah Anda bahkan dapat melakukan port belum diinvestasikan dan kami sudah menjatuhkan dukungan.

Yang mana?

Halaman pisau cukur sangat besar, saya sudah menyebutkannya beberapa kali.

Saya tidak tahu apa-apa tentang stackoverflow.com tetapi apakah mungkin untuk memecah-mecah (saya tidak ingin mengatakan "layanan mikro") sehingga ASP.NET Core dapat digunakan untuk beberapa bagian?

Tidak, ini tidak mungkin. Kami tidak merender dalam 18 md dengan melakukan panggilan API dan menambahkan overhead di antara berbagai hal. Saya senang membahas arsitektur kapan saja, Anda akan melihat itu bukan rute yang masuk akal.

Saya pikir saya menjelaskan ini sebelumnya tetapi ini dia lagi:

API apa pun yang merupakan bagian dari standar bersih yang perlu dikembangkan akan berkembang perlahan. Hal-hal dapat dibangun di atas standar bersih dan dapat berjalan di mana saja, dan itu bagus. Saat Anda membutuhkan API baru, katakanlah, klien http, atau SSL Stream, atau Int, atau String, atau Array, atau LINQ atau salah satu primitif yang ada di NET Standard, versi .NET Standard baru harus dibuat dan implementasi perlu untuk setuju bahwa mereka akan menerapkannya. Sekarang itu bukan akhir dunia karena kita memiliki sebagian besar dari mereka sekarang, mono, .NET Core, .NET Framework, UWP tetapi ada yang lain seperti Unity (dan mungkin yang lain). Setiap vertikal .NET memiliki kerangka waktu dan siklus pengirimannya sendiri, masing-masing adalah produk mereka sendiri yang terpisah dan itu tidak dapat diabaikan.

Tapi sekarang Anda mengerti, versi standar bersih baru dibuat saat API baru online. Jika perpustakaan ingin menggunakan API baru ini, Anda akan segera kehilangan dukungan untuk semua platform. Anda dapat melakukan kompilasi silang dan mencoba melakukan polyfill tetapi itu tidak menskala untuk semua perubahan.

Semoga itu memberi Anda gambaran tentang seperti apa prosesnya membawa API ke standar bersih. @terrajobst akan memiliki ide yang lebih baik tentang apa rencananya.

@DamianEdwards dan @shanselman Bagaimana dengan Service Fabric dan Unit Test?

Dalam kasus kami, kami memiliki proyek layanan mikro besar dengan banyak aplikasi SF yang merupakan proyek Inti tetapi menggunakan .Net Framework 4.5 hingga 4.6. (sesuatu). SF saat ini tidak mendukung netcoreapp oleh karena itu kami harus menggunakan .Net Framework tetapi karena kami tidak ingin ketinggalan, kami menggunakan proyek .Net Core.

(masalah lain adalah) Karena layanan kami adalah .Net Framework dan MS Fakes tidak tersedia untuk netcoreapp, semua pengujian unit kami normal (atau haruskah saya katakan warisan). Proyek Net Framework. Hampir semua perpustakaan kami menggunakan standar bersih 1.0 hingga 1.6.

Sekali lagi aplikasi klien kami menggunakan Xamarin Forms + UWP dan kami berhasil menggunakan netstandard sehingga lib kami kompatibel.

Apakah ini berarti kita terjebak dan tidak dapat meningkatkan ke .Net Core 2.0 dan netcoreapp2.0 dan netstandard 2.0?

@NickCraver

Halaman pisau cukur sangat besar, saya sudah menyebutkannya beberapa kali.

Saya mengerti yang ini, tetapi saya tidak percaya bahwa Anda akan mengubah semua stack overflow menjadi halaman pisau cukur saja. Jika Anda sudah menggunakan MVC hari ini, mengapa tidak port ke tampilan biasa dan ketika lebih banyak dependensi online, port ke halaman silet. Cara halaman pisau cukur dirancang membuatnya sepele untuk beralih dari tindakan pengontrol ke halaman pisau cukur.

Ya, kami memiliki hal-hal lain. Layanan System.Directory adalah apa yang saya tunjukkan karena bahkan namespace yang diminta teratas belum siap. Semua yang lain lebih buruk. Penganalisis portabilitas API bahkan tidak diperbarui untuk VS 2017 tempat kami dapat menjalankannya. Penganalisis untuk melihat apakah Anda bahkan dapat melakukan port belum diinvestasikan dan kami sudah menjatuhkan dukungan.

Pastikan untuk mengeskalasi daftar dependensi itu sehingga kami tahu apa yang penting.

@aboo

Apakah ini berarti kita terjebak dan tidak dapat meningkatkan ke .Net Core 2.0 dan netcoreapp2.0 dan netstandard 2.0?

Maksud Anda ASP.NET Core 2.0 dan? .NET Core 2.0 dan .NET Standard 2.0 tidak benar-benar berlaku di sini.

Ya, Anda harus tetap menggunakan ASP.NET Core 1.x.

Sebagian besar pekerjaan yang dilakukan untuk membuat hal-hal yang kompatibel dilakukan di .NET Core 2.0 dan .NET Standard 2.0. ASP.NET Core 2.0 sejujurnya tidak memiliki banyak fitur baru. Kami mengatakan bahwa kami akan mem-backport SignalR ke ASP.NET Core 1.x (yang merupakan post 2.0). Apakah itu hanya masalah persepsi?

@davidfowl Saya pikir Anda secara besar-besaran meremehkan ketakutan yang menyerang hati pengembang windows ketika Anda diberi tahu bahwa Anda harus memigrasikan sesuatu. _Terutama_ ketika tumpukan baru belum mencapai paritas fitur dengan tumpukan lama, dan tidak diketahui apakah dan kapan itu akan terjadi. Ini pada dasarnya mengumumkan EOL-ing dari ASP.NET Core pada .NET Framework penuh. Dan, sementara itu mungkin bukan rencana jangka panjang, itu diumumkan sebagai fitur, dan orang-orang berpikir itu mungkin bertahan untuk sementara waktu. Peta jalan sedang bergeser saat kita berbicara. Rapat akan diadakan.

Kami memiliki beberapa hal lama yang menjijikkan yang harus kami dukung karena konektor database dan SDK yang dikelola secara nominal. Beberapa dari vendor ini jauh lebih mungkin untuk merilis API baru yang disembelih dengan 30% fungsionalitas yang ada, antarmuka HTML5, dan rangkaian bug baru daripada mempertahankan produk mereka yang sudah ada. Atau mereka mungkin hanya mendapatkan pesaing, merilis produk dan dengan cepat EOL itu. Beberapa vendor ini cukup besar untuk dikenali. Kami memiliki banyak kode yang bagus, tetapi beberapa dari kode itu juga tinggal di daerah kumuh windows meskipun kami telah berusaha sebaik mungkin karena tidak selalu di bawah kendali kami. Teknologi lama tidak hanya pensiun dengan anggun. Itu bersembunyi di bawah tempat tidur Anda, di lemari kami, dan di bawah keyboard Anda.

Saya lebih khawatir tentang langkah ini yang menandakan kemungkinan mengesampingkan .NET Standard daripada saya tentang sisanya. .NET Standard awalnya tampak seperti sesuatu yang akan membawa implementasi yang berbeda lebih dekat dan lebih dekat ke paritas fitur sambil memungkinkan konsumen untuk bermigrasi ke platform yang berkembang dan berkembang. Sekarang terdengar seperti tidak lebih dari tonggak fitur .NET Core. Anda tidak akan dapat (atau ingin) menargetkan executable ke .NET Standard - hanya perpustakaan. Dan sepertinya akan ada lebih sedikit perencanaan yang terlibat dalam .NET Standard, dan sebaliknya itu hanya akan dicap dengan apa pun yang digunakan di ASP.NET karena sudah terlambat untuk berubah. Bagaimanapun, itu sudah akan diproduksi.

Pengembang lain harus memercikkan kode dengan arahan kompiler, membagi kode menjadi perpustakaan khusus platform dan mengkompilasi dengan beberapa target. Bagian kasar dari saya ingin tim ASP.NET Core melakukan dogfood sehingga Anda akan tertarik pada runtime dan dukungan perkakas yang lebih baik untuk skenario multi-penargetan dan multi-platform. Dan jika tim Anda menginginkannya, maka kami mungkin mendapatkannya. Bagian praktis dari saya mengatakan bahwa minimal, Anda harus memiliki rilis berkala ASP.NET Core yang menargetkan .NET Standard. Anda tetap harus membuat rilis _stable_ yang sebenarnya. Tidak ada yang hanya akan mengkompilasi cabang master dari git dan menyebarkannya ke produksi. Mengapa tidak melakukan iterasi yang lebih kecil dari .NET Standard dan mencocokkannya dengan rilis ASP.NET yang ditandai?

Juga, apakah akan ada ASP.NET baru untuk desktop? Semua keriuhan membuatnya terdengar seperti ASP.NET Core adalah satu-satunya ASP.NET. Sekarang sepertinya Anda tidak akan mendapatkan sesuatu yang baru di ASP.NET kecuali Anda menggunakan .NET Core. Dan itu akan mengubah banyak strategi bisnis. Ada banyak kebingungan yang terjadi dengan peta jalan.

MVC 5 tidak akan pernah hilang, kami tidak mencela apa pun. Ini akan didukung selama .NET Framework ada.

Ya, kami cukup sadar bahwa barang-barang lama akan tetap ada. Biasanya begitu, dan kami menghargai itu. Tetapi apakah hal-hal baru akan masuk ke kerangka kerja "penuh" sangat penting. Kita perlu tahu ke mana arahnya. Kami tidak ingin naik kereta sampai akhir dan hanya kemudian berpikir tentang bagaimana untuk bergerak maju. Kami juga membuat penumpang kami khawatir. Dan perbedaan antara .NET Core dan .NET Framework membuat banyak orang tidak yakin tentang masa depan. Saya mengajukan pertanyaan satu setengah tahun yang lalu tentang kapan bagian tertentu dari fungsionalitas akan didukung di .NET Core. Saya bahkan bertanya apakah itu akan diterima jika saya mengerjakannya secara pribadi. Komunikasi menjadi jarang. Aku masih tidak tahu apa yang akan terjadi padanya. Jenis ketidakpastian tentang skenario dan garis waktu yang didukung membuat perbedaan besar dalam kode yang kami tulis. Bahkan mengetahui bagian mana dari kerangka kerja desktop yang berprioritas rendah dapat memberi orang cukup waktu untuk bermigrasi alih-alih menunggu pembaruan status.

Singkatnya, saya mendukung apa yang Anda lakukan dan tujuan di baliknya. Dan saya tahu itu sulit ketika kita sampai di sini dan mengeluh tentang keputusan yang Anda buat untuk alasan yang sangat bagus. Tetapi banyak orang tidak mau naik kereta perintis karena mereka tidak bisa, dan yang lain tidak mau karena mereka tidak tahu ke mana arahnya.

@davidfowl kurasa. Apa yang Anda sebut proyek inti (baru) dengan .Net Framework? Apa pun itu, pemahaman saya dari postingan tersebut adalah bahwa netstandard vNext tidak akan mendukungnya.

@markrendle Kami adalah pelanggan nyata. Kami memberi tahu orang-orang bahwa hal-hal tidak akan berhasil. Saya tahu arsitektur saya lebih baik daripada Anda, jadi komentar arogan tidak membantu. Untuk poin Anda:

Tim tidak hanya melakukan ini untuk itu. Ada banyak fitur dan pengoptimalan baru yang siap (atau hampir siap) untuk diluncurkan di .NET Core yang sangat berguna bagi orang-orang yang membangun aplikasi web modern, API, dan layanan mikro, dan menunggu fitur tersebut mendarat di Windows .NET Framework penuh akan menunda rilis selama berbulan-bulan.

Tidak ada yang menentang mereka juga mendukung hal-hal ini. Keluhan kami secara universal tentang menjatuhkan dukungan, bukan menambahkan fitur baru secara kondisional.

Banyak keluhan yang saya lihat di utas ini adalah beberapa variasi dari "Saya tidak bisa melakukan X di .NET Core 2.0" padahal sebenarnya maksud penulis adalah "Saya harus mengubah cara saya melakukan X di .NET Core 2.0". Ya, Anda harus berubah. Tidak, itu bukan hal yang buruk. Jika Anda memiliki sepotong kecil fungsi diskrit dalam aplikasi ASP.NET MVC Anda yang melakukan sesuatu dengan file PDF atau DOCX, dan Anda benar-benar tidak dapat menemukan cara yang lebih baik untuk melakukan apa pun itu (sudahkah Anda mencoba?), maka hancurkan itu fungsionalitas ke dalam layanan mikro yang berjalan pada .NET penuh pada Windows Server dan menyebutnya sebagai API HTTP dari aplikasi .NET Core Anda. Mengurai aplikasi dan memindahkan fungsionalitas tertentu ke dalam layanan kecil yang mandiri bahkan bukan solusi, ini adalah praktik terbaik untuk tujuan umum.

Ini sangat jauh dari basis saya tidak tahu harus mulai dari mana. Halaman kami akan jauh lebih lambat dan lebih mahal di "layanan mikro". Kami akan memakan lebih banyak waktu secara signifikan di GC daripada yang kami lakukan di perenderan halaman dengan pengaturan seperti itu. Ini juga membuat asumsi bahwa ketergantungan kerangka kerja penuh bukanlah bagian penting dari setiap render halaman. Asumsi yang buruk.

.NET Core 2.0 bahkan belum dalam pratinjau publik yang layak, jadi mengeluh bahwa itu tidak mendapat dukungan untuk LDAP atau apa pun yang tampaknya terlalu dini. Jika RTM muncul di Q3 dan masih tidak ada cara untuk berinteraksi dengan AD atau Kerberos atau apa pun, maka komplainlah (walaupun pikirkan juga tentang migrasi ke sistem otentikasi berbasis token modern karena ini bukan tahun 2008 lagi).

Kami telah diberitahu bahwa mereka tidak akan ada di sana. Perhatikan berdiri. Atau lihat GitHub yang diberi label "Masa Depan". Kami mengeluh sekarang karena keputusan buruk ini akan dikirimkan pada Q3.

Ada migrasi yang lancar dari ASP.NET MVC 4.5 ke ASP.NET Core 2.0. Ini disebut ASP.NET Core 1.0 (dan saya setuju bahwa harus ada janji dukungan jangka panjang untuk 1.0 dalam situasi tersebut).

Dukungan jangka panjang tidak berarti itu bukan jalan buntu. Kita masih bisa dengan mudah terdampar di 1.x ketika sudah berakhir. Dalam hal ini, kami akan memiliki dukungan yang lebih lama pada kerangka kerja penuh.

Full .NET menyusul dan Anda dapat menjalankan ASP.NET Core 2.x di atasnya

Itu menargetkan netcoreapp , itu tidak akan terjadi.

...atau Teknologi pihak ketiga apa pun yang Anda andalkan mendukung .NET Core (atau dapat diganti dengan teknologi setara yang mendukung .NET Core).

Perpustakaan-perpustakaan tersebut seringkali berada di luar kendali orang dan anggaran waktu. Bahkan perpustakaan dari Microsoft tidak ditingkatkan . Saya sedang berjuang dengan tim SQL sekarang untuk meningkatkan paket mereka agar dapat bekerja pada sistem proyek baru karena install.ps1 berfungsi. Jika kami bahkan tidak bisa mendapatkan perbaikan sederhana itu, kami disekrup dengan port netstandard .

Ingatlah bahwa—sementara tim Anda mungkin dilumpuhkan oleh ketergantungan eksternal atau kebijakan atau politik internal perusahaan atau sekadar kelembaman—ada ratusan ribu, jika bukan jutaan, pengembang di dunia yang ingin membangun aplikasi, layanan, dan API menggunakan modern pola arsitektur dan platform teknologi baru (cloud/edge/IoT/etc), untuk siapa ASP.NET Core 2.0 sangat cocok. Mereka menginginkannya cepat, terukur, dan lintas platform; hal-hal itu penting bagi banyak orang. Meminta Microsoft untuk mengabaikan pasar yang berkembang pesat itu, hanya karena pemasok kontrol pihak ketiga Anda atau proyek sumber terbuka belum mem-porting kode mereka, adalah konyol.

Menyebutnya konyol adalah meremehkan, kasar, dan tidak beralasan. Ini adalah hidup kita. Ini adalah aplikasi kami. Ini adalah hal-hal yang telah kami ciptakan selama bertahun-tahun atau puluhan tahun dan tiba-tiba sebelum rilis kami mengetahui bahwa prospeknya adalah waktu yang terbatas bagi kami, sulit. Banyak ketidakpastian diperkenalkan untuk sedikitnya. Itu bukan sesuatu yang Anda inginkan dalam karir Anda.

setiap titik masuk akal, tetapi ingat bahwa di alam semesta ini semuanya akan berjalan dalam keadaan yang membutuhkan lebih sedikit energi, maka pastikan bahwa keadaan itu adalah tempat yang Anda inginkan, karena kita akan pergi ke sana dengan cara atau cara lain.
Jadi jika Anda ingin mencapai keadaan tertentu, pastikan itu membutuhkan lebih sedikit energi daripada yang dibutuhkan untuk tetap berada di tempat kita sekarang.

Saya baru saja membaca seluruh utas ini setelah seseorang menyebutkan ini sebagai tambahan di IRC - saya belum melihat pengumuman resmi tentang ini - dan saya benar-benar kecewa.

Saya telah menonton .NET Core, terlibat dan mengubah proyek kecil dari .NET Framework ke .NET Standard / .NET Core untuk mendapatkan pengalaman dengan SDK dan runtime baru, dan untuk menjalankan proyek ini di macOS dan Linux .

Target besar saya adalah layanan web perusahaan besar yang menggunakan banyak komponen yang belum tersedia di .NET Core 1.0 atau 1.1. Ini termasuk, di luar kepala saya:

• Direktori Aktif ( System.DirectoryServices ), digunakan untuk otentikasi dan manajemen pengguna
• Entity Framework 6 ( EntityFramework ), karena EF Core belum mendukung banyak fungsi yang kami gunakan.
• OData ( Microsoft.Data.Services / System.Data.Services ) v1-3, pustaka Javascript klien yang kami gunakan tidak mendukung v4 (belum) dan WebAPI OData jauh lebih rumit untuk disiapkan.
• Manajemen IIS ( System.Web.Management ) dan .NET Remoting ( System.Runtime.Remoting ) untuk kemampuan layanan web untuk meningkatkan dirinya sendiri - meskipun ini dapat diekstraksi ke aplikasi mandiri.
• SinyalR
• Kustom IHttpHandler s dan IHttpModule s, yang harus disesuaikan dengan apa pun yang setara dengan ASP.NET Core, mungkin semacam middleware
• Sejumlah besar barang khusus menggunakan ekstensibilitas ASP.NET WebAPI.
• Saya pikir kita bahkan mungkin menggunakan Microsoft.TeamFoundationServer.ExtendedClient di server, yang hanya mendukung net46, memiliki beberapa rakitan asli, dan memiliki peluang 0% untuk bekerja pada .NET Core 2.0.
• dll.

Karena ukuran dan kerumitan layanan ini, migrasi apa pun ke .NET Core harus bertahap, dan kemungkinan besar kami mungkin harus menggunakan beberapa API baru di ASP.NET-Core-2.0, saya tidak tahu namun, kita belum sampai sejauh itu.

Menghapus kemampuan untuk menjalankan ASP.NET Core pada .NET Framework berarti bahwa migrasi harus dilakukan dengan gaya big-bang jika ASP.NET Core 1.x bukan batu loncatan yang layak. Kami langsung kehilangan tahap "jalankan kerangka kerja baru di runtime lama" sebelum "jalankan kerangka kerja baru di runtime baru". Ini adalah strategi manajemen perubahan yang mengerikan untuk sistem besar mana pun.

Saya tidak akan terlalu keberatan jika dukungan .NET Framework dijatuhkan setelah .NET Core berada pada atau mendekati paritas, tetapi masih cukup jauh di belakang untuk aplikasi yang cukup canggih, dan saya tidak berpikir 2.0 adalah tempat yang tepat untuk membuat seperti perubahan yang merusak.

@davidfowl

Saya mengerti yang ini, tetapi saya tidak percaya bahwa Anda akan mengubah semua stack overflow menjadi halaman pisau cukur saja. Jika Anda sudah menggunakan MVC hari ini, mengapa tidak port ke tampilan biasa dan ketika lebih banyak dependensi online, port ke halaman silet. Cara halaman pisau cukur dirancang membuatnya sepele untuk beralih dari tindakan pengontrol ke halaman pisau cukur.

Banyak perpustakaan, dll. yang dibagikan di seluruh aplikasi sedang dimainkan di sini. Stack Overflow adalah banyak aplikasi (situs web utama hampir seluruhnya adalah satu aplikasi, tetapi sebagai sebuah perusahaan: kami memiliki banyak hal yang terkait dan berkomunikasi.

Pastikan untuk mengeskalasi daftar dependensi itu sehingga kami tahu apa yang penting.

Ya, saya melakukan itu. Tapi itu tidak akan menjadi ketergantungan terakhir, hanya pemblokir terbesar karena kami bahkan tidak bisa masuk ke beberapa aplikasi tanpanya. Ini adalah pemecah layar pertama. Saya akan mencoba dan melakukan penganalisis portabilitas penuh di seluruh aplikasi kami minggu ini (setelah peluncuran pagi ini), tetapi saya khawatir itu hanya akan lebih membuat depresi. Akan membantu jika penganalisis bahkan diperbarui untuk perkakas saat ini sebelum gerakan seperti ini dipertimbangkan.

Data membantu, saya akan mencoba dan mendapatkan lebih banyak data Anda - kecuali jika tidak ada kemungkinan untuk mengubah keputusan ini. Jika itu masalahnya, tolong beri tahu kami agar saya tidak menginvestasikan waktu saya lagi di dalamnya.

Sebagai catatan: OData adalah perpustakaan lain yang belum mendukung netcoreapp.

Sebenarnya itu bahkan masih berbasis System.Web (Anda harus menggunakannya melalui middleware OWIN di ASP.NET Core) dan mereka menjanjikan dukungan (lihat https://github.com/OData/WebApi/issues/939).

Masih layak disebut. Terutama karena itu dari Microsoft.

EDIT: @yaakov-h 2 menit lebih cepat, jadi +1 untuk penyebutannya tentang OData

Saya masih di sini membalas karena beberapa alasan

• aku peduli
• Tidur adalah untuk yang lemah
• Saya perlu memanggil FUD karena seseorang di internet salah

@NickCraver

Banyak perpustakaan, dll. yang dibagikan di seluruh aplikasi sedang dimainkan di sini. Stack Overflow adalah banyak aplikasi (situs web utama hampir seluruhnya adalah satu aplikasi, tetapi sebagai sebuah perusahaan: kami memiliki banyak hal yang terkait dan berkomunikasi.

Itu hanya berarti Anda tidak dapat menggunakan halaman Razor tbh, ASP.NET Core 2.0 memiliki banyak hal kecil tetapi tidak ada fitur atau perbaikan besar yang juga tidak di-porting kembali ke 1.x. Hal EOL sangat nyata dan saya pribadi tidak berpikir ASP.NET Core 2.0 mendukung .NET Framework untuk satu tahun lagi akan membantu. Kami benar-benar membahas perubahan arah di sini, apakah kami mendukung .NET Framework selamanya, atau tidak, benar-benar tidak ada peralihan.

@dustinmoris bukan hanya itu. juga merupakan masalah harapan. Kasus penggunaan Anda mungkin tidak sama dengan orang lain.

Saya sedang mengembangkan aplikasi aspnetcore 1.* dan menggunakan desktop .NET sebagai runtime (LOB untuk perusahaan).

Dan saya mengerti apa perbedaan antara .net core runtime, netstandard, dll (hanya untuk memastikan ini bukan komentar tentang kesalahpahaman tentang itu)

Migrasi saya adalah ke aspnet core terlebih dahulu (menargetkan .net desktop) karena aliran/visi/dll, mengkonsolidasikannya, dan SETELAH memindahkannya ke .net core (jika mungkin), adalah skenario yang menentukan dalam pilihan aspnetcore.

Masalah ini sedikit tidak terduga, karena aspnetcore 1.* selalu dipasarkan sebagai "berjalan di kedua kerangka kerja", tanpa peringatan afaik tentang menjatuhkannya berikutnya (versi atau tahun).
Saya mengharapkan setidaknya siklus usang -> usang, atau hanya fitur yang tidak didukung (tidak apa-apa).

Bagian yang baik tentang .net (dan aspnet sebagai pilihan untuk tumpukan web) adalah saya dapat memanfaatkan basis kode dan perpustakaan yang ada.
Beberapa internal, tidak ada roi nyata untuk memigrasi ini, ketika target (.net core/netstandard) terlalu cair.
Beberapa bersifat eksternal, dan sulit diubah, jika ini tidak berfungsi di penutupan netcoreapp2, saya tidak dapat menggunakan ini.

Ditambah ide saya adalah netstandard2 bukan netcoreapp2 .
Bagaimana saya bisa mulai mengevaluasi migrasi lib ke netstandard2, jika belum ada? Sulit untuk mengevaluasi migrasi berdasarkan bit pratinjau dan janji (dan tahun-tahun terakhir menurunkan kepercayaan saya pada stabilitas janji)

Saya mengerti adalah skenario yang berbeda dari sepenuhnya greenfield, tetapi juga jika greenfield saya ingin menggunakan kembali beberapa lib, karena saya perlu berinteraksi dengan sistem yang ada (Excel/pdf/etc), tidak menulis ulang semuanya dari awal.
Atau tambahkan layanan mikro sebagai rpc hanya karena tren terbaru, karena membuat segalanya lebih rumit (itu adalah pilihan yang ingin saya evaluasi dan lakukan, tidak dipaksa untuk membungkus lib yang ada). Saya perlu memberikan nilai (aliran dev aspnetcore bagus dan produktif), bukan hanya mengubah arsitektur.

Dalam evaluasi ekosistem pribadi saya, untuk kasus penggunaan saya, ketersediaan .net core dan/atau lib netstandard terlalu rendah (tidak semua orang hanya menggunakan nuget.org oss pkgs gratis). Jadi jika saya perlu bermigrasi dengan susah payah ke tumpukan baru, saya perlu mengevaluasi juga tumpukan lain (biaya/manfaat/masa depan/kepercayaan/dll)

Saya tidak hanya menulis aplikasi web TODO, saya menggunakan .NET karena saya telah menyiapkan banyak hal selama bertahun-tahun, jadi saya dapat mengubah satu hal (dalam hal ini aspnetcore, dan membiarkan sisanya untuk iterasi ini).
Ubah saja semuanya adalah resep untuk bencana dalam skenario saya, dan ketika saya perlu melakukan itu, saya harus benar-benar mulai mengevaluasi apakah lebih masuk akal untuk bermigrasi ke tumpukan lain (sebagai Java/node) di mana lib ada.

Migrasi yang lancar membutuhkan waktu, saya suka visi untuk inti aspnet masa depan. tetapi jika saya tidak memiliki jalan yang jelas (atau ragu-ragu), sulit untuk menjual secara internal.

Yang mengatakan, meninggalkan desktop .net, dapat menjadi pertaruhan yang baik dari tim aspnet untuk bergerak lebih cepat dan memilih lebih banyak pengguna baru (atau tidak kehilangan arus ke node/java).
Tapi yang pasti, akan membuat hidup lebih sulit bagi dev pada dering yang lebih lambat, dan ini adalah panggilan tim aspnet (produk mereka).
Umpan balik saya adalah untuk tidak melakukan itu, dan bekerja keras untuk mendukung fw, karena sebagai pengembang, saya membutuhkan kepercayaan dan stabilitas, dan tahun-tahun terakhir di mana agak terlalu cair dalam ekosistem .net (bukan hanya netcore/project.json, tetapi sebelumnya juga, dan pemasaran/penginjil tidak membantu menurunkan kepercayaan)

@yaakov-h

Jika Anda memutuskan untuk port ke ASP.NET Core (baik 1.x atau 2.x), Anda memerlukan proses lain. ASP.NET Core tidak berjalan di System.Web sehingga Anda tidak dapat melakukan port bertahap di proyek yang sama.

Saya tidak akan terlalu keberatan jika dukungan .NET Framework dijatuhkan setelah .NET Core berada pada atau mendekati paritas, tetapi masih cukup jauh di belakang untuk aplikasi yang cukup canggih, dan saya tidak berpikir 2.0 adalah tempat yang tepat untuk membuat seperti perubahan yang merusak.

Tidak ada waktu yang tepat untuk menjatuhkannya. Itu tidak pernah dimaksudkan untuk mencapai paritas dengan .NET Framework dan sangat mungkin bahwa ada dependensi yang Anda miliki yang tidak akan pernah di-porting. Mengingat itu, pertanyaan saya adalah, apakah Anda mendesain ulang aplikasi atau apakah Anda harus tetap menggunakan .NET Framework selamanya?

@davidfowl yang sepenuhnya bergantung pada dependensi hulu kami. Saat ini, kami akan tetap menggunakan .NET Framework selamanya.

Yang cukup menarik, sebagian besar dari pihak ke-3 sudah memiliki rilis netstandard . Sebagian besar dependensi Microsoft yang membuat kami tetap menggunakan .NET Framework, dan beberapa di antaranya tampaknya setengah ditinggalkan (mis. OData)

@NickCraver Saya tidak bermaksud meremehkan atau menghina. Saya menghargai bahwa ini adalah perubahan di akhir hari, dan itu membuat frustrasi bagian mana pun dari komunitas yang terpengaruh olehnya, dan jika saya terpengaruh olehnya, saya mungkin akan membuat keributan juga. Saya tidak (di tempat saya bekerja kami masih menggunakan ASP.NET WebAPI 5.2.3), jadi pendapat saya tentang situasi ini kurang emosional.

Lihat seperti ini: jika Anda mulai dari awal membangun Stack Exchange berikutnya (apa pun itu) hari ini, bukankah barang-barang yang ada di netcoreapp20 yang ingin digunakan oleh tim Inti ASP.NET ( seperti UTF8Strings dan Pipelines dan alokasi rendah, asinkron, _fast_ primitif (saya kira sedikit di sana)) membuatnya lebih menarik bagi Anda daripada .NET penuh? Bukankah .NET Core 2.0 umumnya lebih masuk akal daripada .NET 4.7.1 penuh? Jika Anda memilih antara tumpukan web yang dapat berevolusi dan beradaptasi dengan perubahan dengan cepat, vs tumpukan web yang terikat tidak dapat ditarik kembali ke teknologi dasar yang bergerak lambat dengan hampir dua dekade kode warisan yang perlu dikhawatirkan tentang dukungan, mana yang akan Anda pilih?

@ZigMeowNyan

Saya lebih khawatir tentang langkah ini yang menandakan kemungkinan mengesampingkan .NET Standard daripada saya tentang sisanya. .NET Standard awalnya tampak seperti sesuatu yang akan membawa implementasi yang berbeda lebih dekat dan lebih dekat ke paritas fitur sambil memungkinkan konsumen untuk bermigrasi ke platform yang berkembang dan berkembang. Sekarang terdengar seperti tidak lebih dari tonggak fitur .NET Core. Anda tidak akan dapat (atau ingin) menargetkan executable ke .NET Standard - hanya perpustakaan. Dan sepertinya akan ada lebih sedikit perencanaan yang terlibat dalam .NET Standard, dan sebaliknya itu hanya akan dicap dengan apa pun yang digunakan di ASP.NET karena sudah terlambat untuk berubah. Bagaimanapun, itu sudah akan diproduksi.

Itu sebenarnya poin yang sangat bagus dan sesuatu yang layak dipertimbangkan. Anda harus memahami bahwa itu tidak ada hubungannya dengan .NET Standard yang dikesampingkan, itu hanya fisika. Jika setiap platform .NET bergerak dengan kecepatannya sendiri, maka menggunakan .NET Standard terbaru berarti kerangka kerja yang bergerak lebih lambat mendapatkan hal-hal yang lebih jarang. Itu adalah sesuatu yang harus diinternalisasi oleh semua orang. Itu tidak membuatnya kurang berguna, itu hanya sifat binatang itu. Satu-satunya cara untuk menghilangkan beban ini adalah dengan memiliki implementasi tunggal dan jadwal kapal tunggal yang sangat mempersempit tempat .NET dapat dijalankan.

Pengembang lain harus memercikkan kode dengan arahan kompiler, membagi kode menjadi perpustakaan khusus platform dan mengkompilasi dengan beberapa target. Bagian kasar dari saya ingin tim ASP.NET Core melakukan dogfood sehingga Anda akan tertarik pada runtime dan dukungan perkakas yang lebih baik untuk skenario multi-penargetan dan multi-platform. Dan jika tim Anda menginginkannya, maka kami mungkin mendapatkannya. Bagian praktis dari saya mengatakan bahwa minimal, Anda harus memiliki rilis berkala ASP.NET Core yang menargetkan .NET Standard. Anda tetap harus membuat rilis stabil yang sebenarnya. Tidak ada yang hanya akan mengkompilasi cabang master dari git dan menyebarkannya ke produksi. Mengapa tidak melakukan iterasi yang lebih kecil dari .NET Standard dan mencocokkannya dengan rilis ASP.NET yang ditandai?

Kami melakukan hal yang sama, ingat, kami masih menargetkan standar bersih untuk sekelompok perpustakaan kami dan itu memang berisi ifdefs. Namun, yang lain, menargetkan netstandard untuk menyiapkan kami memanfaatkan API baru dalam jangka waktu 2.x.

Singkatnya, saya mendukung apa yang Anda lakukan dan tujuan di baliknya. Dan saya tahu itu sulit ketika kita sampai di sini dan mengeluh tentang keputusan yang Anda buat untuk alasan yang sangat bagus. Tetapi banyak orang tidak mau naik kereta perintis karena mereka tidak bisa, dan yang lain tidak mau karena mereka tidak tahu ke mana arahnya.

Pertanyaan jujur ​​(ini yang saya tanyakan bukan Microsoft), apakah Anda lebih menyukai kompatibilitas daripada fitur baru? Jika ya, mengapa memilih ASP.NET Core?

Hanya pemikiran cepat lainnya: untuk setiap utas seperti ini, ada utas yang setara-tetapi-berlawanan di mana sekelompok orang yang berbeda — tetapi sama besarnya — menjadi kesal karena konsesi untuk mendukung .NET "lama" dibuat.

Cukup menarik sebagian besar pihak ke-3 sudah memiliki rilis standar bersih. Sebagian besar dependensi Microsoft yang membuat kami tetap menggunakan .NET Framework, dan beberapa di antaranya tampaknya setengah ditinggalkan (mis. OData)

😞.

@markrendle

• Banyak keluhan yang saya lihat di utas ini adalah beberapa variasi "Saya tidak bisa melakukan X di .NET Core 2.0" padahal yang sebenarnya penulis maksud adalah "Saya harus mengubah cara saya melakukan X di .NET Core 2.0" . Ya, Anda harus berubah. Tidak, itu bukan hal yang buruk. Jika Anda memiliki sepotong kecil fungsi diskrit dalam aplikasi ASP.NET MVC Anda yang melakukan sesuatu dengan file PDF atau DOCX, dan Anda benar-benar tidak dapat menemukan cara yang lebih baik untuk melakukan apa pun itu (sudahkah Anda mencoba?), maka hancurkan itu fungsionalitas ke dalam layanan mikro yang berjalan pada .NET penuh pada Windows Server dan menyebutnya sebagai API HTTP dari aplikasi .NET Core Anda. Mengurai aplikasi dan memindahkan fungsionalitas tertentu ke dalam layanan kecil yang mandiri bahkan bukan solusi, ini adalah praktik terbaik untuk tujuan umum.
NB Sejauh yang saya tahu, paket OpenXML sekarang mendukung .NET Standard, jadi bekerja dengan Word/Excel/apa pun seharusnya tidak mustahil.<<

Seperti yang telah dinyatakan orang lain, mengubah arsitektur desain bagus kami bukanlah rencana yang baik. Dalam kasus kami, kami membagikan kode antara pengujian aplikasi WPF kami dan server. Semakin banyak perbedaan yang kita buat di antara mereka, semakin rumit untuk dipertahankan.

Saya dapat meyakinkan Anda bahwa saya telah menghabiskan banyak waktu untuk menyelidiki alat terbaik yang kami gunakan untuk PDF, pembuatan DocX dan itu tidak sesederhana melakukan dengan XML terbuka. Kami menggunakan perpustakaan pihak ketiga karena ada puluhan ribu baris kode yang telah mereka kembangkan dan kami tidak perlu mengembangkan/memelihara/menguji. Itulah intinya.

Versi .net menjadi sangat rumit. Saya tidak jelas apakah di masa mendatang ASP.net akan dapat digunakan pada kerangka .net lengkap? Karena saya perlu berbagi kode antara server dan aplikasi desktop saya, apakah itu berarti saya tidak akan pernah memiliki versi terbaru ASP.Net? Ini bukan masalah dalam jangka pendek tetapi dalam jangka panjang dengan peningkatan keamanan dan lain-lain saya tidak ingin terlalu jauh dari versi terbaru. Saya yakin ada banyak orang lain di kapal saya di mana Anda memerlukan beberapa bentuk kompatibilitas dengan kerangka kerja penuh.

Untuk memperjelas apa yang saya lakukan adalah bahwa saya memiliki tiga perpustakaan saya sendiri yang dibagi antara berbagai aplikasi WPF dan server saya. Saya sama sekali tidak tahu pada titik ini Apis mana yang saya gunakan mungkin atau mungkin tidak tersedia di.net core. Dan kemudian di perpustakaan itu saya menggunakan versi desktop lengkap dari alat WPF Telerik dan SyncFusion untuk menghasilkan docx dan pdf. Beberapa atau semua fungsi yang digunakan alat tersebut mungkin tersedia atau tidak tersedia di .net core. Mencoba mengembangkan aplikasi berdasarkan mungkin atau mungkin tidak sangat sulit. Microsoft memiliki kerangka dasar yang brilian di .net, dan sementara saya memahami alasan di balik inti .net. Microsoft tampaknya telah melupakan pentingnya kompatibilitas ke belakang.

Stefan

@markrendle

Oh, maaf, saya tidak menyadari ukuran sampel Anda begitu besar. 257 komentar dengan bias yang kuat terhadap orang-orang yang tidak menyukai keputusan itu? Sulit untuk berdebat dengan itu. DISCLAIMER: Saya bukan ahli Big Data.

Tidak tahu apa yang aku lakukan padamu, tapi tidak perlu snark atau rengekan tingkat rendah seperti ini. Anda tahu betul utas ini hanyalah sebuah contoh.

@stefanolson

versi .net menjadi sangat rumit

Saya pikir ini adalah salah satu dari sedikit hal yang kita semua bisa sepakati.

Kami mencari port ke .Net Core x.
Masalah terbesar kami ada di sekitar:
NewRelic (tidak ada paket .Net Core, jadi kami perlu mencari alternatif)
NH (di mana EF Core tidak memiliki fitur tersebut).
ServiceBase (sepertinya akan datang ke .Net Core 2 di musim panas)

Kedengarannya seperti kita harus menargetkan Core 1.0 untuk sementara dan menunggu NH, EF meningkatkan atau menjadi kreatif.

Itu hanya berarti Anda tidak dapat menggunakan halaman Razor tbh, ASP.NET Core 2.0 memiliki banyak hal kecil tetapi tidak ada fitur atau perbaikan besar yang juga tidak di-porting kembali ke 1.x. Hal EOL sangat nyata dan saya pribadi tidak berpikir ASP.NET Core 2.0 mendukung .NET Framework untuk satu tahun lagi akan membantu. Kami benar-benar membahas perubahan arah di sini, apakah kami mendukung .NET Framework selamanya, atau tidak, benar-benar tidak ada peralihan.

Ini sedikit lebih besar dari halaman Razor, itu berarti tidak ada alasan untuk pindah . Tidak ada skenario (saat ini) di mana keduanya ada:

1. Kami akan didukung sepanjang waktu
2. Ada peningkatan aktual di sisi lain

Faktanya adalah bahwa ASP.NET Core tidak terlalu berguna tanpa ekosistem . Memiliki pengontrol yang membuat teks kembali bagus, tetapi tidak berguna untuk banyak skenario. Kami membutuhkan API. Kami membutuhkan perpustakaan. Kami membutuhkan ekosistem, itulah mengapa kami memilih .NET sejak awal .

Perubahan ini berasal dari kerangka kerja yang sepenuhnya mendukung kasus penggunaan kami saat ini menjadi kerangka kerja yang jelas belum siap. Ini bahkan tidak dekat dengan siap. Dan pratinjau untuk menguji apakah sudah siap bahkan tidak tersedia secara umum. Migrasi untuk mencari tahu janji apa yang akan siap tidak tersedia. Kami mengandalkan sejumlah besar janji dan banyak yang akan dibakar. Itulah cara terburuk yang mungkin untuk memasarkan hal-hal ini: terlalu menjanjikan dan memberikan terlalu banyak (pengalaman keseluruhan).

Saya pikir ASP.NET Core sangat bagus. Kalian melakukan hal-hal yang luar biasa. Saya cukup beruntung untuk membantu beberapa di antaranya. Tetapi sakelar ini pada saat ini buruk. Jika semua hal yang kami pikir akan di-porting benar- benar di-porting dalam kerangka waktu 2.x, maka bagus. Buat perubahan di 3.x kemudian. Porting sebelum alternatif siap dan menetapkan tenggat waktu kapan harus membunuh garis hidup EOL itu buruk. Memberitahu orang untuk port ke pemeliharaan -> versi EOL buruk.

Tolong, jangan lakukan perubahan ini sekarang. .NET lebih baik dari ini. Tunjukkan bahwa Anda peduli dengan pengguna Anda sama seperti semua orang di sini peduli dengan Anda. Kami tidak akan berada di sini jika kami tidak ingin membantu.

@FransBouma Anda (harus) tahu betul bahwa Microsoft memiliki basis data telemetri, umpan balik, dan data lain yang luas tentang apa yang dilakukan orang dengan teknologi mereka yang memberikan gambaran yang jauh lebih jelas daripada sejumlah utas Masalah GitHub, dan menurut saya bukan menunjukkan bahwa itu lebih kejam dari

Oh saya tidak tahu, dengan membaca posting di utas ini?

Versi .net menjadi sangat rumit. Saya tidak jelas apakah di masa mendatang ASP.net akan dapat digunakan pada kerangka .net lengkap? Karena saya perlu berbagi kode antara server dan aplikasi desktop saya, apakah itu berarti saya tidak akan pernah memiliki versi terbaru ASP.Net? Ini bukan masalah dalam jangka pendek tetapi dalam jangka panjang dengan peningkatan keamanan dan lain-lain saya tidak ingin terlalu jauh dari versi terbaru. Saya yakin ada banyak orang lain di kapal saya di mana Anda memerlukan beberapa bentuk kompatibilitas dengan kerangka kerja penuh.

Kisah berbagi kode di berbagai runtime .NET adalah .NET Standard. Pustaka Anda harus mencoba menargetkannya ke kode yang dibagikan di .NET Core dan .NET Framework.

Microsoft tampaknya telah melupakan pentingnya kompatibilitas ke belakang.

Masalahnya adalah, ASP.NET Core tidak pernah dimaksudkan untuk kompatibel ke belakang... Itu sebabnya ada perubahan paradigma besar dari ASP.NET 4.x. Sepertinya jika kompatibilitas mundur adalah bit urutan tinggi untuk Anda akan lebih baik menggunakan ASP.NET 4.x di .NET Framework. Itu didukung untuk masa mendatang dan akan ditambal keamanannya selama Windows masih hidup.

Meskipun tidak dimaksudkan demikian, 1.0 sangat kompatibel! Ini mendukung seluruh warisan ekosistem yang luas, dan kami menghargainya. Sepertinya pada saat itu tidak ada yang harus memberikan kue mereka atau menahan diri untuk tidak memakannya.

@NickCraver

Ini sedikit lebih besar dari halaman Razor, itu berarti tidak ada alasan untuk pindah. Tidak ada skenario (saat ini) di mana keduanya ada:

Bisakah Anda menguraikan?

Faktanya adalah bahwa ASP.NET Core tidak terlalu berguna tanpa ekosistem. Memiliki pengontrol yang membuat teks kembali bagus, tetapi tidak berguna untuk banyak skenario.

Itu bisa melakukannya dengan sangat cepat juga

Saya pikir ASP.NET Core sangat bagus. Kalian melakukan hal-hal yang luar biasa. Saya cukup beruntung untuk membantu beberapa di antaranya. Tetapi sakelar ini pada saat ini buruk. Jika semua hal yang kami pikir akan di-porting benar-benar di-porting dalam kerangka waktu 2.x, maka bagus. Buat perubahan di 3.x kemudian. Porting sebelum alternatif siap dan menetapkan tenggat waktu kapan harus membunuh garis hidup EOL itu buruk. Memberitahu orang untuk port ke pemeliharaan -> versi EOL buruk.

Saya tidak mengerti mengapa 2.x (support) dan 3.x (drop) lebih baik daripada 1.x (support) dan 2.x (drop). Bisakah Anda menjelaskannya kepada saya? Bagaimana itu membuat perbedaan ?

Beberapa rekomendasi sesi //BUILD 2017 untuk mereka yang peduli tentang dukungan jangka panjang dari variasi ASP.NET:

• Pembaruan Formulir Web ASP.NET T6009
  
  
  
  • yaitu mereka masih mengembangkan platform web .NET lengkap
  
  
• Dukungan T6072 untuk ASP.NET Core: Apa itu LTS?
  
  
  
  • Yang saya kira sedang diperbarui dengan panik sekarang :meringis:
  
  

@davidfowl :

Bagaimana itu membuat perbedaan?

Karena Anda telah menjanjikan beberapa API yang hilang paling signifikan untuk dikirimkan setelah 2.0, bukan?

@yaakov-h

Karena Anda telah menjanjikan beberapa API yang hilang paling signifikan untuk dikirimkan setelah 2.0, bukan?

Katakan padaku yang mana di ASP.NET Core?

@davidfowl System.DirectoryServices, System.Drawing disebutkan di atas.

Pertanyaan jujur ​​(ini yang saya tanyakan bukan Microsoft), apakah Anda lebih menyukai stabilitas dan kompatibilitas daripada fitur baru? Jika ya, mengapa memilih ASP.NET Core?

Saya pikir ini adalah pertanyaan yang sangat bagus. Jika kerangka .NET lengkap memberikan semua yang mereka butuhkan saat ini, mengapa begitu tertarik untuk bermigrasi ke tumpukan yang berbeda? Jika .NET Core dan ASP.NET Core diberi nama yang berbeda, tanpa nama .NET, maka saya pikir lebih sedikit orang yang akan berdebat tentang masalah migrasi. Tidak ada yang mengeluh bahwa mereka tidak dapat bermigrasi ke tumpukan web Go atau Node.js yang bergerak lebih cepat.

@davidfowl menjadi kompatibel dengan ASP.NET MVC 5.x adalah satu hal, menjadi kompatibel dengan .net framework adalah hal lain. Menjatuhkan .net framework adalah hal yang besar...

Saya tidak mengerti mengapa 2.x (support) dan 3.x (drop) lebih baik daripada 1.x (support) dan 2.x (drop).

Karena 2.x akan segera hadir setelah kami mengerti.

@davidfowl System.DirectoryServices, System.Drawing disebutkan di atas.

Itu tidak ada hubungannya dengan ASP.NET Core 1.x atau 2.x dan akan berjalan di keduanya saat online.

Seperti yang saya katakan, saya di sini hanya untuk memanggil FUD dan itu bagian darinya. Utas ini menjadi sangat besar sehingga tidak ada yang bisa melihat fakta di beberapa balasan.

@FransBouma Anda (harus) tahu betul bahwa Microsoft memiliki basis data telemetri, umpan balik, dan data lain yang luas tentang apa yang dilakukan orang dengan teknologi mereka yang memberikan gambaran yang jauh lebih jelas daripada sejumlah utas Masalah GitHub, dan menurut saya bukan menunjukkan bahwa itu lebih kejam dari

@markrendle telemetri bukan sihir. Anda tidak dapat mengukur mengapa ppl/dev tidak beralih, atau mengapa mereka beralih ke tumpukan lain, atau pentingnya proyek mereka dan seberapa besar mereka menyukai tumpukan (dan membantu orang lain, dengan konsultasi atau oss), atau apa yang mereka lakukan.

Utas ini persis seperti itu, umpan balik.

Saya tidak mengerti mengapa 2.x (support) dan 3.x (drop) lebih baik daripada 1.x (support) dan 2.x (drop). Bisakah Anda menjelaskannya kepada saya? Bagaimana itu membuat perbedaan?

@davidfowl waktu.
waktu untuk menetap sedikit. waktu untuk mengevaluasi sesuatu. waktu untuk mengubah satu hal suatu waktu. waktu untuk menggunakan paket netstandard2 dengan hal rtm. waktu untuk memindahkan lib kami ke netstandard2 (lebih mudah) daripada netstandard1 (lebih sulit). Waktu untuk mengubah satu hal waktu, bagi saya, sebagian besar.
Anda melakukan aspnet, tetapi produk saya tidak hanya aspnet, merupakan kombinasi dari banyak lib dan pengorbanan serta ekosistem.

Karena 2.x akan segera hadir setelah kami mengerti.

Apa hubungannya dengan itu? Bagaimana jika 2.0 akan datang pada akhir tahun atau pada bulan Januari? Apakah itu akan membuat perbedaan? Apa di 2.0 yang membuat 1.x tidak layak?

@yaakov-h Mereka disebutkan di sini di mana @shanselman berkata (penekanan milik saya)

AD – Benar-benar, ini adalah celah JIKA Anda ingin memanggil LDAP secara langsung. Anda pasti dapat mengautentikasi terhadap Windows Auth SEKARANG. Kami berencana untuk secara khusus memiliki namespace DirectoryServices untuk Core 2.0 sekitar jangka waktu musim panas
Menggambar – Benar-benar, ini adalah celah. Kami berencana untuk memiliki ini untuk Core 2.0 sekitar jangka waktu musim panas . Sampai saat ini, opsi standar bersih ini juga ada opsi ImageSharp, ImageResizer, Mono, dll

@davidfowl ini bukan tentang versi, ini tentang tanggal dan jatuh tempo .net core dan ekosistemnya.

@hikalkan

Maaf, saya mengerti itu dari POV tingkat yang sangat tinggi tetapi bukan dari yang teknis. Mungkin ini bukan diskusi teknis?

@enricosada

waktu untuk menetap sedikit. waktu untuk mengevaluasi sesuatu. waktu untuk mengubah satu hal suatu waktu. waktu untuk menggunakan paket netstandard2 dengan hal rtm. waktu untuk memindahkan lib kami ke netstandard2 (lebih mudah) daripada netstandard1 (lebih sulit). Waktu untuk mengubah satu hal waktu, bagi saya, sebagian besar.
Anda melakukan aspnet, tetapi produk saya tidak hanya aspnet, merupakan kombinasi dari banyak lib dan pengorbanan serta ekosistem.

Mengapa perbedaan itu membuat ASP.NET Core 2.0 secara khusus? Anda akan mendapatkan manfaat itu dari platform terlepas dari apa yang ASP.NET Core pilih untuk dilakukan.

@markrendle seseorang memberi saya kalender, karena musim mencakup seluruh kuartal (bisa 3 bulan dari sesuatu yang lain di kuartal yang sama) dan sangat membingungkan kami orang-orang belahan bumi selatan.

@enricosada Anda bisa mendapatkan banyak sekali informasi berguna dari telemetri dan sumber data lainnya (analisis web, data pencarian, umpan balik pelanggan langsung). Jauh lebih banyak daripada yang bisa Anda dapatkan dari massa yang marah di GitHub (betapapun wajarnya kemarahan setiap individu).

@yaakov-h Nah, RTM yang diproyeksikan saat ini untuk .NET Core 2.0 (dan juga ASP.NET Core 2.0) adalah kalender Q3, yaitu Juli/Agustus/September), dan Musim Panas di belahan bumi utara sebagian besar Juli/Agustus/September , jadi pada dasarnya hal yang sama.

Anda bisa mendapatkan banyak sekali informasi berguna dari telemetri dan sumber data lainnya (analisis web, data pencarian, umpan balik pelanggan langsung).

Saya bertanya-tanya seberapa andal telemetri ini - setidaknya bagian otomatisnya - untuk penerapan perusahaan. (Karena dari situlah sebagian besar serangan balik tampaknya berasal.)

Saya tidak mengerti mengapa 2.x (support) dan 3.x (drop) lebih baik daripada 1.x (support) dan 2.x (drop). Bisakah Anda menjelaskannya kepada saya? Bagaimana itu membuat perbedaan?

@davidfowl Waktu. Dan pengumuman yang tepat. Jika pesannya lebih jelas, orang tidak akan terkejut.

@davidfowl Waktu. Dan pengumuman yang tepat. Jika pesannya lebih jelas, orang tidak akan terkejut.

Saya mengerti tetapi saya tidak berpikir itu akan membuat perbedaan dalam kemampuan Anda untuk mem-porting apa pun. Kebijakan EOL yang sama masih ada.

Oke, setelah mengalami kesulitan untuk memahami masalah ini, saya ingin memberikan beberapa wawasan bagi mereka yang berjuang seperti saya dan juga memiliki beberapa pertanyaan.

jadi jika dipahami dengan benar, kita akhirnya akan memiliki netstandard menggantikan net framework.

Jadi mari kita asumsikan netcore tidak ada dan aspnet core didasarkan pada netstandard. itu berarti fitur akan datang lebih lambat.

Contoh:
2017 asp.net menginginkan Fitur A.
2018 netstandard mengimplementasikan Fitur A. kami mendapatkan Fitur A di ns.

Apa yang dikatakan tim adalah agar netcore tidak didasarkan pada standar net jadi:
2017 asp.net menginginkan Fitur A
Tim aspnet 2017 mengimplementasikan Fitur A. Asp.Net Core mendapatkan Fitur A di netcore.
2018 netstandard mengimplementasikan Fitur A. kami mendapatkan Fitur A di ns.

Jadi, keputusan ini sebenarnya membawa lebih banyak "fleksibilitas dan kecepatan" ke persamaan. Rilis lebih cepat untuk siapa yang dapat menggunakannya, umpan balik, dll. Saya pikir ini adalah tambahan yang bagus untuk ketenangan kerangka kerja bersih yang lambat. Fitur akan benar-benar matang ketika mencapai NS.

Jika memiliki netcore berdasarkan netstandard 2 berarti fitur dirilis 1 tahun (atau kerangka waktu apa pun) kemudian, orang masih akan berpendapat bahwa mereka menginginkan ini? Ini adalah skenario yang biasa kami gunakan dengan NET Framework .

Ini adalah surga bagi tim aspnet, dapat mengirimkan barang tanpa bergantung pada orang lain, dan juga merupakan kabar baik bagi pelanggan yang bisa mendapatkan barang cepat tersebut. Jika Anda tidak dapat menggunakan hal-hal yang cepat, tetap menggunakan versi sebelumnya adalah pertukaran yang wajar (dan motivasi bagi Anda/dependensi untuk meningkatkan.)

Penulis perpustakaan tetap harus TUJUAN untuk menargetkan standar bersih, dan jika Anda bisa maka jangan khawatir sama sekali.
Jika Anda membutuhkan sesuatu yang tidak ada di netstandard (mungkin halaman silet(?)) maka Anda harus menargetkan netcore, pada skenario 1, halaman silet mungkin bahkan tidak ada. Saya tidak melihat bagaimana ini bisa buruk, saya akan mengatakan itu adil.

Jadi pertanyaannya adalah, ketergantungan mana yang Anda miliki saat ini yang membatasi diri Anda untuk beralih ke NET Framework ke Net Core?
Saya mungkin satu-satunya di sini tetapi saya tidak pernah berharap inti aspnet bekerja di NET Framework selamanya, jelas bagi saya bahwa ini adalah langkah "transisi". Semua pengembangan saya yang saat ini membutuhkan NET Framework adalah splited . (dan tidak, ini bukan layanan mikro, ini jauh lebih sederhana dari itu).

dukungan 2.x dan penurunan 3.x tidak berbeda dengan dukungan 1.x dan penurunan 2.x. Saya akan menebak di sini dan mengatakan bahwa orang tidak memahami skenario dengan jelas, jadi saya harap ini menjelaskan setidaknya beberapa.

@NickCraver Anda mengatakan Anda ingin Microsoft mengembalikan keputusan ini. Apa saran Anda, untuk tidak memiliki netcore yang terisolasi dan memiliki rilis fitur yang lebih lambat? (pertanyaan jujur)

@davidfowl Saya pikir mungkin ada masalah tersembunyi yang halus dengan proposal saat ini yang mengkhawatirkan pengembang.
Jika Anda memiliki fitur A untuk asp.net (dengan netcore) maka Anda dapat memasarkan dan mengirim (dan mencentang kotak manajemen/pm) dan menjadi "malas" untuk mengimplementasikan pada netstandard, jika saya tidak salah inilah yang "bertaruh" pada tidak pasti adalah wasit di sini.
Jadi dalam contoh saya sebelumnya, netstandard mengimplementasikan Fitur A mungkin pada 2019, atau 2020, atau tidak pernah alih-alih 2018. <-- ini sepertinya masalah yang mungkin terjadi (?) Apakah saya benar? Bisakah Microsoft berkomitmen untuk sesuatu di sini?

Meskipun kita semua dapat berbeda pendapat apakah kita menyukai pengumuman itu, terima kasih kepada @davidfowl @DamianEdwards dan @shanselman karena telah meluangkan waktu untuk berdiskusi. Ini bukti lebih lanjut dari peningkatan keterlibatan dan keterbukaan.

Saya yakin beberapa orang akan berdebat tentang waktu dll, tetapi ini adalah kemajuan.

Contoh:
2017 asp.net menginginkan Fitur A.
2018 netstandard mengimplementasikan Fitur A. kami mendapatkan Fitur A di ns.

Apa yang dikatakan tim adalah agar netcore tidak didasarkan pada standar net jadi:
2017 asp.net menginginkan Fitur A
Tim aspnet 2017 mengimplementasikan Fitur A. Asp.Net Core mendapatkan Fitur A di netcore.
2018 netstandard mengimplementasikan Fitur A. kami mendapatkan Fitur A di ns.

yang seharusnya mereka lakukan adalah:
2017 tim aspnet membangun fitur yang dibutuhkan di lib X, yang mendukung netstandard2.0. Dengan cara ini aspnet bekerja pada semua yang dijalankan .netstandard, dan pengguna kemudian dapat menjalankannya di .net full karena lib X juga dapat digunakan di .NET full (hanya dengan menginstal nuget).

Sebaliknya, mereka tidak melakukan ini, mereka memaksa lib X menjadi .NET core saja (jika tidak, mengapa utas/keputusan ini di tempat pertama). Jika lib X sangat canggih sehingga memerlukan fitur CoreCLR, Microsoft harus bertanya pada diri sendiri mengapa fitur-fitur canggih ini tidak di-porting ke .NET full CLR.

Semuanya terasa seperti politik di mana MS membutuhkan .NET core/aspnet core yang bergerak cepat untuk memberikan pelanggan Azure tumpukan yang dapat digunakan dalam wadah di Azure sehingga bersaing dengan wadah berbasis JVM/NodeJS di AWS atau Google cloud. Dari perspektif bisnis mereka, saya bahkan bisa memahaminya. Tapi apa yang ditunjukkan adalah bahwa MS tidak memiliki prioritas mengenai .NET full untuk bergerak maju lebih cepat, karena tidak menempatkan sumber daya yang cukup pada .NET full untuk mengikuti inti .NET. Lihat jumlah API yang ditambahkan ke .NET penuh dalam 2 tahun terakhir. Apakah itu memberi tahu Anda bahwa tim besar sedang mengerjakannya?

Tidak.

Microsoft menjual sistem database besar, SQL Server Enterprise. Muncul dengan fitur enkripsi mewah. Tidak didukung pada inti .NET. Bersenang-senang menjual .NET core 2.0 kepada perusahaan yang merupakan pelanggan potensial dari sistem database yang mahal itu.

Anda mungkin ingin bergerak 'cepat', tetapi kecuali Anda benar-benar memahami tujuan yang Anda tuju, perlu satu atau dua menit untuk memutuskannya terlebih dahulu.

Semakin saya memikirkannya, semakin saya pikir masalah yang dimiliki kebanyakan orang adalah bahwa mereka merasa kita memutuskan hubungan antara .net dan asp.net.
Saat ini kami memiliki asp.net, asp.net core (.net), dan asp.net core (core). Jadi Anda dapat memilih apakah Anda ingin tidak, sedikit atau inti penuh.

Karena versi dikomunikasikan dengan buruk, orang merasa bahwa itu hanya bagian terakhir yang berinovasi dan terus maju, sementara asp.net dan asp.net core (.net) macet.
Karena kami tidak memiliki cara untuk memvalidasi apakah lib akan bekerja di netstandard2.0 tanpa mencoba, akan sangat berisiko untuk menggunakan inti penuh pada proyek baru. Jadi mereka berakhir dengan asp.net (lama) atau asp.net core (juga lama).
Dan karena keduanya sudah tua, masuk akal untuk menggunakan system.web dan asp.net lama. Karena mereka tahu itu dan karena asp.net core adalah EOL, mengapa repot-repot.

Jadi kami hanya memilih inti yang berani, dan sisanya menggunakan system.web lama tapi stabil. Dan kita akan selamanya terjebak dengan ekosistem yang bahkan lebih retak.

PS: Saya mengatakan ini seperti perasaan saat ini. Inti asp.net 1.x itu "tua dan ketinggalan zaman" vs 2.x. Bukannya itu fakta, tapi itulah yang dipikirkan orang.

@davidfowl

Jika setiap platform .NET bergerak dengan kecepatannya sendiri, maka menggunakan .NET Standard terbaru berarti kerangka kerja yang bergerak lebih lambat mendapatkan hal-hal yang lebih jarang.

Ini sudah terjadi, dan kami baik-baik saja dengan itu. Dokumen Versions biasanya diisi dengan _vNext_. Dan itu bagus. Daripada menunggu sampai semua platform berada pada keseimbangan sebelum menaikkan standar, saya lebih suka melihat standar yang ditetapkan beberapa versi ke depan dan melihat platform mengejar ketinggalan. Orang-orang bahkan dapat mengajukan untuk definisi dan implementasi. Dan jika ASP.NET Core menargetkan standar untuk rilisnya, saat platform dan arsitektur menerapkan standar baru itu, paket akan tersedia. Versi Standar baru dapat masuk melalui pembaruan atau paket VS.

Cara penyajiannya, meskipun .NET Standard tidak terdengar seperti upaya yang direncanakan komunitas. Ini lebih seperti snapshot dari kontrak yang diimplementasikan yang lulus tinjauan. Dan jika proyek besar tidak menargetkannya, tidak akan ada banyak perencanaan untuk rilisnya.

Kami melakukan hal yang sama

Oh bagus. Kesengsaraan bersama adalah kesengsaraan terbaik. File csproj dan sln dengan platform/config sangat mengganggu, btw, karena kombinasi build tidak selalu dideklarasikan - mereka disimpulkan. Jadi VS mungkin berpikir saya memiliki lebih banyak kombinasi build daripada yang sebenarnya ada karena menganggap bahwa setiap kemungkinan kombinasi itu penting. Dan saya harus memiliki bagian tambahan dalam file yang tidak diperlukan jika saya bisa mendeklarasikan kombinasi platform/config. Seperti bagaimana Anda dapat menggunakan fungsi seperti Substring di elemen csproj PropertyGroup untuk menyederhanakan properti kustom, tetapi kondisi tersebut digunakan dalam menentukan konfigurasi build, jadi Anda harus memiliki nilai string lengkap di sana. Hal-hal semacam ini seharusnya tidak terlalu merepotkan.

Pertanyaan jujur ​​(ini yang saya tanyakan bukan Microsoft), apakah Anda lebih menyukai kompatibilitas daripada fitur baru? Jika ya, mengapa memilih ASP.NET Core?

Secara pribadi, tidak. Selama ada cara untuk melakukan apa yang perlu saya lakukan, saya tidak keberatan menulis ulang kode selama itu bukan upaya besar dengan sedikit manfaat atau PITA untuk diuji. Jadi saya akan memilih apa pun yang memiliki momentum dan potensi paling besar. Tetapi saya harus bekerja dengan proyek di berbagai teknologi - Win32, COM, CORBA, ADO.NET, beberapa mesin pelaporan, berbagai API web, browser yang disematkan seperti CEF/Firefox/IE (tentu saja tanpa tepi, karena tidak didukung) dan beberapa hal khusus vendor saya akan menghindari mempermalukan. Saya menerapkan apa yang saya bisa sebagai plugin, tetapi saya menikah dengan denominator paling tidak umum pada host yang dapat dieksekusi, untuk sebagian besar. Berurusan dengan banyak teknologi itu menjengkelkan, tetapi itu statis. Begitulah banyak hal desktop/server. Selama saya diberi alat untuk interop, saya bisa melakukannya. Tetapi semakin sedikit kerangka kerja yang saya ingat, semakin baik.

ASP.NET, bagaimanapun, adalah bagian dari web stack, dan web stack adalah sesuatu yang saya rasa perlu untuk tetap up to date. Ini memiliki kasus penggunaan yang berbeda, dan ada harapan yang tidak menguntungkan untuk menggunakan platform yang lebih baru untuk pekerjaan web kecuali ada alasan bagus untuk tidak melakukannya, atau basis kode yang tidak kompatibel secara signifikan. Saya mencoba untuk terus memperbaruinya karena standar web berubah dengan cepat dan signifikan. Sebagian besar orang yang mengikuti perkembangan web tetap berpegang pada teknologi yang lebih baru, dan menerapkan hal-hal baru pada tumpukan yang lebih lama bisa jadi agak menyakitkan. Terutama dalam situasi di mana ASP.NET bersaing dengan PHP dan Node, saya harus menyimpan tumpukan yang lebih modern untuk menarik bakat dan minat. Saya ingin melakukan lebih sedikit pekerjaan web, tetapi sayangnya itu adalah harapan UI baru. Saya berharap berpegang pada standar akan membuat saya mendapatkan yang terbaik dari kedua dunia, tetapi itu sepertinya tawaran waktu yang terbatas.

jadi jika dipahami dengan benar, kita akhirnya akan memiliki netstandard menggantikan net framework.

Bukan itu tidak benar. Saya tidak yakin bagaimana Anda menarik kesimpulan itu. .NET Standard akan selalu menjadi subset dari setiap runtime yang mendukungnya.

Saya ingin membuang beberapa hal gila di sini karena telah disebutkan beberapa kali. Apa yang akan saya katakan tidak ada hubungannya dengan apa yang akan terjadi, itu semua spekulasi pada saat ini. Beberapa orang bertanya mengapa kami ingin menargetkan .NET Core daripada .NET Standard.

• Kami telah mengidentifikasi string sebagai salah satu hal utama yang ingin kami coba tangani di .NET Core, ada banyak ide tetapi salah satunya adalah membuat string menjadi utf8 secara default (banyak masalah kompatibilitas tetapi ikuti saya di sini).
• Hal lain yang ingin kami perbaiki adalah kemampuan untuk mengambil potongan array/string yang murah, setiap bagian dari memori yang berdekatan. Kami telah menambahkan Span<T> dan melihat Buffer<T> untuk mewakili ini. Ini mungkin berarti bahwa String dan Array mengimplementasikan antarmuka baru yang memungkinkan untuk mengambil sebuah irisan yang membutuhkan alokasi 0.
• Ini mengarah ke metode baru pada String yang memungkinkan pemisahan yang tidak mengalokasikan array setiap saat.
• Ini menyebabkan kelebihan beban ke Int, UInt dll (TryParse) yang membutuhkan Span<char> dan Span<byte> .
• Ini mengarah ke rutinitas penyandian baru yang membutuhkan Span<byte> .
• Buffer<T> dan Span<T> memungkinkan Anda merepresentasikan memori dengan cara yang seragam dan kami ingin memutakhirkan tumpukan jaringan untuk memungkinkan melewati buffer yang telah disematkan sebelumnya yang mengambil Span<T> atau Buffer<T> .
• Kestrel akan mengimplementasikan HTTP2 dalam jangka waktu 2.x (saat ini ditujukan pada 2.1) dan itu membutuhkan API baru pada aliran SSL untuk melakukan ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
• Http Client pada .NET Core mendukung streaming dupleks, ini akan memungkinkan untuk menerapkan titik akhir streaming melalui http di signalr melalui satu permintaan http non websocket.
• Kami memotong implementasi parser header dari HttpClient dan System.Net.Http dan menamainya (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers) sehingga kami dapat meningkatkannya dan minta mereka mendukung .NET Framework dan .NET Core. .NET Core memiliki salinan perbaikan ini yang belum kembali karena tidak perlu meningkatkannya (kami tidak dapat menggunakannya).
• Ada banyak threading primitif baru yang memerlukan API baru yang akan menyalakan skenario baru jika kita dapat menggunakannya (https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+ author%3Adavidfowl+label%3Aarea-System.Threading), itu hanya beberapa hal yang saya ajukan secara pribadi.

Tanpa kemampuan untuk menghidupkan kembali inti primitif, kami didorong untuk memotongnya dan membuat hal-hal yang terlihat seperti mereka tetapi sebenarnya bukan. Itulah alasan kami memiliki BCL kecil kami sendiri di dalam ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

Itu hanya dump acak dari hal-hal yang saya dapat melihat kita lakukan dalam waktu dekat yang mempengaruhi bagian yang sangat mendasar dari .NET.

@FransBouma

.NET full untuk bergerak maju lebih cepat, karena tidak menempatkan sumber daya yang cukup di .NET full untuk mengikuti .NET core. Lihat jumlah API yang ditambahkan ke .NET penuh dalam 2 tahun terakhir. Apakah itu memberi tahu Anda bahwa tim besar sedang mengerjakannya?

Itu tidak benar. Hal-hal terus-menerus di-porting ke .NET Framework tetapi seperti yang kita semua tahu risikonya jauh lebih tinggi daripada membuat perubahan yang sama di .NET Core. Tidakkah Anda semua membencinya ketika pembaruan ke .NET Framework merusak aplikasi Anda? Kami melakukannya juga sehingga kami menemukan semua jenis proses untuk menguranginya, Anda tidak akan percaya cengkeraman yang diberikannya pada rekayasa untuk mempertahankannya. Kami masih berhasil melakukan fitur terlepas dari semua itu. Yang mengatakan, itu tidak akan pernah bergerak secepat .NET Core, itu adalah komponen windows yang dikirimkan pada jadwal windows.

Saya mengerti tetapi saya tidak berpikir itu akan membuat perbedaan dalam kemampuan Anda untuk mem-porting apa pun. Kebijakan EOL yang sama masih ada.

@davidfowl Benar. Tapi bagaimana Anda membingkai itu berarti sesuatu. Belum lagi saat dikomunikasikan , jika pernah. Ini tidak selalu memberi orang lebih banyak waktu untuk melakukan pekerjaan yang sebenarnya, tetapi itu akan memberi mereka lebih banyak waktu untuk berpikir dan membuat keputusan yang benar (untuk mereka).

Saat ini, jika Anda telah mulai melakukan porting ke/menggunakan ASP.NET Core di .NET Framework, tampaknya Anda memiliki tiga pilihan:

1. Port semua kode dan dependensi Anda ke .NET Core dan pindah ke ASP.NET Core 2.x.
   
   
   
   • Ini akan menjadi solusi optimal, tetapi bisa membutuhkan banyak pekerjaan, dan untuk beberapa, itu bahkan mungkin di luar kendali mereka karena lib pihak ke-3.
   
   
2. Tetap menggunakan ASP.NET Core 1.x dan .NET Framework dan berharap Anda dapat melakukan 1. sebelum tidak didukung.
   
   
   
   • Ini cukup berisiko. Dalam satu tahun (atau dua, atau tiga? siapa tahu?), Anda dapat mengambil risiko menjalankan platform yang tidak didukung.
   
   
3. Kembali ke ASP.NET 4.x
   
   
   
   • Meskipun alternatif ini membuat Anda didukung, Anda akan "kembali" dan membatalkan pekerjaan yang sudah Anda mulai. Dan juga, mari kita hadapi itu; platform ini tidak akan mendapatkan banyak cinta ke depan.
   
   

Jika Anda sudah tahu sebelumnya dan dapat merencanakannya, saya pikir 1. dan 2. adalah alternatif yang layak. Masalahnya adalah bahwa kedua alternatif memiliki beberapa yang tidak diketahui. Bagaimana dengan perpustakaan A? Bagaimana dengan perpustakaan B? Apakah perpustakaan A akan pernah di-porting?

Saat ini, saya pikir banyak orang merasa mereka dipaksa untuk membuat pilihan, tanpa gambaran yang jelas tentang apa sebenarnya pilihan itu.

@khellang (dalam solusi hipotetis Anda)

1. Pindah ke ASP.NET Core 2.0 di .NET Framework
   
   
   
   • Ini cukup berisiko. Dalam setahun, Anda dapat mengambil risiko menjalankan platform yang tidak didukung.
   
   

@davidfowl

Pertanyaan jujur ​​(ini yang saya tanyakan bukan Microsoft), apakah Anda lebih menyukai stabilitas dan kompatibilitas daripada fitur baru? Jika ya, mengapa memilih ASP.NET Core?

Jawaban jujur:
Mendukung: Stabilitas dan kompatibilitas adalah yang terpenting. Fitur-fitur baru memang bagus, tetapi ketika mereka mendarat, mereka tidak boleh merusak ekosistem yang ada.
Mengapa ASP.NET Core: Hanya karena berjalan di OS X dan Linux.

Ekosistem seperti .NET (lama dan/atau inti) atau juga Java dipilih oleh bisnis. Dan ketika mereka membuat keputusan, mereka berusaha keras dalam mengembangkan kode untuk platform/ekosistem tersebut.

Sekarang, salah satu pelanggan kami, misalnya, sudah banyak berinvestasi di ASP.NET Core. Berdasarkan pengumuman sebelumnya dan ide penjualan .NET Core, kode telah ditulis. Kode (ASP.)NET Core baru ini kami (dengan susah payah) menulis dengan tim selama pengembangan awal (ASP).NET Core, dimulai dengan awal, adalah satu set server dan perpustakaan klien, dengan cukup banyak dari logika bisnis.
Dan kode ini, selain berjalan di server Linux, menyediakan layanan, saat ini juga digunakan dalam serangkaian aplikasi yang sangat lama yang berbicara dengan layanan ini, dan ini adalah campuran yang luar biasa dari WPF / Windows Forms / C++/CLI dan normal C++ (termasuk hal-hal DirectX).

Dan sekarang Anda hanya memotong investasi klien kami dalam beberapa tahun upaya ke dalam kode .NET Core untuk aplikasi yang ada, karena tidak mungkin untuk menggunakan kembali kode .NET Core baru dalam aplikasi yang sebenarnya (server baru dan perpustakaan logika bisnis dibangun untuk).

Kembali ke pertanyaan: Sebuah bisnis akan memilih .NET Core sebagai ".NET, sekarang juga untuk XPlat", sambil mengharapkan kompatibilitas dan stabilitas yang sama seperti yang diberikan .NET kepada kami dalam 17 tahun terakhir. Dan, sejujurnya, ini adalah satu-satunya alasan untuk .NET Core. Jika Anda tidak menginginkannya, Anda akan menggunakan Node.js atau bahkan Java. Keduanya jauh lebih matang dan XPlat daripada .NET Core sekarang.

Dan, hanya untuk menguraikan sedikit lebih banyak: .NET Core keren dan serba cepat pada tahap awal dengan project.json dan semuanya. Dan kemudian, karena alasan "kompatibilitas dengan .NET" project.json diambil dari kami demi Msbuild dan .csproj lagi. Dan sekarang manfaat dari "kompatibilitas dengan .NET" ini juga diambil, demi .. apa sebenarnya?

@jahe

Pertama-tama, balasan yang bagus!

Mengapa ASP.NET Core: Hanya karena berjalan di OS X dan Linux.

Berdasarkan itu, sepertinya MVC 5 on mono adalah yang Anda inginkan bukan?

Kembali ke pertanyaan: Sebuah bisnis akan memilih .NET Core sebagai ".NET, sekarang juga untuk XPlat", sambil mengharapkan kompatibilitas dan stabilitas yang sama seperti yang diberikan .NET kepada kami dalam 17 tahun terakhir. Dan, sejujurnya, ini adalah satu-satunya alasan untuk .NET Core. Jika Anda tidak menginginkannya, Anda akan menggunakan Node.js atau bahkan Java. Keduanya jauh lebih matang dan XPlat daripada .NET Core sekarang.

Dan, hanya untuk menguraikan sedikit lebih banyak: .NET Core keren dan serba cepat pada tahap awal dengan project.json dan semuanya. Dan kemudian, karena alasan "kompatibilitas dengan .NET" project.json diambil dari kami demi Msbuild dan .csproj lagi. Dan sekarang manfaat dari "kompatibilitas dengan .NET" ini juga diambil, demi .. apa sebenarnya?

Ini pada dasarnya adalah inti dari masalah ini. Berdasarkan penilaian Anda:

Kode (ASP.)NET Core baru ini kami (dengan susah payah) menulis dengan tim selama pengembangan awal (ASP).NET Core.

Anda benar-benar hanya menginginkan .NET Framework yang ada di linux dengan kompatibilitas ASP.NET 4.x lama yang bagus. Apakah itu ringkasan yang adil?

Mendukung: Stabilitas dan kompatibilitas adalah yang terpenting. Fitur-fitur baru memang bagus, tetapi ketika mereka mendarat, mereka tidak boleh merusak ekosistem yang ada.

.NET Core sebenarnya adalah platform yang lebih stabil daripada Desktop karena memungkinkan eksekusi berdampingan di mana Desktop tidak.

Jika Anda ingin menggunakan fitur yang lebih baru di versi Desktop berikutnya, Anda perlu memutakhirkan seluruh mesin ke versi baru itu dan itu memengaruhi semua yang ada di mesin itu, bukan hanya aplikasi yang ingin menggunakan fitur yang lebih baru. Yang baik-baik saja jika Anda memiliki server khusus untuk satu tujuan; tetapi tidak jika Anda memiliki banyak aplikasi yang berjalan di server yang sama yang meningkatkan pada tingkat yang berbeda (atau tidak pernah memutakhirkan sama sekali!)

@davidfowl menulis:

Terserah kerangka kerja untuk memutuskan apakah mereka ingin berjalan di .NET Framework, UWP, .NET Core, mono dll. Itu pilihan. Orleans tidak dikirimkan dengan .NET Core. ASP.NET Core tidak. Produk-produk itu adalah satu dan sama.

Dalam kasus Orleans, kami mendukung .NET Standard 1.5 dalam build "2.0 Technical Preview" kami, tetapi telah menunggu .NET Standard 2.0 sehingga kami dapat membuat rilis yang stabil. Saat ini saya tidak melihat pemblokir apa pun untuk kami - kekhawatiran saya hanya tentang perbedaan di masa depan. Perbedaan itu harus terjadi di beberapa titik.

👍 Terima kasih banyak telah bertahan untuk menjawab pertanyaan semua orang, @davidfowl & co!

.NET full untuk bergerak maju lebih cepat, karena tidak menempatkan sumber daya yang cukup di .NET full untuk mengikuti .NET core. Lihat jumlah API yang ditambahkan ke .NET penuh dalam 2 tahun terakhir. Apakah itu memberi tahu Anda bahwa tim besar sedang mengerjakannya?

Itu tidak benar. Hal-hal terus-menerus di-porting ke .NET Framework tetapi seperti yang kita semua tahu risikonya jauh lebih tinggi daripada membuat perubahan yang sama di .NET Core. Tidakkah Anda semua membencinya ketika pembaruan ke .NET Framework merusak aplikasi Anda? Kami melakukannya juga sehingga kami menemukan semua jenis proses untuk menguranginya, Anda tidak akan percaya cengkeraman yang diberikannya pada rekayasa untuk mempertahankannya. Kami masih berhasil melakukan fitur terlepas dari semua itu. Yang mengatakan, itu tidak akan pernah bergerak secepat .NET Core, itu adalah komponen windows yang dikirimkan pada jadwal windows.

yang mengabaikan fakta bahwa Anda dapat melepaskan perpustakaan yang _Anda_ andalkan sebagai paket netstandard2.0 sehingga aspnet dapat berjalan di .net full juga. Selain itu, membuat perubahan ke .NET full bukannya tanpa risiko, tapi tolong jangan membuatnya terdengar seperti tumpukan kode yang sangat terorganisir di mana satu perubahan dapat membuat semuanya hancur.

Kami masih berhasil melakukan fitur terlepas dari semua itu.

Ya begitu juga setiap pengembang .NET lainnya ;) Setelah Anda merilis sesuatu, Anda terjebak dengan API itu, kita semua memilikinya. Namun Anda ingin mengambil jalan pintas (seperti yang telah dilakukan tim ASPNET berkali-kali sebelumnya!) dan bergerak tanpa beban itu. Tapi itu tidak akan terbang pada akhirnya.

Yang mengatakan, itu tidak akan pernah bergerak secepat .NET Core, itu adalah komponen windows yang dikirimkan pada jadwal windows.

Saya pikir di sini kita memiliki inti masalahnya, bukan? Tim inti .NET dapat melakukan apa yang mereka inginkan tanpa berkomunikasi dengan raksasa 'WinDiv'. Mengapa Microsoft tidak menyelesaikan omong kosong politik internal ini di rumah dan memastikan .NET full + .NET core berversi / bergerak dengan benar tanpa politik windows?

Btw, masih tertarik dengan bagaimana Anda akan menjual API enkripsi SQL Server Enterprise kepada pengguna .NET core 2.0.

Juga, saya harus menambahkan; Saya cukup terkesan berapa lama utas ini telah berjalan, dengan begitu banyak orang yang terlibat, sementara masih tetap sipil ❤️ Itu bukan sesuatu yang Anda lihat setiap hari di internetz Mungkin ekosistem .NET OSS tumbuh? 😉.

yang mengabaikan fakta bahwa Anda dapat merilis pustaka yang Anda andalkan sebagai paket netstandard2.0 sehingga aspnet dapat berjalan di .net full juga.

Selain itu, membuat perubahan ke .NET full bukannya tanpa risiko, tapi tolong jangan membuatnya terdengar seperti tumpukan kode yang sangat terorganisir di mana satu perubahan dapat membuat semuanya hancur.

Besar dan sudah ada sejak lama. Seperti sistem warisan lainnya, beberapa bagian lebih baik daripada yang lain. Itu tidak membuat kodenya kurang dapat diandalkan tetapi itu membuat beberapa bagian praktis tidak mungkin diubah. Ada begitu banyak cerita menyenangkan yang dapat diceritakan oleh para veteran tentang bagaimana perbaikan bug di satu area memecahkan skenario yang tidak jelas dalam aplikasi di bagian lain. Ini kusut, itulah yang terjadi ketika batas ketergantungan tidak didefinisikan dengan baik. Anda bahkan tidak perlu percaya saya hanya pergi dan menelusuri referencesource.microsoft.com. Di tempat pembaruan adalah alasan kami perlu menambahkan sakelar konfigurasi untuk setiap perubahan yang berpotensi merusak ke .NET Framework. Ini fisika, tidak bisa bergerak secepat itu.

Ya begitu juga setiap pengembang .NET lainnya ;) Setelah Anda merilis sesuatu, Anda terjebak dengan API itu, kita semua memilikinya. Namun Anda ingin mengambil jalan pintas (seperti yang telah dilakukan tim ASPNET berkali-kali sebelumnya!) dan bergerak tanpa beban itu. Tapi itu tidak akan terbang pada akhirnya.

Kami menyukai jalan pintas! Pengembang malas . Kami juga ingin benar-benar meningkatkan .NET Core kami tanpa mengganggu apa yang diwakili oleh .NET Framework. Mungkin kita harus mengganti namanya menjadi sesuatu yang lain, seperti Sparkle .

Saya pikir di sini kita memiliki inti masalahnya, bukan? Tim inti .NET dapat melakukan apa yang mereka inginkan tanpa berkomunikasi dengan raksasa 'WinDiv'. Mengapa Microsoft tidak menyelesaikan omong kosong politik internal ini di rumah dan memastikan .NET full + .NET core berversi / bergerak dengan benar tanpa politik windows?

Baca jawaban saya yang lain tentang fisika.

Btw, masih tertarik dengan bagaimana Anda akan menjual API enkripsi SQL Server Enterprise kepada pengguna .NET core 2.0.

Itu bukan bidang keahlian saya, saya akan membiarkan orang lain menjawabnya.

@khellang lol itu karena masalah GitHub belum menarik MS yang membenci troll. Saat ini Twitter adalah media mereka untuk itu di mana belum ada downvote :)

@davidfowl

Anda benar-benar hanya menginginkan .NET Framework yang ada di linux dengan kompatibilitas ASP.NET 4.x lama yang bagus. Apakah itu ringkasan yang adil?

Tidak terlalu. Klien kami membutuhkan layanan lengkap baru/mengkilap (mikro), untuk melengkapi aplikasi desktop Windows .NET 4.x mereka yang sudah ada (mereka adalah 3,5 saat kami memulai).

Kami ketika Anda pergi beta dengan semua hal-hal Core mengkilap, kami mulai menulis kode server baru untuk MVC semua-baru di atas ASP.NET Core bersama dengan DTO yang menyertainya, logika bisnis dan perpustakaan klien, yang juga sedang digunakan secara paralel dalam aplikasi desktop 4.6 yang ada untuk berbicara dengan server yang semuanya baru.

Juga, beberapa server ASP.NET Core yang semuanya baru tidak hanya berjalan di Linux, tetapi juga sebagai layanan windows dengan Topshelf (di atas kerangka kerja 4.6 penuh).

Jadi masalahnya, banyak investasi telah dilakukan, dan sekarang kami tampaknya terjebak dengan .NET Core 1, karena pindah ke 2 (dan kehilangan standar bersih) juga berarti, kami tidak dapat menggunakan kembali rakitan di aplikasi Desktop yang ada (layanan dan lib yang menyertainya dibuat untuk) lagi.

Jadi, hal terpenting bagi kami adalah tetap dapat menggunakan (ASP). Pustaka NET Core baru yang kami tulis di aplikasi desktop .NET 4.6 (karena untuk itulah mereka dibuat), sambil tetap dapat menggunakan dukungan Versi .NET Core selama versi desktop .NET didukung, tempat kode dapat dijalankan.

Jadi, selama .NET Core 1. didukung seperti .NET 4.6, dan ada jalur peningkatan linier ke .NET Core x ketika .NET 5 keluar, dan kode .NET Core x mampu berjalan pada .NET Core x. NET 5, maka kami baik-baik saja.

@gingters Apakah Anda menggunakan fitur .net bukan di netstandard2.0 pada layanan asp.net?

Jika tidak maka lib seharusnya berfungsi. Tapi saya kira Anda sedang membicarakan hal-hal yang tidak ada di netstandard2.0.

@davidfowl Akankah c++/cli dll bekerja di netcoreapp 2.0? Kami memiliki rakitan C++/CLI pihak ke-3 lama yang tidak akan diganti dalam waktu dekat.

@davidfowl menulis:

ASP.NET Core 2.0 sejujurnya tidak memiliki banyak fitur baru

Dalam hal ini, mengapa perubahan yang sangat mengganggu ini sekarang?

@qrli C++/CLI tidak bekerja pada CoreCLR. Berikut beberapa latar belakang mengapa itu tidak didukung: https://github.com/dotnet/coreclr/issues/659#issuecomment -91341753

Berikan dukungan 4 tahun untuk 1x (porting sebanyak mungkin dari 2x) dan lanjutkan dan cepat dengan 2x. Mobil kota untuk lalu lintas kota yang lambat dan Ferrari untuk jalan raya. Kami memiliki banyak kompetisi di luar dunia .net.
Jika ASP.Net Core berhasil, saya yakin MS akan memberikan sumber daya untuk mendukung 1x selama 4 tahun. Sebagian besar budaya akan berubah.

@ idg10 Sebenarnya tidak. 2.x cukup banyak 1.x dengan hal-hal kinerja yang hanya tersedia di inti. Saya pikir hanya fitur utama adalah Razor Pages.

Jadi berada di versi 1.x tidak berarti Anda berada di versi yang sudah ketinggalan zaman. Tapi ini belum dikomunikasikan dengan baik.

Dalam hal ini, mengapa perubahan yang sangat mengganggu ini sekarang?

kira ini cukup merangkumnya https://github.com/aspnet/Home/issues/2022#issuecomment -300141134

@hallatore
Saya tahu ini berhasil, seperti halnya _now_. Kita bisa tetap di 1 untuk saat ini. Masalahnya berjalan ke depan. Ketika kami ingin (atau lebih buruk: perlu) untuk meningkatkan ke (ASP). NET Core 2 perpustakaan (yaitu ketika 1 keluar dari layanan, dan ada lubang keamanan kritis diperbaiki) kami menghadapi masalah yang kami tidak dapat memutakhirkan, karena ini akan membuat tidak mungkin untuk menggunakan lib kami yang memerlukan paket yang ditingkatkan di aplikasi desktop .NET.

Sunting / tambahkan: Kecuali akan ada kerangka kerja .NET lengkap baru yang mampu menjalankan lib .NET Core baru yang diperbaiki yang berada di jalur peningkatan linier untuk aplikasi desktop lama yang ada.

@gingters Tidak yakin saya mengerti.

Jika lib desktop Anda bekerja dengan netstandard2.0 mereka juga harus berjalan pada inti. (jika mereka memanggil barang-barang wpf dll, tentu saja mereka tidak akan melakukannya)
Jika hal ini terjadi maka Anda harus dapat menggunakan asp.net core 2.0.

Jika lib desktop Anda mogok pada inti karena mereka menggunakan hal-hal yang tidak ada di netstandard2.0. Lalu saya mengerti mengapa Anda harus tetap menggunakan 1.x. Dan saya mengerti mengapa EOL pendek menjadi masalah.

Akankah 1.x menjadi pilihan yang lebih mudah/lebih baik jika Anda tahu 2.x hanya berisi sebagian besar hal-hal kinerja inti (Artinya 1.x tidak ketinggalan zaman vs 2.x). Dan 1.x itu akan mendapatkan tambalan dan didukung selama * tahun?

@hallatore Ini sebaliknya. Aplikasi lama: Campuran Windows Forms, WPF, C++/CLI, C++ normal, DirectX, jutaan baris kode, dll. pp, berjalan pada 4.6 kerangka kerja penuh.

Pada .NET Core: Pustaka logika bisnis baru (menggunakan juga lib lain, yaitu versi .NET Core dari Serilog), lib abstraksi + layanan + pustaka klien untuk layanan ini. Layanan perlu berjalan di Linux dan sebagai layanan windows (saat ini Topshelf pada kerangka .NET 4.6 penuh, segera setelah dukungan layanan windows masuk ke Core yang dapat diubah, meskipun).

Sekarang logika bisnis baru dan abstraksi serta pustaka klien layanan juga digunakan dari aplikasi .NET 4.6. Ini berarti kami tidak dapat memutakhirkannya, karena mereka harus berjalan pada kerangka kerja .net lengkap selama aplikasi desktop melakukannya (yang dapat kami asumsikan akan cukup banyak selama desktop dapat hidup, kecuali kerangka kerja penuh hilang secara umum).

@gingters Anda masih dapat memiliki proyek perpustakaan bersama dalam solusi Anda yang menargetkan netstandard _min(dapat digunakan)_ dan menggunakan perpustakaan tersebut dari kode ASP.NET Core 2.0 Anda serta mengemasnya untuk digunakan dari WPF, Xamarin, UWP, apa pun.

sungguh menyedihkan bahwa kalian MS masih tidak mengerti maksudnya. Anda masih berpikir itu hanya masalah celah api. Anda masih berpikir orang hanya dapat memodifikasi kode mereka dan itu akan bekerja di netcoreapp... saya pikir Anda memahami perusahaan jauh lebih baik daripada google.

Berdasarkan itu, sepertinya MVC 5 on mono adalah yang Anda inginkan bukan?

@davidfowl Maksudku, ayolah. Itu jawaban yang meremehkan dan terus terang menghina. Adakah yang bisa mengkonfirmasi bahwa satu dev bahkan ditugaskan ke Framework ASP lagi? Saya tidak mencoba untuk menjadi brengsek di sini, tetapi sepertinya komunitas terkadang diremehkan.

Tidak ada alasan di bawah matahari bahwa saya harus mempertimbangkan .Net Core dan ASP.Net Core sebagai produk yang sama. Belum ada pesan untuk mendukungnya sama sekali. Terutama ketika Anda mempertimbangkan bahwa Mono berada di bawah sayap Microsoft _setelah_ pengumuman .Net Core. Itu selalu dikirim sebagai versi xplat yang lebih kecil, lebih gesit, dari .Net. Tidak hanya itu, tetapi kita semua ingat hari-hari ketika ASP.Net Core sebenarnya adalah ASP.Net 5 dan akan bekerja di mana-mana. Heck, perubahan itu hanya lebih dari satu setengah tahun yang lalu saja.

Apakah cerita HTTP yang dihosting sendiri di netstandard20 secara efektif "menggunakan Kestrel 1.x"? Saya tidak yakin orang-orang Nancy akan sangat peduli untuk itu, dan saya juga tidak. ASP.Net 2.x mungkin merupakan fitur tambahan, tetapi Kestrel 2 memiliki manfaat kinerja yang serius sehingga kami dapat menggunakannya secara serius pada hari itu keluar.

@davidfowl

Besar dan sudah ada sejak lama. Seperti sistem warisan lainnya, beberapa bagian lebih baik daripada yang lain. Itu tidak membuat kodenya kurang dapat diandalkan tetapi itu membuat beberapa bagian praktis tidak mungkin diubah. Ada begitu banyak cerita menyenangkan yang dapat diceritakan oleh para veteran tentang bagaimana perbaikan bug di satu area memecahkan skenario yang tidak jelas dalam aplikasi di bagian lain. Ini kusut, itulah yang terjadi ketika batas ketergantungan tidak didefinisikan dengan baik.

Saya pikir ini komentar yang menarik. Saya ingat menonton rekaman sesi konferensi NDC yang lebih lama dengan @davidfowl dan @DamianEdwards mengambil bagian dari cruft warisan di ASP.NET 4 yang benar-benar ingin Anda tinggalkan - sungguh menarik untuk mengintip ke dalam kotak hitam kode itu.

Tapi saya pikir komentar ini juga mencerminkan kekhawatiran banyak dari kita dengan basis kode kita sendiri. Kami memelihara sistem warisan yang besar, seringkali tidak dirancang dengan baik dengan batas ketergantungan yang buruk. Praktis tidak mungkin untuk menulis ulang beberapa sistem ini untuk .NET Core. Bisnis tidak akan membiarkan risiko perubahan sebanyak itu.

Saya tidak tahu apa jawaban yang benar. Tapi saya tahu bahwa untuk aplikasi kami sendiri, kami akan menggunakan kerangka kerja penuh dan ASP.NET4/MVC5 untuk masa mendatang (kami masih memiliki sepotong WebForms yang tidak akan ditulis ulang untuk beberapa waktu!). Saya berharap untuk melihat MVC5 mendapatkan cinta sekarang karena _akhirnya_ dipindahkan ke GitHub - Saya bahkan bersedia menyumbangkan waktu dan upaya saya sendiri untuk membuatnya lebih baik (misalnya dukungan async yang lebih baik, peningkatan kinerja, dll.).

@qrli Enterprises masih memiliki .NET 4.5 lengkap untuk dijalankan di Windows Server 2008 R2 IIS 7.5 Web Farms. Tidak ada yang mengambil itu dari mereka.

@mattnischan

Apakah cerita HTTP yang dihosting sendiri di netstandard20 secara efektif "menggunakan Kestrel 1.x"? Saya tidak yakin orang-orang Nancy akan sangat peduli akan hal itu, dan saya juga tidak.

HttpListener adalah bagian dari netstandard20 oleh karena itu juga netcore20 tidak ada yang diambil di depan itu dengan menggunakan netcore20.

HttpListener adalah bagian dari netstandard20 oleh karena itu juga netcore20.

Dan saya kira saya dapat mengharapkan permintaan yang sama per detik dari HttpListener ?

@markrendle Benar. Untuk sekarang.

Tapi apa yang akan Anda sarankan ketika satu perpustakaan lain yang digunakan oleh barang-barang kami bersama (yaitu serilog, newtonsoft, autofac dll.) menjatuhkan dukungan untuk netstandard_min(dapat digunakan), (mungkin hanya karena mereka merasa terlalu banyak upaya untuk mendukung kedua dunia) dan ada masalah keamanan kritis yang terdeteksi di versi terbaru yang masih mendukung kerangka kerja penuh?

@mattnischan

HttpListener adalah bagian dari netstandard20 oleh karena itu juga netcore20.

Dan saya kira saya dapat mengharapkan permintaan yang sama per detik dari HttpListener?

Oke kalau begitu, Nancy adalah .NETStandard 1.6 jadi Anda bisa menggunakannya di Core 2.0 dan menggunakan Kestrel 2.0. Lebih baik?

@gingters Saya sarankan menyeberangi jembatan itu ketika Anda datang ke sana.

Jangan biarkan masa depan mengganggu Anda. Anda akan menghadapinya, jika harus, dengan senjata akal yang sama yang hari ini mempersenjatai Anda melawan masa kini.
_~ Marcus Aurelius_

Itu bukanlah mantra yang berguna ketika memberikan perangkat lunak yang tidak memiliki anggaran pemeliharaan dan harus digunakan sebagian besar tidak berubah selama bertahun-tahun yang akan datang.

Jika sebagian besar harus tidak berubah selama bertahun-tahun yang akan datang lalu mengapa penting apa yang terjadi pada perpustakaan itu tergantung pada tahun-tahun yang akan datang?

@markrendle Sekarang anggap saja Anda diharuskan, oleh hukum (setidaknya di beberapa negara), untuk menyediakan protokol darurat untuk kasus-kasus ini, sebelum versi aplikasi dikirimkan, karena mungkin digunakan di lingkungan di mana nyawa orang mungkin dipertaruhkan .

Jadi Anda menginginkan server web yang secepat Kestrel, dan satu-satunya persyaratan khusus Anda adalah bukan Kestrel?

Oke kalau begitu, Nancy adalah .NETStandard 1.6 jadi Anda bisa menggunakannya di Core 2.0 dan menggunakan Kestrel 2.0. Lebih baik?

@markrendle @benaadams Tidak, saya pikir Anda salah paham, dan sekali lagi, tidak mencoba menjadi brengsek, hanya menunjukkan bahwa ada pelanggan lain dari ASP.Net Core yang tidak semuanya. Saya hanya ingin meng-host platform produksi kami di atas Kestrel 2.0 saat diluncurkan, dan platform produksi kami mungkin berada di Framework untuk sementara waktu. Saya tidak dapat menargetkan netcoreapp20.

Nancy mungkin netstandard16 tetapi tidak masalah karena saya tidak dapat menggunakan Kestrel 2.0 kecuali pada Core 2.0. Saya menyadari ini spesifik, dan mungkin jawabannya benar-benar "kemudian tulis server web Anda sendiri yang bekerja pada kerangka kerja secepat Kestrel 2. Kestrel hanya untuk ASP.Net." Tapi aku tidak suka itu menjadi pesannya.

@gingters @gulbanana Saya tidak mengerti bagaimana aplikasi yang dikirimkan dengan set dependensi tetap akan rusak karena proyek open source berhenti mendukung versi arbitrer dari kerangka kerja yang mendasarinya pada beberapa tanggal yang diduga di masa depan.

@mattnischan Ya, saya tahu apa yang Anda maksud dan menghapus komentar itu :)

@stefanolson

Karena saya perlu berbagi kode antara server dan aplikasi desktop saya, apakah itu berarti saya tidak akan pernah memiliki versi terbaru ASP.Net?

Jika Anda menargetkan .NET Standard dengan pustaka Anda, Anda dapat menggunakannya di Desktop dan Core. Untuk perpustakaan target .NET Standard, maka Anda memiliki dukungan platform universal: Desktop, Core, Mono, Unity, UWP, Tizen dll

Aplikasi ASP.NET dapat dieksekusi; titik akhir, itu bukan perpustakaan. Hasil akhir, aplikasi/executable ASP.NET perlu dijalankan pada platform. Akhirnya salah satu perpustakaan platformnya akan dikonsumsi oleh aplikasi ASP.NET sehingga tidak ada keuntungan bagi mereka untuk tidak menjadi target yang sama dengan platform.

.NET Core adalah platform yang bagus karena memiliki cakupan lintas platform yang luas; dapat diinstal berdampingan dengan Desktop dan dapat ditingkatkan secara mandiri aplikasi demi aplikasi; daripada seluruh mesin dan setiap aplikasi.

Beberapa item memang memiliki kegunaan di luar; jadi Wyam menggunakan Razor untuk pembuatan situs statis; Razor saat ini .NET Standard 1.3 jadi mengkonsumsinya di luar Core saat ini tidak menjadi masalah.

Ada beberapa kasus tepi yang disebutkan di atas:

Menggunakan perpustakaan yang tidak mendukung set fitur .NET Standard 2.0. Mudah-mudahan banyak celah yang bisa diisi - dan di awal edisi ini MS menanyakan apa celah itu sehingga mereka bisa memprioritaskannya.

Menjalankan WebApp yang disematkan di misalnya aplikasi UWP; namun jika Desktop masih didukung tetapi diubah ke versi 4.7.1 Anda masih berada dalam situasi yang sama karena UWP saat ini tidak mendukung 4.7.1 dan pada saat itu ASP.NET akan membutuhkan 4.7.2, lalu 4.7. 3 dll. Ini akan menjadi tugas Sisyphean karena platform lain tidak akan pernah menangkapnya; jadi itu hanya akan menjadi pekerjaan yang sibuk tanpa banyak gunanya?

Ya, saya tahu apa yang Anda maksud dan menghapus komentar itu :)

Jangan khawatir, tuan yang baik. 👍

@davidfowl

Bagaimana versi revving ASP.NET Core memengaruhi itu? Jika kami menjatuhkan dukungan .NET Framework di 3.0 (seperti yang tampaknya dihindari orang di utas ini), bukankah Anda akan berada di jalan buntu yang sama? Anda akan menjalankan aplikasi ASP.NET Core 2.0 pada kerangka kerja selama satu tahun dan ketika 3.0 keluar, Anda tidak akan dapat memutakhirkan. Anda tetap dapat melakukan ini dengan ASP.NET Core 1.1.x yang berjalan pada .NET Framework dan didukung bahkan ketika ASP.NET Core 2.0 keluar.

Hanya mengatakan (seperti yang saya mengerti) bahwa "kadang-kadang kita perlu istirahat dengan .net penuh mengapa tidak sekarang" kehilangan poin penting. Saya yakin banyak orang sedang menunggu rilis core 2.0. Karena secara publik menjanjikan banyak peningkatan dalam kompatibilitas dengan .net penuh. Begitu banyak penulis perpustakaan juga menunggu untuk memulai migrasi ke inti. Jadi saya kira setelah core 2.0 dirilis, kami akan lebih banyak memigrasikan lib di Core. Dan mengikat asp.net core ke core 3.0 akan jauh lebih membuat frustrasi ekosistem daripada sekarang. Karena pada saat 3.0 ini seharusnya lebih sedikit menghalangi hal-hal dari migrasi ke inti.
Saat ini adalah bencana.

Sebelumnya saya menilai awal migrasi kerangka kerja kami (cerita yang sangat mirip dengan apa yang dijelaskan @benaadams ) ke inti/asp.net inti dalam dua langkah: migrasi komponen web (yang ada di mvc/webapi sekarang) ke inti asp.net dan tetap penuh .net dan kemudian migrasikan semua hal lain pada inti ketika semua dependensi akan memiliki implementasi yang sesuai untuk inti. Saat ini yang menghalangi kami adalah penyedia Oracle ADO dan penyedia Postgres ADO (mungkin ada ketidakcocokan lain di corefx yang belum kami gali). Sekarang rencana ini sudah mati. Jadi kita harus duduk dan menunggu migrasi dependensi yang meninggalkan semua hal baru di dunia Inti. Dan semua ini hanya karena fakta bahwa seseorang di MS memutuskan bahwa kita membutuhkan platform "bergerak cepat".

@markrendle Aplikasi tidak akan rusak hanya karena itu. Masalahnya berbeda:
Karena .NET Core 2 menjatuhkan dukungan untuk kerangka kerja penuh (di mana ia berjalan dengan baik di versi 1, dan itu dari Microsoft di mana Anda tidak mengharapkan fitur dasar dan dasar seperti itu dijatuhkan saat memperbarui ke versi baru), juga Anda dependensi mungkin menjatuhkan dukungan untuk skenario ini lebih cepat daripada nanti.
Seseorang menemukan masalah keamanan kritis di salah satu perpustakaan yang digunakan, dan tidak ada pembaruan yang dikeluarkan untuk versi yang Anda gunakan, karena versi yang lebih baru tidak mendukung waktu proses Anda lagi. Sekarang, karena aplikasi Anda digunakan dalam lingkungan yang sangat teregulasi, Anda perlu menyediakan rencana darurat yang menjelaskan apa yang sebenarnya akan Anda lakukan ketika masalah keamanan kritis terdeteksi dan cara meluncurkan perbaikan itu untuk mencegah orang terluka atau lebih buruk. Sebuah "baik, kami tidak bisa melakukan apa-apa" akan mengakibatkan pencabutan tunjangan Anda untuk mengirimkan aplikasi itu.

@gingters Lihat, intinya adalah, Anda harus membuat pilihan teknologi berdasarkan informasi yang tersedia saat ini dan sifat pasar tempat perusahaan Anda beroperasi. Dengan kemauan terbaik di dunia, Anda tidak dapat menjelaskan semua kemungkinan, betapapun birokrat dan regulator dunia ingin berpura-pura bahwa Anda bisa. Bagaimana jika Microsoft diakuisisi dalam pengambilalihan yang tidak bersahabat oleh Apple dan .NET dihentikan sepenuhnya demi Swift? Bagaimana jika enkripsi kuat dibuat ilegal di salah satu negara tempat Anda menjual, dan semua tumpukan perangkat lunak yang menyertakan SHA256 dilarang? Bagaimana jika Nicolas atau James atau _insert-name-of-Autofac-maintainer-sini_ memutuskan untuk pindah ke Mars dan menjadi petani kelembapan? Bagaimana jika kutub magnet terbalik dan setiap bit data yang direkam secara digital dihapus?

Sebagai jawaban aktual atas pertanyaan tentang apa yang Anda, sebagai perusahaan, katakan akan Anda lakukan jika masalah keamanan kritis ditemukan di JSON.NET (misalnya), jika tidak ada pembaruan resmi yang tersedia, satu-satunya jawaban yang mungkin adalah "kami akan melakukan fork-and-patch JSON.NET", yang saya duga sudah merupakan jawaban atas pertanyaan tentang apa yang akan Anda lakukan jika James Newton-King menjadi tidak sehat karena alasan apa pun. Dalam pengalaman saya sebelumnya bekerja di pasar semacam itu, ada pengaturan escrow untuk kode sumber ke paket berpemilik untuk kemungkinan semacam itu; apa yang harus dilakukan tentang paket open source sepele dibandingkan dengan itu.

Dan semua ini hanya karena fakta bahwa seseorang di MS memutuskan bahwa kita membutuhkan platform "bergerak cepat".

"bergerak cepat" mungkin berlebihan; mengikuti jadwal rilis sebelumnya dari Full Framework mungkin lebih baik dinyatakan sebagai "tanpa menambahkan penundaan tambahan 1 - 2 tahun" ke dalam pengiriman. Itu jumlah waktu yang gila di dunia web.

Segalanya berubah dengan cepat dan platform harus tetap relevan.

@davidfowl dan @DamianEdwards Saya pikir seluruh kebingungan ini berasal dari fakta bahwa ASP.NET Core 1.x dapat berjalan di .NET Framework. Ini menciptakan asumsi bahwa ASP.NET Core adalah evolusi dari ASP.NET 4/MVC5; membuat orang bermigrasi ke sana berpikir bahwa mereka akan mendapatkan semua manfaat (kecepatan dan fitur baru) sambil menjaga kompatibilitas ke belakang.

Jadi mungkin jawaban jangka panjang/permanen untuk masalah ini adalah mempromosikan kembali ASP.NET 4/MVC5 sebagai jawaban untuk orang yang mencari kompatibilitas mundur dengan dukungan jangka panjang (dan mungkin menawarkan untuk melakukan perbaikan kecil juga).

Kemudian, ASP.NET Core dapat fokus menjadi platform baru yang melepaskan diri dari masa lalu untuk menawarkan manfaat besar, bagi mereka yang dapat melakukan lompatan.

Dalam hal itu, (ASP).NET (Framework) dan (ASP).NET Core akan menjadi dua jalan paralel dan sama-sama valid yang dapat dipilih pelanggan. Dan saya pikir ini adalah cara yang seharusnya sejak awal.

@markrendle Ya, ini hiptetis, tetapi sayangnya birokrasi adalah hal yang nyata. Dan ya, Anda tidak dapat (dan tidak perlu) memperhitungkan semua kemungkinan. Hanya untuk yang bisa Anda antisipasi.

Dan sekarang kita memiliki situasi bahwa a) menjatuhkan platform lengkap (.NET full framework), yang didukung di .NET Core 1 dengan baik, bukanlah sesuatu yang dapat Anda antisipasi. Namun, karena itu terjadi sekarang, Anda dapat b) mengantisipasi penurunan dukungan untuk v1 di dependensi Anda yang lain dengan cukup yakin "ya, saya benar-benar dapat melihat itu terjadi lebih cepat daripada nanti".

Dan ya, perbaikan forking dan backporting adalah salah satu solusi yang mungkin, namun ini adalah sesuatu yang ingin Anda hindari sebisa mungkin. Jika tim Inti .NET mengatakan sesuatu seperti "Hei. Dengar, kami tidak bermaksud untuk menjalankan kerangka kerja penuh, jangan mengandalkan itu", atau bahkan lebih baik tidak pernah memungkinkan itu sejak awal, seluruh diskusi ini tidak akan diperlukan karena pelanggan tidak akan memilih untuk berinvestasi dalam hal-hal baru di atas .NET Core di tempat pertama.

@gingters Saya pikir kami berada pada titik di mana Anda senang menjalankan bit web ASP.NET Core Anda di .NET Core 2.x atau yang lebih baru, dan menggunakan .NET Standard 2.x untuk berbagi perpustakaan antara Core dan Full/UWP/apa pun . Karena jika perpustakaan ini menghentikan dukungan untuk .NET Standard 2.x dan hanya mendukung .NET Core 2.x, maka mereka akan menjatuhkan dukungan untuk .NET penuh juga, dan Anda akan disemprot dengan cara apa pun.

@markrendle Sampai pada titik di mana kami memiliki masalah kritis di salah satu bit Inti ASP.NET yang perlu kami gunakan dalam hal-hal yang dibagikan setelah 1x tidak didukung lagi.

@gingters untungnya ini open source dan Anda dapat mendukung diri sendiri (atau membayar pihak ke-3) jika perlu!

@markrendle no. proyek warisan murni adalah yang mati. proyek perusahaan biasanya merupakan basis kode campuran besar yang berisi tanggal kode/lib dari beberapa dekade yang lalu hingga yang baru. menjadi netcoreapp hanya berarti Anda menghapus kemampuan untuk mencampur. jadi kami tidak bisa lagi pindah ke versi baru yang mewah tetapi terkunci ke versi lama. dan rekan kerja anti-ms akan dengan senang hati mengatakan kepada saya "sudah saya katakan..." dan kemudian mendorong kami untuk bermigrasi ke solusi google.

saya tidak berdebat untuk mendukung netfx selamanya. tetapi saya sangat merasa netfx harus didukung oleh asp.net core setidaknya selama 2 tahun dari sekarang. tidak hanya 1.x tetapi juga 2.x.

@qrli "Proyek perusahaan ... basis kode campuran besar yang berisi kode/lib tanggal dari beberapa dekade yang lalu hingga yang baru." adalah segala sesuatu yang salah dengan proyek perusahaan dan harus dihentikan. Mengeluh bahwa teknologi baru menghentikan Anda dari melemparkan lebih banyak bongkahan lumpur ke dalam bola besar keputusasaan yang disatukan dengan shim, kawat baling, dan penolakan adalah seperti mengeluh bahwa mesin pemotong laser industri baru dilengkapi dengan fitur keselamatan yang menghentikan Anda bersandar dan memotong bagian penting dari diri Anda.

@benaadams

"bergerak cepat" mungkin berlebihan; mengikuti jadwal rilis sebelumnya dari Full Framework mungkin lebih baik dinyatakan sebagai "tanpa menambahkan penundaan tambahan 1 - 2 tahun" ke dalam pengiriman. Itu jumlah waktu yang gila di dunia web.

Segalanya berubah dengan cepat dan platform harus tetap relevan.

Ini adalah batasan politik/organisasi, bukan batasan teknis. Lihat bagaimana JVM / Java bergerak. Jika mereka bergerak sama sekali. Masih relevan, lebih dari .NET saat ini. Jadi 'bergerak cepat' bukanlah alasan orang memilih Java/JVM. Di sisi lain. Mereka memilih Java/JVM karena tidak memiliki semua kelemahan yang terkait dengan 'bergerak cepat': ini adalah platform yang stabil dan dapat diandalkan, di mana investasi Anda tidak akan sia-sia dalam 1-2 tahun.

Saya tidak tahu, jika MS ingin memindahkan .net penuh dengan cepat, itu akan bergerak cepat. Mereka memilikinya, mereka dapat memutuskan apa yang harus dilakukan. Tetapi kekuatan yang ada tidak benar-benar memberi banyak tentang itu: .net full 'cukup baik' untuk tempatnya sekarang.

MS telah tidur di belakang kemudi selama bertahun-tahun dan sekarang tiba-tiba hal-hal seperti kinerja dan tekanan memori penting (mereka, tidak diragukan lagi), sementara di JVM investasi tanah dalam aspek-aspek tertentu dari runtime telah dilakukan selama banyak tahun dan itu terbayar.

Saya tidak tahu apa solusinya, jangka pendek, tetapi dalam jangka panjang, meninggalkan .NET terbagi menjadi dua departemen utama (.net penuh dengan windows, .net core dengan devdiv) tanpa kesamaan/tujuan selain yang sama majikan bukan pertanda baik bagi kita orang luar.

Meskipun ada banyak poin yang dibuat di sini, dan semua orang berusaha memastikan bahwa mereka memahami sudut pandang orang lain, solusi seperti "perusahaan besar tidak boleh seperti itu" tidak akan membantu. Bahkan jika Anda dapat meyakinkan mereka tentang hal itu, perlu 20 tahun bagi mereka untuk berhenti menjadi seperti itu, karena mereka adalah perusahaan besar .

@kolectiv Itu benar, tetapi menerima bahwa perusahaan tidak tiba-tiba berhenti menjadi perusahaan tidak berarti Anda harus secara aktif mendorong/mengaktifkan perilaku semacam itu.

Ini juga tidak berarti bahwa aplikasi _my_ harus berjalan lebih lambat dan lebih mahal untuk dihosting.

Menjalankan analisis portabilitas pada perpustakaan kami yang banyak digunakan yang masih menargetkan .NET 4.x pada ASP.NET Core 1.x (EF6, NHibernate, NServiceBus) dan kawan, lib ini bahkan tidak mendekati dapat menargetkan netstandard20 .

Lib | bagian
---------- | ---------
EF6 | 62.74
NHibernasi | 67.39
NServiceBus | 65.68

Dan masih ada celah besar dalam API yang hilang. EF Core masih memiliki gap yang besar dengan EF6, dan kami masih menggunakan NHibernate ketika ada fitur utama yang tidak ada di EF6. NServiceBus kami gunakan pada proyek apa pun yang melakukan pengiriman pesan.

Wah.

@markrendle

"Proyek perusahaan ... basis kode campuran besar yang berisi kode/lib berasal dari beberapa dekade yang lalu hingga yang baru." adalah segala sesuatu yang salah dengan proyek perusahaan dan harus dihentikan. Mengeluh bahwa teknologi baru menghentikan Anda dari melemparkan lebih banyak bongkahan lumpur ke dalam bola besar keputusasaan yang disatukan dengan shim, kawat baling, dan penolakan adalah seperti mengeluh bahwa mesin pemotong laser industri baru dilengkapi dengan fitur keselamatan yang menghentikan Anda bersandar dan memotong bagian penting dari diri Anda.

Ya, mari beri tahu Perusahaan dan organisasi besar yang menyebalkan itu untuk melakukan hal-hal yang berbeda, potong kabelnya! hentikan banjir lumpur! Itu akan membuat mereka bangun dan mendengarkan. Oh tunggu, itu tidak akan membantu, karena mereka sudah tahu itu tetapi harus bekerja dengan banyak hal yang tidak Anda pedulikan atau abaikan untuk argumen Anda sendiri.

Lihat, tidak ada yang mengatakan 'teknologi baru: buruk!'. Ini tentang mengejar teknologi baru tanpa menyadari konsekuensi yang menyertainya. Kita semua suka bekerja dengan potongan-potongan terbaru dan tidak perlu khawatir tentang kesalahan lama, siapa yang mau? Namun kenyataan menceritakan kisah yang berbeda. Jika Anda hanya harus bekerja dengan bit terbaru dan tidak perlu peduli dengan omong kosong lama, bagus untuk Anda! Sayangnya kami sedih bekerja drone di parit harus hidup dengan kenyataan yang berbeda. Ini akan cocok untuk Anda jika Anda setidaknya mengakui bahwa bagi BANYAK orang, kenyataan hanya itu, mereka tidak dapat mengubahnya, mereka tidak dapat membuat masa depan yang berbeda, itulah yang harus mereka kerjakan.

@markrendle Saya tidak yakin apa yang Anda sarankan? Meninggalkan 15 juta baris kode C# yang berfungsi dan menulis semuanya lagi? Kami sedang melihat transisi (perlahan) ke netstandard 2.0 dan mudah-mudahan mendapatkan akses ke hal-hal seperti Span dll ketika datang, tetapi masalah seperti ini membuat saya ragu itu bijaksana.

Kami ingin dukungan Linux tetapi ini terasa lebih seperti perbedaan. Saya berasumsi netstandard akan bergerak maju dengan implementasi paling canggih dan kemudian hal-hal seperti kerangka kerja akan menyusul, tetapi setidaknya kami tahu itu akan terjadi.

@FransBouma Jadi kita semua harus menderita karena Perusahaan ingin melakukan hal-hal bodoh? Saya seharusnya tidak mendapatkan barang-barang bagus karena proyek sektor publik bernilai jutaan dolar belum siap untuk itu? Bagaimana cara kerjanya?

@markrendle Apa yang bodoh tentang keinginan untuk tetap menggunakan kode?

Mereka memilih Java/JVM karena tidak memiliki semua kelemahan yang terkait dengan 'bergerak cepat': ini adalah platform yang stabil dan dapat diandalkan, di mana investasi Anda tidak akan sia-sia dalam 1-2 tahun.

Dan Anda dapat menggunakan System.Web pada dasarnya selamanya; yang dipanggang ke dalam Windows yang berarti kemungkinan tidak akan pernah hilang. Anda tidak menjadi lebih stabil dan dapat diandalkan dari itu.

ASP.NET Inti 1.x -> ASP.NET Inti 2.x; semua api hampir sama, perubahan utama adalah menjatuhkan dukungan untuk .NET Framework. Itu bahkan mengubah semver untuk istirahat

ASP.NET Core 1.x berjalan pada .NET Core 2.x dan .NET Framework, mendukung .NET Standard 2.x (via .NET Core 2.x); dan memiliki apis yang sama dengan ASP.NET Core 2.x, Jadi itulah batu loncatannya.

ASP.NET Core 2.x adalah rilis istirahat. Itu masih mendukung .NET Standard 2.x (melalui .NET Core 2.x) dan tidak banyak yang berubah antara ASP.NET Core 1.x dan ASP.NET Core 2.x; tetapi menjatuhkan .NET Framework.

Mungkinkah alternatifnya:

• ASP.NET Core lanjutkan dan kerjakan sesuatu seperti netstandard3.0 (bisa 2.x) dan hanya versi netstandard lebih cepat. Seperti seperempat sekali.
• Rilis NetFx berikutnya dapat melompat lagi untuk mendukung netstandard3.x kapan pun rilis berikutnya. Bahkan tidak harus menjadi standar terbaru.

Ini mungkin ide yang buruk karena semua yang digunakan mungkin tidak perlu menjadi bagian dari netstandard tetapi setidaknya ASP.NET Core 2.x akan menargetkan standar yang nantinya akan digunakan oleh kerangka kerja lain.

Hanya meludah. Saya yakin ini sudah diangkat.

@bencyoung Saya hanya menyarankan bahwa agak egois untuk bersikeras bahwa seluruh dunia harus berputar di sekitar 15 juta baris kode C# Anda yang berfungsi (yang tidak akan berhenti bekerja, btw). Jadi Anda tidak dapat menggunakan ASP.NET Core 2.0. Anda masih memiliki kerangka lengkap Windows-only ASP.NET yang memiliki dukungan warisan yang berjalan melaluinya seperti Brighton through rock. Jadi ada mainan baru yang tidak dapat Anda mainkan karena tidak ekonomis bagi Anda untuk mem-porting kode Anda dan memfaktorkan ulang/mendesain ulang aplikasi Anda. Itu menyebalkan, tapi begitu juga banyak hal. Tetapi jika Microsoft menghindari segala sesuatu yang tidak akan berfungsi untuk basis kode lama dua dekade yang sudah ada sebelumnya yang mungkin masih menyertakan komponen COM yang ditulis dalam VB 6.0, maka dalam 20 tahun lagi mereka akan menjadi Fokus Mikro.

@adamhathcock Itulah yang saya asumsikan untuk standar net - pendekatan penyatuan, daripada penyebut yang paling tidak umum. Itu dapat bergerak secepat yang diinginkan, tetapi mereka akan menjadi komitmen bahwa .NET framework pada akhirnya akan menyusul. Akhirnya akan ada standar bersih yang pada dasarnya adalah kerangka kerja .NET dikurangi hal-hal khusus platform dan kemudian akan disatukan

NetFx rilis berikutnya bisa melompat lagi untuk mendukung netstandard3.x kapan pun rilis berikutnya.

Pembaruan .NET Framework adalah pembaruan paksa untuk setiap mesin di planet ini yang menjalankan Windows (kebanyakan).

Pembaruan .NET Core adalah pembaruan yang Anda pilih untuk diambil oleh aplikasi individual .

Mereka adalah binatang yang sangat berbeda.

Nah, satu hal yang mudah dilakukan adalah berhenti menautkan ke halaman ini dari halaman pertama dokumen ASP.NET Core .

(Atau cukup tambahkan baris "Jangan pilih .NET Framework jika Anda ingin terus menggunakan ASP.NET Core!".)

mereka akan menjadi komitmen bahwa .NET framework pada akhirnya akan menyusul.

Ada https://github.com/aspnet/Home/issues/2022#issuecomment -299609207

janji kami umumnya adalah: jika jenisnya dibagi antara .NET Framework dan .NET Core, kami bermaksud untuk mem-port anggota yang baru ditambahkan ke .NET Framework. Dalam kasus yang sangat jarang ini mungkin tidak mungkin, tetapi taruhannya adalah bahwa mereka secara otomatis dipertimbangkan.

Tetapi pada saat itu menyusul, ASP.NET akan pindah ke versi .NET Standar berikutnya dan itu tidak akan pernah menjadi versi yang tepat dari .NET Framework untuk ASP.NET; itu akan selalu berada di belakang.

@markrendle tidak, mereka bukan bola lumpur besar. campuran besar tidak berarti mereka dirancang dengan buruk. mereka modular. itu adalah bahwa banyak modul adalah kode yang telah teruji pertempuran yang ditulis sejak lama oleh orang-orang yang benar-benar pintar atau dibeli dari pihak ke-3. beberapa dengan c, beberapa di fortran, beberapa di c++/cli, dll. untuk bermigrasi atau menulis ulang, kita perlu memahaminya, membaca makalah, mengumpulkan lebih banyak data pengujian nyata, menguji ulang versi baru. dibutuhkan usaha tetapi tugas-tugas seperti itu tidak pernah dianggarkan, tetapi terserah diri kita sendiri. pebisnis tidak peduli kita menggunakan .net core atau tidak, tetapi mereka ingin fiturnya selesai. dan untuk pihak ke-3, kita harus mendesak mereka atau mencari pengganti.
jadi, itu bisa memakan waktu beberapa tahun dalam praktiknya.

@benaadams

Dan Anda dapat menggunakan System.Web pada dasarnya selamanya; yang dipanggang ke dalam Windows yang berarti kemungkinan tidak akan pernah hilang. Anda tidak menjadi lebih stabil dan dapat diandalkan dari itu.

ASP.NET Inti 1.x -> ASP.NET Inti 2.x; semua api hampir sama, perubahan utama adalah menjatuhkan dukungan untuk .NET Framework. Itu bahkan mengubah semver untuk istirahat
ASP.NET Core 1.x berjalan pada .NET Core 2.x dan .NET Framework, mendukung .NET Standard 2.x (via .NET Core 2.x); dan memiliki apis yang sama dengan ASP.NET Core 2.x, Jadi itulah batu loncatannya.
ASP.NET Core 2.x adalah rilis istirahat. Itu masih mendukung .NET Standard 2.x (melalui .NET Core 2.x) dan tidak banyak yang berubah antara ASP.NET Core 1.x dan ASP.NET Core 2.x; tetapi menjatuhkan .NET Framework.

Ya, dan mari kita lihat apa opsinya sebenarnya :) ASPNET Core 1.x adalah jalan buntu: Anda dapat melakukan port ke sana tetapi kode Anda tidak dapat pindah ke .net core jika Anda bergantung pada lib yang .net penuh hari ini dan mungkin tidak di-porting ke .net core /standard saat dukungan berakhir. Memilih ASP.NET core 1.x sekarang hanya bijaksana jika ketergantungan Anda sudah pada netstandard2.0/.netcore, maka Anda dapat pindah ke asp.net core 2.x tanpa masalah, mengetahui bahwa Anda tidak menemui jalan buntu.

Saran Anda untuk memilih system.web sebagai alternatif untuk nginx dan tumpukan JVM jika Anda ingin memiliki stabilitas agak lemah, bukan begitu? :) Ini tentang opsi untuk organisasi besar apa yang harus dipilih sebagai platform. Kecuali jika mereka membuat aplikasi yang benar-benar baru dan tidak harus bekerja dengan dependensi luar (jarang), mereka kemungkinan akan mengambil taruhan yang aman, dan mengapa tidak? Jika kemudian turun ke system.web atau JVM/nginx pilihannya cukup sederhana.

Ini hal-hal kecil. Saya telah membahasnya sebelumnya: fitur enkripsi perusahaan server sql. Anda tidak akan menggunakan ini di .net core karena tidak ada di sana. Peramal? Tidak. Jadi jika Anda ingin menggunakan asp.net core dan fitur-fitur tersebut, Anda harus menggunakan .net full dan asp.net core 1.x. Tetapi apa yang terjadi jika fitur-fitur ini tidak di-porting/tersedia ketika dukungan untuk asp.net core 1.x berakhir? (dan siapa yang ingin mempertaruhkan pertanian pada platform yang sudah dalam 'mode QFE'?) Kembali ke system.web?

Tampaknya bagi saya bahwa bagian dari masalahnya adalah bahwa ASP.NET secara langsung mendorong evolusi .NET Core. Saya kira itu hal internal di Microsoft, tetapi sebenarnya platform dan perpustakaan tertentu tidak boleh digabungkan dengan erat.

Jika sesuatu yang baru perlu ditambahkan ke versi .NET maka itu harus tersedia untuk semua orang melalui benjolan standar bersih (dengan vNext) dan kemudian ASP.NET diperbarui untuk menggunakannya saat dirilis. Menurut saya, posisi istimewa ASP.NET yang menyebabkan masalah ini. Ini mungkin tidak dapat dihindari karena grup pengembang di dalam Microsoft sama...

Sebagai penulis perangkat lunak HPC yang banyak menggunakan .NET, kami juga telah menerapkan penguraian alokasi nol, dll., tanpa perubahan pada platform yang mendasarinya. Apakah kita mendapat manfaat dari Span dll? Sangat! Bisakah kita beralih ke .NET Core? Tidak untuk waktu yang lama. Apakah kita akan melihat Span dll ditambahkan ke .NET Framework? Tampaknya sulit untuk mengatakan sekarang tanpa itu menjadi komitmen standar bersih ...

@markrendle Tentu, tapi apa rencana transisi kita? Saya tidak dapat melihat yang tidak mencapai jalur yang tidak didukung. Jika perubahannya dalam standar net dan kemudian ASP.NET Core menggunakannya maka setidaknya kita akan tahu ada jalan melalui akhirnya....

@markrendle Saya tidak yakin siapa pengguna inti asp.net yang dituju. tetapi apa yang saya lihat sebagian besar pengguna .net yang memiliki investasi besar di .net dan basis kode warisan besar (tidak buruk). jika kita bukan pengguna yang dituju, saya tidak melihat node.js/python/go guys memberikan .net a sh*t, tidak peduli seberapa baik kita berpikir .net.
jika bukan untuk perusahaan tetapi untuk proyek saya sendiri, saya tidak akan menggunakan asp tetapi menggunakan nancy sebagai gantinya. perusahaan membutuhkan jaminan dan dukungan yang stabil. dan mereka/kami membayar banyak uang untuk itu.

Solusi mudah untuk masalah ini adalah, jika Microsoft akan membuat distribusi CoreCLR Windows saja yang mendukung berbagai pustaka .NET Framework.

Sisi pribadi saya keren bermain dengan .NET Core pada PI di ubuntu tetapi sisi bisnis bahkan tidak mempertimbangkan .NET Core karena .NET Framework melakukan semua yang kami butuhkan dan .NET Core hanya masalah dalam perbandingan. Sebagian besar masalah ini adalah seputar perkakas dan menyiapkan semua orang sehingga rasa sakit itu akhirnya hilang, tetapi masih kekurangan begitu banyak fitur... EF Core bahkan tidak mendekati cukup lembut untuk menggantikan EF6 atau NHibernate dan mereka menang tidak berjalan di .NET Core 2 juga. Kurangnya WCF (host) untuk SOAP Services cukup membebani, karena itulah yang kami lakukan sepanjang hari dalam komunikasi bisnis, tetapi mungkin dapat dikurangi melalui desain yang cerdas dan menggunakan .NET Core dan .NET Framework di banyak aplikasi. AppDomains juga tidak mudah diganti meskipun itu adalah masalah saya yang paling kecil. Lompatan dari ASP.NET MVC 5 ke MVC Core secara tak terduga mudah untuk menulis ulang tetapi menggunakan .NET Core membuat VS berhenti bekerja sama, menampilkan semua kesalahan.

Hal-hal menyenangkan seperti hosting ASP.NET Core di dalam WPF juga tidak mungkin.

Bahkan tidak masalah jika distribusi Windows CoreCLR akan menjadi sumber tertutup karena tidak jauh berbeda dengan .NET Framework saat ini.

Sekarang permisi sementara saya diam-diam menangis dan menghapus cabang eksperimental saya yang dimigrasikan ke ASP.NET Core.

Saran Anda untuk memilih system.web sebagai alternatif untuk nginx dan tumpukan JVM jika Anda ingin memiliki stabilitas agak lemah, bukan begitu?

Ini akhir yang ekstrim ;)

Jika kemudian turun ke system.web atau JVM/nginx pilihannya cukup sederhana.

Ya, jika Anda dapat menggunakan JVM, Anda menggunakan ASP.NET Core 2 karena Anda tidak memiliki pemblokir dan memiliki interop dan p/invoking yang bagus :)

jika apinya "hampir sama", mengapa Anda tidak menyimpan satu versi penomoran 2x untuk semua, tetapi memiliki opsi untuk memilih "netstandard" atau "netcore"?

Karena internalnya yang berubah; dan memanfaatkan perubahan pada runtime, jit, dan pustaka standar. Bagi pengguna, tampilannya sebagian besar sama seperti di situlah kompatibilitas antara ASP.NET 1.x dan 2.x; pada permukaan api yang terbuka, bukan bagian dalam "begini caranya".

Tampaknya bagi saya bahwa bagian dari masalahnya adalah bahwa ASP.NET secara langsung mendorong evolusi .NET Core.

Seperti orang lain. Anda dapat membuat permintaan api di dotnet/corefx seperti yang saya lakukan misalnya untuk ValueTask ; yang kemudian berkembang menjadi seperti Tugas dan sekarang menjadi bagian dari C#7.

Segera setelah api Anda disertakan dalam .NET Core, Anda dapat mulai menggunakannya (jika Anda menggunakan nightlies dan ingin memastikan apinya benar); atau pada rilis coreclr/corefx berikutnya jika Anda ingin bertahan selama 6 bulan.

dan kemudian ASP.NET diperbarui untuk menggunakannya saat dirilis.

Sekarang harus nunggu 2 tahun. Itu tidak terlalu praktis; karena apis akan membutuhkan penyempurnaan melalui penggunaan; dan melalui penggunaan lebih banyak penemuan akan terjadi. Itu seperti menambahkan langkah kompilasi 2 tahun ke siklus pengembangan Anda.

Sebagai penulis perangkat lunak HPC yang banyak menggunakan .NET, kami juga telah menerapkan penguraian alokasi nol, dll., tanpa perubahan pada platform yang mendasarinya. Apakah kita mendapat manfaat dari Span dll? Sangat! Bisakah kita beralih ke .NET Core? Tidak untuk waktu yang lama.

Apakah perangkat lunak HPC Anda langsung menghentikan permintaan web? Kira-kira itu mungkin memiliki antrian yang didorong oleh permintaan web, tetapi itu berjalan dalam proses yang terpisah sehingga haruskah tidak terpengaruh oleh perubahan ini?

Apakah kita akan melihat Span dll ditambahkan ke .NET Framework?

Ya

@benaadams

Tetapi pada saat itu menyusul, ASP.NET akan pindah ke versi .NET Standar berikutnya dan itu tidak akan pernah menjadi versi yang tepat dari .NET Framework untuk ASP.NET; itu akan selalu berada di belakang.

Yang benar-benar baik dan dapat diterima, jika setidaknya ada 1 versi yang tumpang tindih (yaitu jika Anda tetap menggunakan kerangka kerja lengkap terbaru, masih ada setidaknya satu versi yang didukung secara resmi (ASP). NET Core yang menjalankannya).

Microsoft akan membuat distribusi CoreCLR Windows saja yang mendukung berbagai pustaka .NET Framework.

Atau satu set pustaka .NET Standard 2.0; sehingga mereka dapat berjalan di .NET Core, yang hanya berjalan di Windows yang menutupi celah api?

@benaadams ya itu idenya, meskipun itu tidak akan berhasil untuk apa pun yang melempar PlatformNotSupportedException

@qrli Jika modular, maka Anda dapat meningkatkan modul yang dapat ditingkatkan sekarang, dan biarkan sisanya hingga nanti.

Kecuali dengan "modular" yang Anda maksud "itu adalah aplikasi System.Web ASP.NET IIS monolitik besar yang terdiri dari lusinan perpustakaan berbeda yang beroperasi melalui PInvoke dan COM" dalam hal ini, itu adalah bola besar.

Apakah ada daftar akhir rakitan mana yang terpengaruh dan mana yang tidak? Telah disebutkan bahwa Microsoft.Extensions.* aman dan Microsoft.AspNetCore.Razor.Runtime (diasumsikan) juga, karena itu Microsoft.AspNetCore.Html.Abstractions perlu tetap di netstandard juga. Apakah ada hal lain di Microsoft.AspNetCore.* yang tetap di netstandard ?

@bencyoung Rencana transisi yang saya sarankan adalah untuk memigrasikan berbagai komponen dari waktu ke waktu ke layanan mandiri yang menargetkan .NET Core 2.x (atau apa pun yang paling berhasil dari seluruh alat pengembangan untuk komponen tertentu), menggunakan layanan tersebut dari kode lama Anda batas API standar menggunakan HTTP atau bus pesan, hingga Anda mendapatkan arsitektur sistem terdistribusi yang tepat.

@markrendle Tidak semuanya termasuk dalam sistem terdistribusi. Sebagai contoh nyata: sebagian besar alasan mengapa Stack Overflow merender halaman begitu cepat adalah karena tidak didistribusikan. Meskipun latensi jaringan kami adalah 0,017 md, itu akan menambahkan sedikit biaya jaringan, serialisasi, deserialisasi, dan GC ke aplikasi kami. Membagi sistem ke banyak layanan itu bukan jawaban universal. Ini rumit, mahal, dan negatif bersih untuk banyak skenario juga. Ini mungkin hal yang baik, tetapi juga bisa menjadi hal buruk yang terlalu rumit.

@markrendle masalah saya bukan salah satu dari migrasi ke layanan, itu karena beberapa blok bangunan infrastruktur layanan mendasar menggunakan API yang tidak ada di peta jalan untuk netstandard20 atau bahkan netstandardbanana . .NET Core bagi kami bukan tentang aplikasi greenfield, ini tentang keseluruhan sistem greenfield. System.DirectoryServices adalah salah satu contoh tetapi untuk yang lain, ini adalah WCF, dan lebih banyak lagi, ini adalah System.Data dan hal-hal SqlClient, dan bagi kami, System.Messaging .

Saya siap menggunakan .NET Core ketika saya bisa. Sejauh ini termasuk nol proyek klien, greenfield atau tidak, semuanya diblokir pada sesuatu .

@NickCraver Saya tidak bermaksud bercanda atau apa pun, dan saya tahu bahwa alasan sebenarnya mengapa halaman begitu cepat dirender adalah karena Anda dan orang lain yang membuatnya luar biasa, tetapi hasil pencarian Google yang menyertakan tautan ke halaman Anda render secepat halaman Anda, dan Anda _tahu_ mereka berasal dari sistem terdistribusi yang besar dan rumit. Halaman Amazon merender cukup cepat, kesepakatan yang sama. Saya optimis bahwa ASP.NET Core sedang menuju masa depan di mana ia dapat digunakan untuk membangun sistem dengan cara yang sama seperti yang dibangun, dengan kinerja yang sama, dan saya pikir itu memiliki peluang yang lebih baik untuk sampai ke sana jika membebaskan diri dari siklus pembaruan pulau kecil dari .NET penuh.

@jbogard Saya melihat serupa, tetapi itu akan sangat berbeda ketika .NET Core 2.0 keluar.

Mendesah.

@jbogard

pisang standar bersih

kutipan thread

Masalah utama dengan ini, bagi saya dan tim saya, adalah bahwa tidak ada indikasi bahwa jalan ini adalah masa depan yang diinginkan. Saya tidak tahu ada yang tahu masa depan tetapi mendengar bahwa kita perlu memecahkan apa pun yang bergantung pada kerangka .net lengkap (dll vendor komponen, SDK layanan pembayaran, SDK HSM) ke dalam layanan mereka sendiri dan memperkenalkan STINGS hop baru itu. Itu bukan sesuatu yang dibutuhkan situs ini dan sekarang kami harus memperkenalkan lebih banyak kompleksitas operasi pengembang atau melakukan kembali bagian aplikasi web ke MVC 5.

Kami menggunakan inti asp.net untuk kecepatan kestrel dan API baru yang mewah. Akan lebih baik jika dapat mempertimbangkan opsi dengan lebih akurat terhadap kurangnya jalur peningkatan yang mudah mengingat dependensi kami.

Menambahkan ke @jabrown85
ASP.NET Core telah menjadi rollercoaster emosi sejauh ini.
Setelah csproj mendarat, saya akhirnya pergi "sudah siap sekarang" dan menganggapnya tidak perlu untuk memulai sesuatu yang baru di dalamnya dan memeriksa apa yang dapat ditingkatkan. Setelah pengumuman ini, lebih seperti: "apakah .NET Core pasti mendukung skenario atau haruskah kita aman dan tetap menggunakan MVC5?"

Korbannya rendah sejauh ini, hanya satu aplikasi yang ditulis dalam ASP.NET Core yang mengelola tugas administratif aplikasi MVC 5 utama, tetapi akan macet di 1.x selamanya karena aplikasi utama menggunakan NHibernate.

@markrendle komputer mengatakan tidak

Alangkah baiknya jika ada beberapa roadmap untuk full .NET -> netstandard. Beberapa bagian mendasar hanya mengatakan "Tidak Didukung" dari ApiPort. Saya akan menjalankan analisis yang lebih lengkap dari proyek klien di ASP.NET Core 1.x untuk melihat apa yang hilang.

tetapi akan macet di 1.x selamanya karena aplikasi utama menggunakan NHibernate.

Tidak seharusnya, NHibernate tidak mati kan?

@benaadams secara mengejutkan tidak. Ada beberapa hal yang benar-benar tidak ada pada EF6. Kami default ke EF6 tetapi ada kasus di mana kami harus menggunakan rute NH.

@benaadams secara resmi tidak, ia memiliki jeda di mana tampaknya hampir mati tetapi biasanya ada satu komit setiap beberapa hari. ApiPort melaporkan cakupan 72,26% untuk .NET Standard tetapi saya tidak begitu yakin bahwa itu akan di-porting (setidaknya dalam waktu dekat).

Membaca komentar, saya prihatin dengan arah umum proyek ini menuju. Untuk waktu yang lama ASP.NET adalah pilihan yang baik untuk teknologi yang stabil dan solid. Namun, saya tidak mendapatkan perasaan yang sama sekarang. Ada banyak teknologi "bergerak cepat dan menghancurkan sesuatu", tetapi itu adalah kategori yang sangat berbeda.
Saya berharap Microsoft dapat mengatasi masalah tersebut dan menyelaraskan harapan semua orang.

Ini bukan tentang perangkat lunak perusahaan vs. non-perusahaan. Ada banyak aplikasi Python 2.x yang digunakan saat ini dan tidak semuanya "perusahaan". Terlebih lagi - tidak semua proyek baru menggunakan Python 3 (hampir 9 tahun setelah rilis Python 3.0!).

Adakah yang bisa meringkas seluruh utas dalam posting blog?

Saya telah membaca semua 300+ komentar saat dalam perjalanan/makan siang dan ... Sepertinya saya masih belum "mengerti" sepenuhnya.

Apa yang saya dapatkan adalah:

• .NET Framework lengkap tidak akan didukung di .NET Core 2
• Setiap ketergantungan akan bergantung pada netcoreapp2.0 alih-alih netstandard2.0
• Jika saya menginginkan sesuatu seperti DirectoryServices atau Drawing, saya harus menghapus Full Framework dan melompat ke 2.0

Aku agak melewatkan sisanya... jadwal sibuk dan segalanya.

@MaximRouiller

Jika saya menginginkan sesuatu seperti DirectoryServices atau Drawing, saya harus menghapus Full Framework dan melompat ke 2.0

Tidak, jika Anda ingin perpustakaan yang tidak mendukung .net core, Anda tidak akan dapat menggunakan AspNet Core 2.0+ sama sekali.

@MaximRouiller , apa yang baru saja mereka lakukan adalah bahwa proyek inti Asp.Net tidak akan dapat mereferensikan rakitan kerangka kerja penuh, sehingga tidak berguna bagi banyak jika tidak sebagian besar, mereka mengatakan rakitan seperti system.drawing dan Directoryservices akan di-porting ke netstandar baru atau saya tidak tahu, tetap saja, rakitan lama tidak akan berfungsi kecuali seseorang mem-portingnya, jadi, itu sangat tidak berguna bagi banyak orang karena beberapa rakitan adalah warisan dan tidak akan di-porting, selamanya. Kesimpulannya, siapa pun yang menggunakan .net core dengan versi lengkap dari .NET framework baru saja kacau dan harus kembali ke MVC 5.

@davidfowl Terima kasih untuk daftar ini . Itulah yang sangat penting "jadi apa yang kita dapatkan dari ini?" bagian yang dibutuhkan orang untuk menyeimbangkan biaya/manfaat dalam pikiran mereka.

Jika Anda belum melakukannya, baca daftarnya sehingga Anda mendapat informasi dari kedua sisi. Saya masih berdiri dengan menginginkan 2.x menjadi rilis transisi (dengan manfaat yang dapat dibenarkan bagi bisnis untuk benar-benar menjamin perpindahan), dan 3.x menjadi tempat kemenangan. Bahkan jika itu keluar 2 hari kemudian. Saya sangat menghargai wawasan di semua sisi.

@davidfowl Anda berkata:

Perpustakaan dapat ditulis di atas standar. Ketika hal-hal dalam standar itu sendiri perlu diubah, itu akan memakan waktu lebih lama untuk diadopsi di semua implementasi .NET dan itu termasuk .NET Framework. Ini bisa berarti beberapa hal:
.NET Standard akan berkembang pada tingkat implementasi paling lambat
.NET Standard akan berkembang pada beberapa kecepatan lain dan .NET Framework akan menjadi yang terakhir untuk mengejar ketinggalan.

Tapi mengapa demikian? Tidak bisakah Anda merilis .NET Standard vNext dan membuat .NET menyusulnya beberapa waktu kemudian (beberapa bulan hingga satu tahun kemudian)? Itu berarti bahwa orang-orang yang berada di ujung tombak dan menginginkan ASP.NET Core terbaru dapat meng-host di .NET Core, dan orang-orang yang membutuhkan .NET untuk kode warisan mereka pada akhirnya dapat menggunakan versi ASP.NET Core itu setelah .NET menyusul ke versi .NET Standard yang digunakannya. Saya tidak mengerti mengapa .NET Standard harus diperbaiki secepat implementasi terendah.
Juga di sini kita berbicara tentang implementasi resmi standar, tetapi akan ada implementasi lain yang tidak akan diperbarui bersamaan dengan standar.
Dengan begitu Anda tidak meninggalkan orang. Tentu, mereka membutuhkan waktu lebih lama untuk mendapatkan manfaat dari fitur-fitur terbaru jika mereka berada di .NET, tetapi mereka tidak macet selamanya.

@jdom karena saya tahu tingkat perubahan .NET Framework dan mengapa harus lambat. Ini adalah distribusi yang berbeda dan mungkin tidak ada apresiasi yang cukup untuk itu. Perubahan apa pun akan diterapkan ke miliaran mesin. Layeringnya juga sangat berbeda jadi itu bukan hal yang sepele untuk dipikirkan.

Saya tidak mengerti mengapa .NET Standard harus diperbaiki secepat implementasi terendah.

Jika kami terus menaikkan tanda air rendah untuk standar .net di ASP.NET Core, itu mengalahkan tujuan dan membuat Anda dalam situasi yang sama. Tentu Anda tidak merasa tertinggal karena ada janji bahwa suatu hari nanti API ini akan hadir di .NET Framework tetapi di timeline apa? .NET 4.7 masih belum melengkapi paritas fitur dengan .NET Standard 2.0.

@davidfowl tapi ini akan membawa kembali masalah yang sama seperti dengan PCL, itu akan menjadi penyebut umum terendah dan rasa sakit untuk digunakan, fakta bahwa ASP.NET meninggalkan menggunakannya menunjukkan itu sudah.

@davidfowl tapi ini akan membawa kembali masalah yang sama seperti dengan PCL, itu akan menjadi penyebut umum terendah dan sulit untuk digunakan,

@Suchiman bagaimana itu masalah? Satu-satunya masalah dengan PCL adalah bagaimana mereka dihitung dan diwakili secara dinamis dalam NuGet yang membuatnya sulit untuk memprediksi apa yang akan Anda dapatkan. Bagaimana lagi netstandard akan berfungsi jika itu bukan set API yang dapat diimplementasikan oleh implementasi yang berbeda?

Apa yang membuat PCL mengganggu untuk digunakan adalah area permukaan API yang sangat kecil. .NET Standard 1.3-1.4 sudah cukup untuk mengimplementasikan sebagian besar API perpustakaan dasar.

.NET Standard selalu tentang luasnya.

ASP.NET Core dan .NET Core adalah tentang tumpukan server lintas platform yang kompetitif untuk membangun layanan mikro yang ringan. Nafas dalam pengertian ini adalah dukungan platform yang lebih luas (berjalan di linux, osx, tizen, pi dll).

@davidfowl

Kami telah mengidentifikasi string sebagai salah satu hal utama yang ingin kami coba tangani di .NET Core, ada banyak ide tetapi salah satunya adalah membuat string menjadi utf8 secara default (banyak masalah kompatibilitas tetapi ikuti saya di sini).

Hal lain yang ingin kami perbaiki adalah kemampuan untuk mengambil potongan array/string yang murah, setiap bagian dari memori yang berdekatan. Kami telah menambahkan Spandan sedang melihat Bufferuntuk mewakili ini. Ini mungkin berarti bahwa String dan Array mengimplementasikan antarmuka baru yang memungkinkan untuk mengambil sebuah irisan yang membutuhkan alokasi 0.

Kedengarannya seperti ini berarti bahwa jika saya ingin menggunakan bit baru ini di perpustakaan, perpustakaan juga perlu menargetkan netcoreapp2.0 alih-alih netstandard2.0 . Apakah itu benar?

Adalah ide yang sangat buruk untuk tidak mendukung kerangka kerja 4.x yang lama lagi. Orang tidak mengupgrade jika itu menyebabkan banyak pekerjaan. Lihat ASP klasik super tua, yang tidak digunakan lagi sejak 2002 - sekitar 15 tahun. Dan kami memiliki aplikasi lama yang masih ada di ASP klasik! Apakah Microsoft ingin melihat sesuatu yang serupa sekali lagi? Menjatuhkan dukungan 4.x lama adalah sesuatu yang harus dilakukan wajib - tetapi dalam jangka panjang! Tidak sekarang. Ini bisa menjadi pilihan dalam beberapa tahun, ketika .NET core adalah standar de facto dan hanya aplikasi lama yang menggunakan net 4.x.

Ide di balik (ASP).NET Core benar-benar hebat, hal terbaik yang dilakukan Microsoft sejak rilis .NET. Tapi kekacauan seperti itu menumpulkan konsep bagus ini. Juga sangat menyedihkan, bahwa Microsoft memutuskan perubahan besar seperti itu sendiri, bahkan tanpa mendiskusikannya di komunitas! Sepertinya perusahaan ini belum sepenuhnya belajar bagaimana menangani proyek open source.

@davidfowl

.NET Standard selalu tentang luasnya.

Luas dalam API atau platform?

Apa masalah dengan berevolusi .netstandard pada kecepatan yang sama dengan .netcoreapp ?
Apakah ada target penyetelan BCL khusus untuk .netcoreapp karena tidak akan pernah diimplementasikan di kerangka kerja lain?

Melepaskan .netstandard2.1 bersamaan dengan .netcoreapp2.1 tidak ada bedanya dengan merilis .netcoreapp2.1 pertama dan setahun kemudian .netstandard2.1 bersamaan dengan .net50 , kecuali paket yang menargetkan .netstandard2.1 akan segera mulai berfungsi pada .net50 tetapi akan diblokir jika menargetkan .netcoreapp2.1

ASP.NET Core adalah kerangka webapp tingkat tinggi yang dibangun di atas .NET Core dan di masa depan akan menargetkan .NET Core, _namun_ itu juga bisa menjadi kerangka kerja webapp tingkat tinggi yang dibangun di atas .NET Standard sebagai gantinya, sehingga menargetkan antarmuka API referensi daripada implementasi spesifiknya.

Penempatan publik .NET Standard menjadi target yang mudah untuk dibangun sambil mengesampingkan detail implementasi - dengan 2 kerangka kerja resmi langsung dari Microsoft untuk mencakup sebagian besar kasus penggunaan.

Mengapa mengubah cerita itu sekarang? Jika .NET Framework tidak pernah mengejar, itu tidak penting. Setidaknya ada kemungkinan, atau kerangka kerja pihak ketiga lainnya dapat melakukannya. Jadi bagaimana jika hanya akan ada satu implementasi yang secara realistis mengimbangi? Inilah tepatnya mengapa kami memiliki antarmuka dalam aplikasi kami meskipun hanya ada satu implementasi konkret, sehingga kami memiliki fleksibilitas dan keuntungan yang dibawanya.

Mungkin menurunkan cakupan pada ASP.NET Core 2.0 sejalan dengan .NET Standard 2.0 dan kemudian menggunakan .NET Standard 2.1 untuk fitur yang lebih baru? Tambahkan beberapa garis waktu dukungan yang layak dan bukankah itu akan menyelesaikan seluruh dilema ini? Microsoft memiliki .NET Standard dan kedua kerangka kerja sehingga ketakutan dalam versi yang bertambah ini tampaknya sama sekali tidak berdasar...

Saya kira harus dipertimbangkan bahwa ASP.NET ke ASP.NET Core bukanlah jalur migrasi untuk semua orang.

ASP.NET pada kerangka kerja penuh akan tetap dan mendapatkan fitur tetapi tidak seperti Core.

Migrasi akan menjadi lebih mudah dari waktu ke waktu tetapi tidak pernah menjadi 100% cocok.

Orang-orang masih menjalankan ASP klasik. Itu bagus untuk mereka juga.

@davidfowl Saya sangat menghormati seluruh tim dan kemajuan yang Anda semua buat. Jadi, tolong jangan menganggap ini sebagai sesuatu yang sedang terjadi. Kalian adalah pionir, dan kami semua memandang Anda sebagai contoh bagaimana melakukan sesuatu dengan benar. Tetapi saya tidak melihat banyak dari poin-poin ini sebagai masalah perubahan target langsung, terutama ketika hal itu belum dikomunikasikan. Mungkin aku salah.

Saya ingin membuang beberapa hal gila di sini karena telah disebutkan beberapa kali. Apa yang akan saya katakan tidak ada hubungannya dengan apa yang akan terjadi, itu semua spekulasi pada saat ini. Beberapa orang bertanya mengapa kami ingin menargetkan .NET Core daripada .NET Standard.

• Kami telah mengidentifikasi string sebagai salah satu hal utama yang ingin kami coba tangani di .NET Core, ada banyak ide tetapi salah satunya adalah membuat string menjadi utf8 secara default (banyak masalah kompatibilitas tetapi ikuti saya di sini).

Poin ini di sini pasti akan menjadi pengubah permainan, tetapi IMO itu satu-satunya yang benar-benar tidak memerlukan kerangka kerja penargetan, dan itu bukan untuk netcoreapp20.

• Hal lain yang ingin kami perbaiki adalah kemampuan untuk mengambil potongan array/string yang murah, setiap bagian dari memori yang berdekatan. Kami telah menambahkan Spandan sedang melihat Bufferuntuk mewakili ini. Ini mungkin berarti bahwa String dan Array mengimplementasikan antarmuka baru yang memungkinkan untuk mengambil sebuah irisan yang membutuhkan alokasi 0.
• Ini mengarah ke metode baru pada String yang memungkinkan pemisahan yang tidak mengalokasikan array setiap saat.
• Ini menyebabkan kelebihan beban ke Int, UInt, dll (TryParse) yang menggunakan Spandan span.
• Ini mengarah ke rutinitas pengkodean baru yang menggunakan Span.
• Penyanggadan spanmembiarkan Anda merepresentasikan memori dengan cara yang seragam dan kami ingin memutakhirkan tumpukan jaringan untuk memungkinkan melewati buffer yang disematkan sebelumnya yang menggunakan Spanatau Penyangga.

Semua ini masih dapat diimplementasikan sebagai paket di atas standar bersih saat ini. Anda bahkan tidak perlu netstandard20 untuk ini. Saya mengerti tidak ingin membawa barang bawaan ini, tetapi kita semua di dunia non-MS harus membuat impl-esque BCL khusus setiap saat ketika use case atau perf tidak cocok. Belum lagi bahwa Span API juga tidak ditargetkan untuk 2.0 (kecuali jika diubah lagi).

Kestrel akan mengimplementasikan HTTP2 dalam jangka waktu 2.x (saat ini ditujukan pada 2.1) dan itu membutuhkan API baru pada aliran SSL untuk melakukan ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
Http Client pada .NET Core mendukung streaming dupleks, ini akan memungkinkan untuk menerapkan titik akhir streaming melalui http di signalr melalui satu permintaan http non websocket.

Saya merasa yang ini sedikit lebih rumit, tetapi tidak jauh berbeda dari Kestrel membawa-bawa libuv. Implementasi CURL dari .Net Core dapat dengan mudah ditarik ke dalam paket ekstensi standar bersih sampai semua orang mengikutinya.

• Kami memotong implementasi parser header dari HttpClient dan System.Net.Http dan menamainya (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers) sehingga kami dapat meningkatkannya dan minta mereka mendukung .NET Framework dan .NET Core. .NET Core memiliki salinan perbaikan ini yang belum kembali karena tidak perlu meningkatkannya (kami tidak dapat menggunakannya).

Benar, tapi ini bisa dibilang cara yang tepat untuk melakukan ini dalam kasus ini. Frustrasi untuk menunggu dan bertahan pada implementasi, tetapi sekali lagi, saya tidak melihat bagaimana ini berbeda dari apa yang dilakukan orang lain ketika mereka menulis kerangka kerja atau perpustakaan.

• Tanpa kemampuan untuk menghidupkan kembali inti primitif, kami didorong untuk memotongnya dan membuat hal-hal yang terlihat seperti mereka tetapi sebenarnya bukan. Itulah alasan kami memiliki BCL kecil kami sendiri di dalam ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

Sekali lagi, sama seperti kita semua.

ASP.NET Core dan .NET Core adalah tentang tumpukan server lintas platform yang kompetitif untuk membangun layanan mikro yang ringan.

ASP.Net Core memiliki beberapa pesan seperti itu. .Net Core telah dikirim sejak hari pertama sebagai subset framework .Net sisi server xplat yang berfungsi penuh. Belum pernah saya mendengar ada yang mengatakan bahwa .Net Core hanya untuk layanan mikro. Saya pernah mendengar Anda dapat menggunakannya dengan ASP.Net Core jika Anda mau, tetapi juga aplikasi konsol, analisis data, layanan DB, dll. Apakah arah .Net Core efektif "apa pun yang paling diinginkan tim ASP.Net Core"?

ASP.NET pada kerangka kerja penuh akan tetap dan mendapatkan fitur tetapi tidak seperti Core.

Akankah? Saya masih belum melihat siapa pun dari MS mengonfirmasi bahwa itu masih sedang dikerjakan. Firasat saya mengatakan bahwa tidak. Saya mengerti. Tim membutuhkan jenis momen "pindahkan atau hilangkan" untuk membebaskan diri. Saya hanya tidak berpikir ini adalah saat itu.

Dengan asumsi bahwa kita memiliki perakitan logika bisnis 4.6, yang menggunakan driver Oracle.Net, NHibernate dan RabbitMQ (semuanya dalam 4.6). Antarmuka dengan ASP.Net hanya melalui objek, permintaan, dan tanggapan bisnis kami. Bisakah kita mereferensikan perakitan ini di ASP.Net Core 2 kita, tanpa kompilasi ulang?

Ringkasan singkat saya

@stefan2410 jawaban singkat, tidak, Anda tidak dapat mereferensikan full framewrok, Anda dapat mereferensikan rakitan tersebut hanya jika dibuat untuk netstandar 2.0.

@mattnischan

Semua ini masih dapat diimplementasikan sebagai paket di atas standar bersih saat ini. Anda bahkan tidak perlu netstandard20 untuk ini. Saya mengerti tidak ingin membawa barang bawaan ini, tetapi kita semua di dunia non-MS harus membuat impl-esque BCL khusus setiap saat ketika use case atau perf tidak cocok.

Maaf tapi sebenarnya tidak. Anda tidak dapat melakukan jenis patch monyet. Kecuali Anda menyarankan kami menambahkan jenis baru dan tidak mengubah yang sudah ada.

Belum lagi bahwa Span API juga tidak ditargetkan untuk 2.0 (kecuali jika diubah lagi).

Span ada di 2.0 sebagai implementasi tetapi bukan API publik. Kami membuat perubahan besar di jurusan baru sehingga kami dapat melakukan lebih banyak fitur dalam versi kecil. Jika ASP.NET Core 2.1 menargetkan .NET Standard 2.1, maka dukungan .NET Framework akan dihapus lagi.

Saya merasa yang ini sedikit lebih rumit, tetapi tidak jauh berbeda dari Kestrel membawa-bawa libuv. Implementasi CURL dari .Net Core dapat dengan mudah ditarik ke dalam paket ekstensi standar bersih sampai semua orang mengikutinya.

Jadi apa yang Anda katakan adalah kita harus mengganti nama semua kelas di BCL sehingga kita dapat menggunakannya di kedua .NET Standard.

Belum pernah saya mendengar ada yang mengatakan bahwa .Net Core hanya untuk layanan mikro. Saya pernah mendengar Anda dapat menggunakannya dengan ASP.Net Core jika Anda mau, tetapi juga aplikasi konsol, analisis data, layanan DB, dll. Apakah arah .Net Core efektif "apa pun yang paling diinginkan tim ASP.Net Core"?

Tidak, .NET Core adalah kerangka kerja tujuan umum yang awalnya tidak memiliki vertikal pada intinya. Mungkin saja ASP.NET Core seharusnya menjadi vertikal alih-alih perpustakaan di atas .NET Core, itu mungkin menghindari beberapa kebingungan ini.

Akankah? Saya masih belum melihat siapa pun dari MS mengonfirmasi bahwa itu masih sedang dikerjakan. Firasat saya mengatakan bahwa tidak. Saya mengerti. Tim membutuhkan jenis momen "pindahkan atau hilangkan" untuk membebaskan diri. Saya hanya tidak berpikir ini adalah saat itu.

Ya, dukungan HTTP/2 telah ditambahkan pada rilis terakhir. Ada tim lain yang bekerja di ASP.NET dan IIS dan mereka melakukan perbaikan. Namun, mereka tidak pada skala yang sama dengan apa yang dilakukan ASP.NET Core.

Saya tidak memiliki perasaan yang kuat tentang ini karena saya menghindari menjalankan layanan ASP.NET Core saya pada kerangka kerja penuh seperti wabah. Dengan itu, saya harus menghindari penggunaan beberapa perpustakaan yang bagus dan matang karena mereka tidak mendukung .NET Standard karena mereka menunggu netstandard2.0 atau hanya karena mereka tidak mau.

Ketakutan saya adalah bahwa menghapus kemampuan untuk menjalankan ASP.NET Core pada kerangka kerja penuh akan menghalangi pengguna untuk mem-porting aplikasi MVC 5/Web API 2 mereka saat ini ke ASP.NET Core yang hanya akan memberikan alasan lain bagi penulis perpustakaan untuk menghindari porting ke .NET Standar. Mengapa repot-repot melakukan peningkatan jika tidak ada pengguna Anda yang mendapat manfaat? Ini menjadi masalah ayam dan telur dan saya hanya khawatir ini akan merusak ekosistem secara keseluruhan saat mulai mendapatkan daya tarik. Pertama, Anda membutuhkan pengguna ASP.NET Core dan saya tidak yakin ada sebanyak yang kita semua inginkan. Semoga saya salah.

Jika ASP.NET Core 2.1 menargetkan .NET Standard 2.1, maka dukungan .NET Framework akan dihapus lagi.

Tidak, itu hanya berarti bahwa Net Framework akan secara otomatis mendukung ASP.NET Core 2.1 segera setelah mendukung .NET Standard 2.1, kapan pun itu, bahkan jika itu membutuhkan satu atau dua tahun.

Hal yang sama untuk semua platform .NET Standard lainnya (Xamarin / Unity / ...).

Membangun di .NET Standard berarti platform lain akan menyala _akhirnya_, membangun di .NET Core berarti mereka akan menyala __never__.

Saya berasumsi bahwa rencananya masih bahwa full-fx akan mengejar standar bersih, bahkan jika dengan penundaan yang lama?
(dan jika tidak ada platform lain selain NET Core yang diharapkan untuk mengimplementasikan .NET Standard 2.1, lalu mengapa memiliki .NET Standard?)

Maaf tapi sebenarnya tidak. Anda tidak dapat melakukan jenis patch monyet. Kecuali Anda menyarankan kami menambahkan jenis baru dan tidak mengubah yang sudah ada.

Yang terakhir adalah apa yang telah dilakukan dalam kebanyakan kasus di 1.x, bukan? Apakah itu tiba-tiba tidak lagi bisa dipertahankan?

Span ada di 2.0 sebagai implementasi tetapi bukan API publik. Kami membuat perubahan besar di jurusan baru sehingga kami dapat melakukan lebih banyak fitur dalam versi kecil. Jika ASP.NET Core 2.1 menargetkan .NET Standard 2.1, maka dukungan .NET Framework akan dihapus lagi.

Mengapa itu akan dijatuhkan? Apakah Anda mengatakan Span akan _never_ ada di Framework?

Jadi apa yang Anda katakan adalah kita harus mengganti nama semua kelas di BCL sehingga kita dapat menggunakannya di kedua .NET Standard.

Tidak. Saya mengatakan bahwa jika saya memerlukan Kamus dengan API yang berbeda, saya harus membuat sesuatu yang lain dan juga tidak menyebutnya System.Collections.Generic.Dictionary, sama seperti yang sudah kalian lakukan dengan Microsoft.Net.*

Ya, dukungan HTTP/2 telah ditambahkan pada rilis terakhir. Ada tim lain yang bekerja di ASP.NET dan IIS dan mereka melakukan perbaikan. Namun, mereka tidak pada skala yang sama dengan apa yang dilakukan ASP.NET Core.

Itu adil. Aku tidak menyadari itu sebelumnya.

Yang terakhir adalah apa yang telah dilakukan dalam kebanyakan kasus di 1.x, bukan? Apakah itu tiba-tiba tidak lagi bisa dipertahankan?

Ini menciptakan kekacauan. Mereka mencoba melakukan itu sesedikit mungkin. Desain dan penerapan API jauh lebih rumit daripada yang disadari kebanyakan orang, menurut saya. Dan bukan orang-orang Microsoft yang membuatnya seperti itu, ini adalah kenyataan mendukung banyak platform dan garis waktu. Saya tidak menghargai ini sampai berada di tengah-tengahnya beberapa kali dan membicarakan semuanya. Saya sangat berharap penerusan tipe berada pada level metode. Itu akan menyelesaikan beberapa kasus sejauh ini :(

Mengapa itu akan dijatuhkan? Apakah Anda mengatakan Span tidak akan pernah ada di Framework?

Itu perlu dihapus dari ASP.NET Core 2.0 , karena garis waktu tidak akan selaras lagi, karena kerangka kerja penuh belum memilikinya .

Itu perlu dihapus dari ASP.NET Core 2.0, karena garis waktu tidak akan selaras lagi, karena kerangka kerja lengkap belum memilikinya.

AFAIK, Spans adalah bagian dari paket netstandard1.x yang dapat digunakan di .NET Desktop (ini adalah implementasi portabel sehingga tidak memiliki peningkatan kinerja yang sama seperti jika didukung ke CLR, tetapi kemungkinan cukup baik).

Sunting: paket System.Memory memiliki netstandard1.0 TFM, sehingga dapat digunakan bahkan di .NET 4.5.

Yang terakhir adalah apa yang telah dilakukan dalam kebanyakan kasus di 1.x, bukan? Apakah itu tiba-tiba tidak lagi bisa dipertahankan?

Kami menghentikan pekerjaan fitur di arah tertentu hari ini karena itu. Ini disengaja dan kami menahan diri dan menolak untuk menggunakan API baru dengan menyalin dan mengimplementasikan kembali hal-hal di luar .NET Standard sehingga .NET Framework dapat berfungsi. Ini bukan segalanya tetapi ada beberapa bagian mendasar yang ingin kami sentuh ke depan, bagaimanapun juga, kami (Microsoft) mengontrol kedua belah pihak.

Mengapa itu akan dijatuhkan? Apakah Anda mengatakan Span tidak akan pernah ada di Framework?

Span sendiri memiliki versi portabel yang berjalan di mana saja, saya tidak yakin implementasi cepat akan pernah ada di .NET Framework. API yang akan ditambahkan ke .NET Framework yang memanfaatkan Span mungkin membutuhkan waktu lebih lama daripada Span itu sendiri, ekstensif. Kapan terakhir kali kita mengubah string dan array di .NET Framework?

Tidak. Saya mengatakan bahwa jika saya memerlukan Kamus dengan API yang berbeda, saya harus membuat sesuatu yang lain dan juga tidak menyebutnya System.Collections.Generic.Dictionary, sama seperti yang sudah kalian lakukan dengan Microsoft.Net.*

Itulah yang Anda sarankan. Kami tidak ingin memiliki Microsoft.Extensions.Collections.Generic. Kami mencoba yang terbaik untuk menghindarinya dan kami hidup dengan API dan polyfill lama jika memungkinkan (https://github.com/aspnet/DependencyInjection/blob/139d91e57dd31fcd5c6ddaf11ad1f771b5855807/src/Microsoft.Extensions.DependencyInjection/Internal/ConcurrentDictionaryExtensions). Ini tidak berkelanjutan dan itu berarti .NET Core tidak mendapatkan manfaat karena kami secara aktif menghindari menggunakannya.

@PinpointTownes memiliki rentang tidak cukup baik, mereka perlu menggunakannya dalam metode panggilan ke tipe yang ada. Saat itulah penerusan tipe tingkat kelas ikut bermain dan menyebabkan banyak masalah.

@0x53A

Itu adil. Bisakah Anda memberi tahu saya mengapa perpustakaan populer di NuGet tidak menghentikan dukungan untuk versi .NET Framework yang lebih lama yang jelas-jelas tidak didukung? Pustaka paling populer menargetkan net20, net35, net40 dll. Mengapa tiba-tiba boleh saja meminta versi .NET Framework tertinggi untuk tetap menggunakan ASP.NET Core? Apakah menurut Anda itu masuk akal?

Ini adalah penghenti pertunjukan. Saya harus mempertimbangkan untuk membatalkan migrasi dari ASP.NET MVC 5/Web Api 2 To Core. Banyak kerangka kerja yang stabil belum tersedia untuk inti. Kami masih menggunakan EF6.x karena EF Core belum cukup matang untuk Feature Comparison .

@PinpointTownes memiliki rentang tidak cukup baik, mereka perlu menggunakannya dalam metode panggilan ke tipe yang ada.

"kebutuhan" mungkin agak berlebihan. Span terutama digunakan untuk kinerja, jadi tidak ada yang mencegah mereka menggunakan kelebihan tidak-super-perfy yang ada di .NET Desktop menggunakan ifdefs hingga .NET Desktop mendapatkan dukungan asli untuk Span.

@davidfowl Saya pikir masalah besarnya adalah emosional. Jika Anda menargetkan netstandard, saya tahu bahwa saya akan dapat memutakhirkan dari 1.x ke 2.x pada akhirnya (walaupun dengan penundaan). Sebagian besar waktu, memperbarui netfx bukanlah masalah besar untuk sebuah aplikasi (berbeda untuk lib).

Tetapi beberapa aplikasi tidak akan pernah bisa membuat lompatan netfx -> netcore, jadi jika Anda menargetkan netcore, mereka tahu bahwa mereka menemui jalan buntu dengan 1.x.

Dalam hal itu, akan lebih baik jika inti Asp.net tidak pernah berjalan di netfx, sebagaimana adanya, mereka berharap untuk melanjutkan, dan sekarang merasa (seharusnya, IMO) dikhianati. Lagi pula, mereka mungkin telah menginvestasikan banyak waktu untuk ini.

Saya pribadi tidak berinvestasi dalam hal ini, karena saya bukan pengguna asp.net, pertanyaan besar saya sebenarnya hanya

Saya berasumsi bahwa rencananya masih bahwa full-fx akan mengejar standar bersih, bahkan jika dengan penundaan yang lama?
(dan jika tidak ada platform lain selain NET Core yang diharapkan untuk mengimplementasikan .NET Standard 2.1, lalu mengapa memiliki .NET Standard?)

Mengenai lib lain yang menargetkan net20, net35, dll, menurut pengalaman saya, sebagian besar penulis mencoba menargetkan versi terendah yang mereka bisa dan hanya memotong platform di mana mereka tidak punya pilihan lain.

Dan __ya, saya pikir masuk akal untuk menghentikan dukungan untuk versi .NET Framework__ yang lebih lama, karena masih tersedia jalur migrasi yang jelas. Perbarui saja versi Anda. Sebagian besar waktu Anda bahkan tidak perlu mengubah apa pun, "cukup" kompilasi ulang dan uji.

Saya pikir kalian benar-benar meremehkan jumlah aplikasi yang tidak akan pernah dapat menargetkan netcore - hanya satu ketergantungan pihak ketiga sumber tertutup sudah cukup untuk memblokirnya.

Span sendiri memiliki versi portabel yang berjalan di mana saja, saya tidak yakin implementasi cepat akan pernah ada di .NET Framework. API yang akan ditambahkan ke .NET Framework yang memanfaatkan Span mungkin membutuhkan waktu lebih lama daripada Span itu sendiri, ekstensif. Kapan terakhir kali kita mengubah string dan array di .NET Framework?

@davidfowl Saya pikir ini mungkin bagian dari masalah. Sejujurnya saya telah bermain sedikit di sini, karena kami terjebak di tengah sebagai aplikasi greenfield yang dimulai tepat sebelum .Net Core adalah sesuatu, jadi kami mengangkangi garis.

Pemikiran kami selalu, gunakan lib baru yang mewah (seperti Kestrel) jika memungkinkan, tetapi tunggu hingga .Net Core stabil (dan saya senang kami melakukannya, jika hanya untuk perubahan perkakas), _atau_ tunggu bit Core keren untuk membuatnya kembali ke Framework. Saya pikir asumsi kebanyakan orang adalah bahwa sebagian besar, jika tidak semua, kemajuan yang telah dibuat corefx akan membuatnya menjadi Framework vNext atau vNext+1. Tapi, sepertinya (dari pandangan 30k kaki kami) dari ini dan perubahan lainnya bahwa Framework bukanlah platform masa depan.

Saya kira jika seperti itu, begitulah adanya. Proyek kami sangat besar, jadi percayalah ketika saya mengatakan bahwa saya memahami rasa sakit memiliki banyak impl kustom dari hal-hal yang dekat dengan tetapi tidak cukup jenis BCL atau ifdef spaghetti. Jadi, saya tidak menyarankan hal-hal karena ketidaktahuan akan komplikasinya. Pasti ada timbal balik.

Memang pertanyaan yang bagus: apa yang tersisa dari backporting fitur inti .net ke .NET penuh? Seperti yang saya baca di sini, .NET full sangat rapuh, memindahkan kode ke sana membutuhkan waktu lama (bergerak sangat lambat) dan dapat pecah kapan saja (bisa jadi, tidak tahu seberapa terjalinnya) jadi saya menyimpulkan itu tidak akan terjadi sangat sering.

Tidak bisa keduanya: baik backporting ke .NET full tidak masalah, mereka hanya merilis lebih jarang (misalnya setiap 6 bulan hingga satu tahun) atau sangat rumit dan rawan kesalahan. Jika itu yang pertama, lanjutkan saja dan jangan biarkan pengguna Anda membayar tagihan dan berhenti menggunakan yang terakhir sebagai alasan. Jika yang terakhir, bukankah kesimpulan yang tepat maka netstandard adalah sebuah kesalahan, karena yang terpenting untuk masa depan adalah API .netcore?

Saya sangat prihatin dengan masa depan arah .NET. Perusahaan saya membuat perkakas untuk .NET full dan .NET standard1.6. Hal terakhir yang kami inginkan adalah bahwa kekuatan pendorong arah .NET (fitur baru yang akan di-backport ke .NET penuh, seperti yang dikatakan dalam pengumuman inti .NET beberapa bulan yang lalu) membagi hal-hal dan ekosistem secara efektif terbelah dua, karena fragmentasi membunuh.

Tidak ada di utas ini yang meyakinkan saya bahwa semuanya baik-baik saja untuk masa depan _all_ .NET dan ekosistem yang diperlukan untuk membuatnya tetap hidup: Saya hanya melihat dua grup:

• Orang-orang yang khawatir bahwa pilihan semakin rumit dan mereka memiliki masalah yang sulit di depan
• Microsoft yang melihat satu jalan di depan: jalan inti .net.

Keduanya tidak cocok saat ini. Bisakah seseorang dari Microsoft mendapatkan cerita yang koheren sehingga kita semua dapat melihat apa yang sebenarnya, bagaimana keadaan sebenarnya, yaitu dengan mendukung fitur ke .net penuh, apa yang dilakukan tentang banyak hal yang hilang di .net core (hal-hal sqlserver, ruang lingkup transaksi untuk beberapa nama) dan bagaimana Microsoft berpikir mereka dapat menjual arah baru ini sebagai platform yang solid, andal, dan dapat diandalkan untuk masa depan, sehingga perusahaan dan tim besar dapat memilihnya tanpa khawatir.

Sementara saya setuju bahwa semua ini adalah hal yang baik dalam jangka panjang, saya juga berpikir bahwa menjatuhkan dukungan untuk kerangka penuh dengan 2.0 terlalu dini.

Kami ingin pindah ke .NET Core sesegera mungkin, tetapi sayangnya, pemblokir terbesar kami saat ini hampir secara eksklusif perpustakaan Microsoft (Misalnya Entity Framework Core belum cukup baik, Azure Service Bus hanya memiliki pratinjau yang sangat awal).

Meskipun saya berharap perpustakaan Azure akan siap dalam beberapa minggu/bulan ke depan, sepertinya EF Core tidak akan memiliki fitur yang cukup dalam waktu dekat.

Saya tidak tahu apa-apa tentang internal EF6 tetapi tidakkah mungkin dengan upaya yang masuk akal untuk membuatnya menargetkan standar bersih? Ini akan menghapus pemblokir besar...

"Tetap di 1.x" sepertinya bukan alternatif yang baik karena pasti akan ada banyak perpustakaan yang tidak peduli (atau tidak memiliki sumber daya/pengetahuan untuk mendukung keduanya) dan hanya meningkatkan ketergantungannya ke 2.0

PS: Saya sangat frustrasi dengan betapa kompleksnya ekosistem .NET selama beberapa tahun terakhir. Saya harus menghabiskan BANYAK waktu untuk memahami semua hal baru dan saya tidak melihat bagaimana pengembang baru harus memahami semua ini. Ada begitu banyak informasi usang di internet sekarang karena semua perubahan yang cukup ekstrim ini.
Juga, semua versi produk yang berbeda (.net core, sdk, .net standard, ...) sangat membingungkan. Saya belum pernah melihat seseorang yang memahami tabel standar .NET tanpa memerlukan penjelasan 20 menit. 😞.

siapa pun yang menggunakan .net core dengan versi lengkap dari .NET framework baru saja kacau dan harus kembali ke MVC 5

Ya. Saya mengerti alasannya, dan saya kira saya bisa mengatakan saya seharusnya melihat ini datang, tetapi sangat membuat frustrasi karena ini menimpa kami tanpa peringatan sebelumnya.

Kami memiliki ekosistem aplikasi, seperti banyak lainnya, dengan perpustakaan bersama sejak satu dekade dan lebih, beberapa aplikasi MVC 3, 4, 5, aplikasi konsol, layanan windows, ratusan ribu baris kode. Kami bahkan tidak dalam situasi yang buruk untuk meningkatkan dibandingkan dengan beberapa.

Kami baru-baru ini membuat beberapa aplikasi web baru menggunakan ASP.Net Core 1.1, yang menargetkan kerangka kerja 4.6.2 penuh. Aplikasi ini menggunakan petak besar perpustakaan bersama kami yang ada. Kami telah menghabiskan banyak waktu dev berurusan dengan project.json, lalu .csproj baru, mencoba mencampur .csproj lama dan baru dalam solusi yang sama, kembali ke VS15 untuk menyelesaikan sesuatu dengan jenis .csproj lama, rusak Sistem. dependensi, dan serangkaian masalah pengikatan perakitan, masalah pembuatan & penerbitan .. daftarnya terus bertambah.

Dan sekarang kami dibiarkan menggantung tinggi dan kering di jalan buntu. Apakah kita membuang beberapa bulan pengembangan atau menghabiskan banyak waktu untuk mencoba terlebih dahulu hanya memastikan apa yang mungkin dan mungkin tidak berhasil dan kemudian mencari cara untuk meningkatkan, dan kemudian jika itu mungkin melakukannya.

Saya tidak bisa mengatakan saya tidak setuju dengan arah dan kebutuhan itu, tetapi komunikasi sebelumnya akan dihargai.

Oh, dan tentu saja, perpustakaan Fabric Layanan Azure juga tidak berjalan pada inti .NET - yang merupakan pemblokir lain bagi kami.

Saya akan mengatakan Anda harus mendukung kerangka .NET penuh sampai Anda dapat memberikan cerita inti .NET yang tepat dalam Microsoft (dan terutama Azure).

@cwe1ss Perubahan ini akan mengurangi beberapa kompleksitas ekosistem .NET. Karena Anda tidak akan memiliki dua format yang berbeda (ASP.NET Core + .NET Full dan ASP.NET + .NET Core). Saya sangat setuju tentang informasi yang sudah ketinggalan zaman, tetapi saya pikir itu tidak dapat dihindari ketika Anda mengembangkan di tempat terbuka seperti yang dilakukan Microsoft sekarang.

@davidfowl

Kisah berbagi kode di berbagai runtime .NET adalah .NET Standard. Pustaka Anda harus mencoba menargetkannya ke kode yang dibagikan di seluruh .NET Core dan .NET Framework.<

Tetapi kerangka lengkap seperti yang saya pahami bahkan tidak mendukung standar net jadi itu benar-benar bukan standar yang berguna.

Microsoft tampaknya telah melupakan pentingnya kompatibilitas ke belakang.<<

Masalahnya adalah, ASP.NET Core tidak pernah dimaksudkan untuk kompatibel ke belakang... Itu sebabnya ada perubahan paradigma besar dari ASP.NET 4.x. Sepertinya jika kompatibilitas mundur adalah bit urutan tinggi untuk Anda akan lebih baik menggunakan ASP.NET 4.x di .NET Framework. Itu didukung untuk masa mendatang dan akan ditambal keamanannya selama Windows masih hidup.<

Patch keamanan hanya bagian dari masalah. Standar web berubah begitu cepat sehingga kita perlu memiliki sesuatu yang dapat kita gunakan dengan standar terbaru. Jadi misalnya saya melihat sesuatu di atas tentang HTTPS v2. Saya tidak tahu apa artinya itu dalam praktik tetapi intinya adalah saya ingin kerangka kerja saya dapat mendukung hal-hal ini. Jika saya terpaksa tinggal dengan versi kerangka kerja yang lebih lama apakah itu v4 atau v1 itu tidak akan mendukung hal-hal yang diperlukan.

ASP .net Core selalu dipasarkan sebagai berjalan di .net core dan di framework. Seperti yang dikatakan orang lain, tidak masalah bagi saya jika kita harus menunggu enam bulan atau satu tahun sampai kerangka itu menyusul. Saya biasanya sekitar enam bulan atau lebih di belakang pula. Tetapi apa yang tampaknya terjadi adalah bahwa investasi kami yang ada saat ini benar-benar ditinggalkan, seperti banyak teknologi Microsoft lainnya yang banyak dari kami telah menginvestasikan waktu.

Stefan

@Rutix untuk "berkembang di tempat terbuka" perubahan terobosan besar ini dilakukan secara diam-diam tanpa pengumuman atau survei (bagaimanapun, masalah ini dibuat oleh anggota komunitas yang menonton permintaan tarik).

Melakukan hal-hal diam-diam telah menggigit microsoft di masa lalu dan mereka tampaknya tidak belajar. Dan jangan coba-coba memberi tahu saya bahwa mereka tidak dapat melihat bahwa menghentikan dukungan kerangka kerja penuh akan mengganggu komunitas dan melukai kepercayaan dan investasi di platform.

Insiden terakhir adalah https://github.com/dotnet/roslyn/issues/17054 tetapi mereka dengan cepat memperbaikinya, saya bertanya-tanya bagaimana ini akan berakhir.

Tetapi kerangka lengkap seperti yang saya pahami bahkan tidak mendukung standar net jadi itu benar-benar bukan standar yang berguna.

@stefanolson Itu tidak benar. Library yang menargetkan .Net Standard 1.x dapat berjalan di berbagai versi full framework saat ini. Perpustakaan yang menargetkan .Net Standard 2.0 dijadwalkan untuk dapat berjalan pada 4.6.1 yang terakhir saya lihat.

@Suchiman Saya sangat setuju dengan Anda di sana. Saya agak kecewa karena mereka tampaknya tidak belajar bagaimana berkomunikasi dan menjatuhkan bom di komunitas. Mereka bisa menangani cara ini lebih baik jika mereka mengumumkannya terlebih dahulu dan melakukan diskusi komunitas.

Tetapi kerangka lengkap seperti yang saya pahami bahkan tidak mendukung standar net jadi itu benar-benar bukan standar yang berguna.

@stefanolson Memang benar. Versi .NET Framework yang berbeda (yang sudah ada) menerapkan versi standar .NET yang berbeda. Lihat https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

Saya tahu saya agak terlambat untuk utas ini, tetapi berikut adalah dua kasus penggunaan kami untuk menggunakan ASP.NET Core di NetFX di Windows:

Menggunakan ASP.NET untuk meng-host REST API untuk aplikasi Anda

Aplikasi kami adalah jenis aplikasi ".NET API-berubah menjadi-REST API". Ini pertama kali dikirimkan sebagai .NET API, dan memiliki ketergantungan ke semua jenis barang Windows.

Saat kami menambahkan REST API, kami memilih ASP.NET Web API untuk meng-host-nya. Ketika menjadi jelas bahwa Web API bersatu di ASP.NET vNext/5/Core, __and__ kami menemukan bahwa __ASP.NET Core akan berjalan di NetFX__ masuk akal untuk menggunakan ASP.NET vNext/5/Core.

Meskipun kami memanfaatkan .NET Core untuk mem-port (bagian dari) aplikasi kami ke Linux dan macOS, masih ada dependensi Windows yang tidak berjalan di .NET Core (untuk mendapatkan daftar dependensi yang kami lakukan port, periksa CoreCompat.* paket NuGet).

Singkat cerita, kita sekarang menemukan diri kita terkunci pada ASP.NET Core 1.x yang akan tetap mendukung untuk waktu yang terbatas. Lalu apa? Kembali ke ASP.NET 4?

Saya memahami semua pekerjaan yang Anda lakukan dan mendorong batasan di area lain .NET Core, tetapi dalam kasus penggunaan saya, saya tidak meng-hosting situs web yang terpapar internet volume tinggi, saya meng-hosting REST API yang akan dapat seperti apa, maks 10-20 RPS?

Dukungan Visual Studio

Sungguh, pengalaman Visual Studio 2017 saya di NET 4.x masih jauh lebih baik daripada .NET Core - contoh bagus ada jumlah waktu yang diperlukan untuk mengkompilasi ulang proyek pengujian dan membuat tes baru muncul di jendela pengujian . Ini jauh lebih cepat di NetFX.

Kami berakhir dengan situasi di mana hari ini kami memiliki proyek NetFX dan .NET Core yang secara berdampingan mengkompilasi basis kode yang sama. Satu-satunya alasan kami mengikuti pemeliharaan ganda ini adalah karena kinerja Visual Studio dengan proyek .NET Core (_terutama_ pengujian unit dan debugger).

Sebagai renungan, apa yang benar-benar mengejutkan saya adalah bahwa perubahan ini dilakukan sekarang, beberapa hari sebelum rilis pratinjau. Tampaknya menunjukkan bahwa belum ada alasan teknis untuk melakukannya - jadi mengapa tidak membuat perubahan di ASP.NET Core v3?

@mattnischan

@stefanolson Itu tidak benar. Library yang menargetkan .Net Standard 1.x dapat berjalan di berbagai versi full framework saat ini. Perpustakaan yang menargetkan .Net Standard 2.0 dijadwalkan untuk dapat berjalan pada 4.6.1 yang terakhir saya lihat.<

Tampak bagi saya seolah-olah asp.net core akan menjalankan .net core bukan .net standar? Jadi saya masih tidak yakin apa inti dari standar .net - apakah itu akan ditinggalkan secara virtual segera setelah dibuat.

Sangat masuk akal jika asp.net core membutuhkan .net standard 2.1 karena ada hal-hal yang mereka butuhkan yang tidak ada dalam framework saat ini. Jadi kami harus menunggu hingga kerangka .net lengkap mendukung fungsionalitas tambahan tersebut sebelum kami dapat menggunakan versi terbaru dari inti Asp.net. Itu akan berhasil dan masuk akal.

Tetapi sebaliknya mereka hanya meninggalkan standar membuat standar tidak berguna (jika saya memahami situasi yang membingungkan ini dengan benar)

Jadi... Build 2017-nya mulai besok; Saya membayangkan tim sangat sibuk mempersiapkannya. Mungkin beberapa pengumuman, mungkin tidak. Mungkin, beri mereka sedikit ruang untuk bernafas dan berkumpul kembali dalam seminggu?

Mungkin menangkap acaranya https://build.microsoft.com/ (Rabu 8:00 PST, 15:00 GMT dan Kam serupa?)

Kita mungkin tahu lebih banyak; mungkin tidak. Hal-hal mungkin lebih jelas, mungkin tidak. Namun, tim ASP.NET kemungkinan akan dapat merespons sedikit lebih baik dan lebih fokus pada kekhawatiran semua orang. Padahal @davidfowl telah melakukan dengan gagah berani!

@stefanolson Tapi sebaliknya mereka hanya meninggalkan standar membuat standar tidak berguna (jika saya memahami situasi yang membingungkan ini dengan benar)

Saya pikir inti dari .NET Standard adalah kompatibilitas. Penulis perpustakaan dapat menargetkan .NET Standard dan kemudian siapa saja dapat menggunakannya, apakah mereka menggunakan .NET Framework, .NET Core, atau sesuatu yang mendukung .NET Standard.

Saya pikir inti dari .NET Core adalah membayangkan ulang .NET Framework. .NET Core bersifat lintas platform, berkinerja tinggi, open source, dan berkembang pesat.

Mengubah implementasi string ke utf8 secara default sangat besar dan bukan sesuatu yang Anda harapkan untuk dilihat di .NET Framework.

Setelah membaca utas ini, saya merasa:
.NET Core -> .NET Framework seperti ASP.NET MVC -> WebForms.

Saya ingin mengunggulkan aspek perkakas juga. Kinerja restore/build/test dll saat ini sangat buruk dan sangat merepotkan. Jika kita harus "tetap pada 1.0" apakah kita masih dapat menggunakan SDK yang lebih baru dengan (semoga) kinerja yang lebih baik atau akankah kita terjebak dengan SDK 1.x?

Kisah .NET Core adalah tur luar biasa yang penuh dengan suka dan duka. Kami baru saja mulai bekerja di ASP.NET Core karena semua "fuck up" sebelumnya (versi, penamaan, project.json - .csproj transisi) dan saya (dan saya) menantikan .netstandard 2.0, karena saya pikir ini akan menjadi rilis "nyata" pertama.

Saya mengerti bahwa ASP.NET Core 1.1 masih didukung dan akan berjalan 10 tahun ke depan, tetapi kalian sangat berani untuk bergerak __that__ dengan cepat dan memotong salah satu nilai jual ASP.NET Core sebelumnya.

Jika Anda ingin tahu apa itu pemblokir (selain layanan direktori) dari pihak kami: Kami masih menggunakan EF6 dan masih menunggu paket Open XML SDK NuGet resmi yang menargetkan netstandardwhatever.
Memigrasikan kode mungkin membutuhkan waktu yang sangat lama...

Apakah mungkin untuk memformalkan semacam proses untuk mendorong maju netstandardXX berdasarkan perubahan yang terjadi di Core yang melibatkan penargetan sebagai bagian dari fase pemeliharaan rilis perpustakaan Asp.Net Core?

Seperti berdiri, saya memiliki aplikasi WebForms/MVC yang akan kami tarik pemicu untuk mengekspos api web ANC ke dan panggilan dari SPA (dan akhirnya dari aplikasi warisan WebForms), tetapi kami tidak dapat mengembangkan di CoreCLR karena ketergantungan pada Sybase (sekarang SAP) Ase ADO.NET driver (jika seseorang yang membaca ini dapat menekan tombol di suatu tempat di SAP ... Sayangnya saya tidak dapat mendengar sama sekali tentang ini atau pada bug yang telah saya ketahui selama ini 9 tahun sekarang).

Membaca masalah ini, saya tidak begitu yakin lagi apa jalan saya seharusnya. Satu-satunya hal yang saya yakin dapat saya rencanakan adalah driver buggy akan terus ada untuk kerangka kerja desktop. Apakah saya harus mengabaikan perubahan pada ASP.NET selama beberapa tahun terakhir karena itu akan membuang-buang waktu saya dan saya harus menargetkan WebApi2? Apakah saya harus mengatakan lanjutkan dengan ANC 1.x dengan pengetahuan bahwa saya mungkin tidak akan pernah bermigrasi dan melihat manfaat 2.x dalam aplikasi yang saya yakini akan didukung di sini selama 10-15 tahun ke depan (aplikasi WebForms memiliki telah dimigrasi dan dipelihara sejak kerangka 1.1 dirilis)?

@davidfowl

Span sendiri memiliki versi portabel yang dapat dijalankan di mana saja, saya tidak yakin implementasinya akan secepat ini
di .NET Framework. API yang akan ditambahkan ke .NET Framework yang memanfaatkan Span mungkin membutuhkan waktu lebih lama daripada Span itu sendiri, ekstensif. Kapan terakhir kali kami mengubah string dan array di .NET
Kerangka?

Tunggu apa?

Tidak semua dari kita adalah pengembang web. Kami telah menantikan dukungan penanganan string yang lebih baik selama bertahun-tahun dan sekarang tiba-tiba Anda memberi tahu kami bahwa kami SOL? Bahwa .NET Framework dan aplikasi non-web yang tak terhitung jumlahnya yang dibangun di atasnya tidak akan pernah mendapatkan akses ke pustaka penanganan string berdasarkan Span?

Ini bukan lagi hanya masalah ASP.NET. Ini menjadi inti dari komitmen jangka panjang Microsoft untuk .NET Framework dan perpustakaan kelas dasarnya.

Anda tahu, saya benar-benar harus memberikannya kepada orang-orang seperti @davidfowl untuk terus menanggapi semua orang dan semua orang yang berkontribusi pada diskusi ini. Saya memiliki banyak hal untuk dikejar dari awal hari ini, tetapi saya merasa seolah-olah saya belajar banyak melalui setiap komentar dalam hal apa yang semua orang gunakan/harapkan untuk menggunakan .NET.

Saya pikir kita pada akhirnya akan mendapatkan beberapa jalan yang diluruskan dengan bantuan semua orang dan saya berharap semua pihak dipertimbangkan.

Saya tidak sabar menunggu pengumuman resminya

Jika saya memahaminya dengan benar, net coreapp 2.0 akan menyediakan shim kompatibilitas yang memungkinkan proyek ASP.NET Core 2.0 kami bergantung pada pustaka kelas NetFx lawas kami (mis., net461).
Di mana saya dapat menemukan informasi lebih lanjut tentang kemampuan/keterbatasan yang saat ini direncanakan dari compat shim tersebut?

@dgaspar Itu tidak terlalu akurat, begini cara kerjanya: netcoreapp2.0 mendukung sebagian besar API di net461 . Jika perpustakaan Anda dibuat untuk net461 dan hanya memanggil API yang ada di dalam subset yang didukung oleh netcoreapp2.0 , maka Anda tetap dapat mengimpor perpustakaan (anggap itu sebagai penggantian, yang Anda tahu lebih baik) dan membuatnya berjalan, karena semua kelas dan metode yang dipanggilnya harus ada di sana.

Sekarang ada juga kelemahannya: jika metode tidak ada atau tidak sepenuhnya didukung dalam beberapa cara, Anda mendapatkan kesalahan runtime untuk metode yang hilang, dll. Jadi pemeriksaan waktu kompilasi bukanlah jaminan yang baik di sana. Ini sedikit pedang bermata dua yang harus diperhatikan, tetapi ada untuk beberapa perpustakaan yang tidak akan pernah diperbarui namun baik-baik saja dengan set API yang mereka panggil.

@NickCraver ada yang ingat...

"imports": [ "dnxcore50", "portable-net45+win8" ]

Komentar terkait yang saya buat pada bulan Desember. 11 jempol dibawa ke depan:

Ada yang tidak beres di sini. Saya telah mengirimkan aplikasi C# selama 15 tahun. Ironisnya karena abstraksi tingkat yang lebih tinggi dikirimkan oleh Microsoft, saya menghabiskan lebih banyak waktu untuk menggali lebih dalam ke internal yang sebelumnya tidak pernah saya khawatirkan. KAMU MELAKUKANNYA DENGAN SALAH.

Jika saya ingin dikejutkan saat runtime oleh perpustakaan acak dan kesalahan yang disebabkan oleh manajemen paket yang tidak ditangkap oleh kompiler, saya akan menulis aplikasi saya di Ruby.

bahkan node.js memungkinkan kita untuk memanggil semua library netfx dengan mudah.

kode mvc benar-benar bagian yang mudah. mungkin perlu beberapa minggu untuk menulis ulang di node.js atau nancy, tetapi akan memakan waktu lebih lama untuk mem-porting kode bisnis dan algoritme, dan membuktikannya berfungsi sekokoh yang lama. belum lagi kasus ketika kita tidak memiliki sumbernya.

ambil contoh RyuJit, bahkan setelah rilis ke produksi, pemblokiran bug utama ditemukan dan butuh satu tahun lagi untuk menyelesaikannya sepenuhnya. sama untuk perangkat lunak kami, yang bukan toko hewan peliharaan tetapi alat industri yang membantu menghasilkan jutaan dolar sehari.

kerangka kerja UI berubah dengan cepat, dari winform ke web. tetapi logika/algoritma bisnis inti jauh lebih stabil dan berumur panjang. jadi, untuk menggunakan kerangka UI baru yang mengkilap, kita perlu menulis ulang/menguji ulang atau mengabaikan kode bisnis/algoritma kita? tidak, kami tahu yang baru mengkilap akan digantikan oleh sesuatu yang lebih trendi dalam 5 tahun, tetapi kode bisnis/algoritma kami akan terus digunakan.

@qmfrederik

Sebagai renungan, apa yang benar-benar mengejutkan saya adalah bahwa perubahan ini dilakukan sekarang, beberapa hari sebelum rilis pratinjau. Tampaknya menunjukkan bahwa belum ada alasan teknis untuk melakukannya - jadi mengapa tidak membuat perubahan di ASP.NET Core v3?

Kami melakukan dukungan HTTP2 selanjutnya dan itu membutuhkan API baru.

Saya ingin mengunggulkan aspek perkakas juga. Kinerja restore/build/test dll saat ini sangat buruk dan sangat merepotkan. Jika kita harus "tetap pada 1.0" apakah kita masih dapat menggunakan SDK yang lebih baru dengan (semoga) kinerja yang lebih baik atau akankah kita terjebak dengan SDK 1.x?

Ya, itu akan berhasil.

@davidfowl

Kami sedang melakukan dukungan HTTP2 berikutnya dan membutuhkan API baru.<

Jadi jenis dukungan HTTP2 yang akan tersedia di asp.net core 2.0 tidak akan tersedia di 1.x? Ini benar-benar jenis masalah yang saya khawatirkan di mana kita tidak akan memiliki akses ke teknologi terbaru karena kita terikat pada kerangka .net lengkap untuk alasan apa pun. Seperti yang saya katakan di atas, tidak masalah jika perlu enam bulan hingga satu tahun untuk menyaring apa pun yang saya gunakan, tetapi pada akhirnya tidak ingin terlalu jauh tertinggal. Karena berbagi kode dan penggunaan perpustakaan pihak ketiga pada tahap ini, saya memerlukan kerangka kerja .net lengkap.

akhirnya, saya mengklarifikasi beberapa hal:

• ketika saya mengatakan modul lama, itu adalah dll tergantung pada netfx atau c++/cli dll, yang pada gilirannya dapat memanggil beberapa dll asli. mereka untuk bisnis/algoritma, tidak ada COM, tidak ada asp.net. mereka tidak buruk. mereka menjadi warisan terutama karena .net core tidak menjalankannya.
• adalah mungkin untuk bermigrasi ke net core dalam jangka panjang, dan kami sangat menginginkannya. tetapi sangat sulit untuk mendorong itu terjadi. Ini akan memakan waktu beberapa tahun bagi kami dan pihak ke-3 untuk berada di sana.
• perpustakaan khusus domain jauh lebih lambat daripada perpustakaan umum untuk perubahan tumpukan teknologi. kita semua tahu contoh python 3. perpustakaan khusus domain itu adalah bisnis nyata.

@danielcrabtree

Saya pikir inti dari .NET Core adalah membayangkan ulang .NET Framework. .NET Core bersifat lintas platform, berkinerja tinggi, open source, dan berkembang pesat.<

Yang fantastis. Tantangannya adalah bagaimana menangani basis kode yang ada dan bagaimana kita membuatnya dapat digunakan dengan .net core. Jika WPF tersedia dibangun di .net core maka saya bisa menggunakan .net core di mana-mana. Tetapi karena tidak dan kode saya dibagikan antara WPF dan ASP.net, saya memerlukan cara untuk membagikannya. Tapi saya tidak ingin terlalu ketinggalan dengan teknologi web terbaru dan teknik keamanan sebagian besar (semua?) yang sepertinya hanya akan ada di 2.x dan yang lebih baru

Beberapa kali di utas ini dan dalam dokumentasi di tempat lain .NET Core digambarkan sebagai lintas platform. Ini diiklankan sebagai salah satu nilai jual utama untuk pindah ke platform.

Namun hal ini tampaknya tidak terjadi seperti yang diklarifikasi dalam percakapan ini di Twitter

https://twitter.com/James_M_South/status/861595907782987776

Dan komentar di atas; penekanan milikku.

Kesenjangan besar yang tersisa yang hilang di .NET Core 2 adalah System.DirectoryServices dan System.Drawing. Kami sedang bekerja untuk memiliki paket kompat Windows yang akan mengaktifkan keduanya di .NET Core di Windows musim panas ini.

Saya telah bekerja sangat keras dengan .NET Core sejak awal mencoba mengisi celah yang ditinggalkan oleh System.Drawing dengan ImageSharp dan sekarang saya menjadi sangat bingung dan lebih dari sedikit tidak puas dan bertanya:

Apa itu .NET Core sekarang?

Berikut deskripsi dari MS Docs .

.NET Core adalah platform pengembangan tujuan umum yang dikelola oleh Microsoft dan komunitas .NET di GitHub. Ini adalah lintas platform, mendukung Windows, macOS dan Linux, dan dapat digunakan dalam skenario perangkat, cloud, dan tertanam/IoT.

Ada pernyataan lintas platform itu lagi. Apakah itu atau bukan? Saya pikir mencoba untuk menjelaskan hal ini menyebabkan banyak kebingungan di komunitas pengembangan.

Setiap deskripsi yang saya baca tampaknya berbeda.

Bisakah kita:

1. Harap tuliskan pesan yang layak, konsisten, di suatu tempat sehingga kami benar-benar dapat memiliki target untuk dituju dan pemahaman keseluruhan yang lebih baik.
2. Dapatkan kejelasan yang disampaikan pada peta jalan sebenarnya untuk System.DirectoryServices , dan System.Drawing

System.Drawing khususnya membingungkan dan mengkhawatirkan. Saya tidak dapat memahami mengapa Anda ingin mem-porting API itu ke .NET Core di platform apa pun. Sulit untuk bekerja dengannya, tidak didukung di server, dan tidak memiliki banyak fitur penting yang diperlukan untuk pengembangan modern (Multi threading, Format Piksel, ICC, EXIF, Quantization, Indexed Png, dan sebagainya).

Ada banyak nama dan wajah yang dapat dikenali di sini, dan saya tahu saya hanya menambahkan beberapa kebisingan di sini, tetapi:

• Layanan Direktori
• Menggambar (bukan karena saya membutuhkannya)
• EF

Ini sepertinya tiga hal paling penting yang harus dilakukan sebelum membuat terobosan besar. Secara pribadi, hampir semua yang saya kerjakan ada di net4x semata-mata karena EF6, karena EFCore... yah... :trollface:

@stefanolson
Saya pikir Anda diharapkan untuk memisahkan kode bersama ke dalam perpustakaan .NET Standard. Kemudian akan dapat digunakan dari WPF dan ASP.NET di .NET Framework dan dari ASP.NET di .NET Core dan aplikasi .NET Core lainnya.

@JimBobSquarePants
Saya tidak berpikir paket kompat Windows adalah bagian dari .NET Core. Ini adalah perpustakaan khusus Windows yang berada di atas .NET Core. Anda bisa membayangkan ada perpustakaan khusus Linux yang mengekspos fitur khusus Linux.

Saya pikir paket compat Windows adalah tentang membuatnya lebih mudah untuk memigrasi basis kode .NET Framework yang ada. Jelas, setelah seseorang beralih ke .NET Core, mereka kemudian harus melihat migrasi ke solusi yang lebih baik seperti ImageSharp.

@stefanolson
Mungkin mereka bahkan dapat membuat paket WPF khusus Windows yang memungkinkan Anda membuat aplikasi WPF di .NET Core, tetapi yang hanya akan berjalan di Windows.

Masalah GitHub ini telah disebutkan di situs berita IT Jerman:
https://www.golem.de/news/asp-net-core-2-0-microsoft-veraergert-net-entwickler-mit-support-entscheidung-1705-127712.html

Terima kasih @danielcrabtree itu yang pertama saya dengar tentang paket kompatibilitas apa pun.

Terjemahan untuk tautan @MJomaa : https://translate.google.com/translate?u=https%3A%2F%2Fwww.golem.de%2Fnews%2Fasp-net-core-2-0-microsoft-veraergert- net-entwickler-mit-support-entscheidung-1705-127712.htm

Saya menunggu System.Xaml untuk di-porting.

@alexwiese jangan menahan nafas.

Saya menunggu System.Xaml untuk di-porting.

Lanjutkan; Aku akan menggigit. Bagaimana Anda menggunakan Xaml di situs web Anda?

Lanjutkan; Aku akan menggigit. Bagaimana Anda menggunakan Xmal di situs web Anda?

UI lintas platform (templat layar yang dibagikan antara aplikasi konsol "layar hijau", aplikasi Xamarin, dan Angular SPA), juga digunakan untuk mesin aturan bisnis.

Wow, ok jadi Anda mengubah XML XAML dalam beberapa cara menjadi HTML dan Javascript? Cukup adil

Tidak yakin jika Anda hanya trolling.

Saya melakukan hal yang sama, tetapi secara realistis saya tidak melihat mereka mem-porting XAML, mengingat pada titik ini tidak dapat diuraikan tanpa juga dieksekusi.

Wow, ok jadi Anda mengubah XML XAML dalam beberapa cara menjadi HTML dan Javascript? Cukup adil

Tentu saja tidak; Saya mengonversi ke JSON terlebih dahulu

Artikel berita lain tentang topik ini dengan banyak dari kami dikutip: https://www.infoq.com/news/2017/05/ASPNET-Core-2

@cwe1ss Penulisnya adalah @Grauenwolf

@alexwiese @yaakov-h Saya ingin membaca posting blog tentang itu; terdengar cukup menarik dan harus datang dengan serangkaian tantangan yang berbeda dari biasanya.

Ini benar-benar buruk. ASP.NET Core adalah penjualan yang masuk akal ketika Anda dapat memanfaatkan perpustakaan lawas saat dibutuhkan. Jika hal itu dapat dilakukan dengan hal-hal baru, atur beberapa hal dan targetkan .NET Core. Jika tidak, cukup targetkan kerangka kerja lengkap.

Dengan perubahan ini, ini adalah lompatan semua atau tidak sama sekali. Dan mengingat bahwa Anda tidak selalu memahami semua dependensi di awal, itu memperbesar risikonya.

Saya memahami keinginan untuk bergerak cepat, dan berevolusi ke tempat yang pasti, tetapi Anda akan meninggalkan pengguna Anda. Orang cenderung bermigrasi, bukan melompat. Sejumlah besar tidak akan keluar dari arus. Dan kemudian ketika mereka melakukannya, mereka mungkin pindah ke platform yang sama sekali berbeda. Serius, Anda meremehkan risiko itu.

Ini adalah langkah yang pada akhirnya harus dilakukan, tetapi lebih seperti akhir 2019, atau paling cepat 2020. Meski begitu, Anda masih menginginkan model jangka panjang untuk mendukung mereka yang telah memilih untuk mencampuradukkan berbagai hal.

Dan tidak, ASP.NET Core 1.x bukanlah jawaban di sana. Ketidakdewasaannya baik-baik saja sebagai fase transisi dengan jalur migrasi yang mudah ke depan, tetapi tidak cocok untuk hidup bersama dalam jangka panjang. Ada perbedaan besar antara pola pikir mereka yang mengembangkan platform seperti ini, dan mereka yang menggunakannya. Harap pertimbangkan kembali arah ini.

@davidfowl Bagaimana dengan sesuatu seperti edge.js untuk netcore? Itu membuat konsumen API bertanggung jawab atas pemeriksaan platform dan antarmuka yang diketik dengan kuat antara netfx dan netcore sudah cukup untuk sebagian besar skenario.

Apakah template ini akan dihapus?

Itu dimasukkan ke dalam VS2017 saat ini.

omong kosong yang benar-benar tidak dapat diterima, sekali lagi ini membuktikan bahwa itu adalah teknologi mainan yang belum siap untuk prime time dan diadopsi secara luas.

Saya sangat menghargai teman-teman Anda memiliki pengalaman berkendara dan pengkodean yang menyenangkan, Anda dapat bersinar di entri blog dan twitter Anda (hore!), Perbaiki profil dan cv linkedin Anda (hore^2), semua pesta rilis di depan Anda, cewek, minuman dan hal-hal terlihat menjanjikan, tapi .. siapa yang akan menggunakannya? apakah Anda menargetkan perusahaan dan menginginkan adopsi yang besar dan basis pengguna yang solid? atau hanya hippie pemula?!?

Komentar tentang "Rentang penuh" yang berpotensi tidak pernah masuk ke .NET Framework sangat mengkhawatirkan bagi saya. Jika Rentang penuh tidak ada dalam .NET Framework maka saya menganggap API yang menggunakannya tidak akan pernah bisa membuatnya menjadi standar bersih masa depan, yang membuatnya tidak mungkin untuk menulis pustaka lintas platform yang menggunakan atau mengekspos penguraian kinerja tinggi? Yang berarti kita terjebak dengan implementasi kustom yang tidak aman secara efektif secara permanen...

Anda menyebutkan bahwa jika Anda ingin perpustakaan Anda menjadi lintas platform maka Anda harus menargetkan standar bersih, tetapi apa itu ASP.NET Core jika bukan perpustakaan yang banyak digunakan? Apakah Anda merekomendasikan perpustakaan lain mulai menjatuhkan dukungan untuk netstandard dan beralih ke .NET Core? Haruskah versi utama JSON.NET berikutnya atau apa pun menjatuhkan netstandard? Itu pasti bisa dilakukan dengan penguraian cepat!

Catatan Java berhasil menambahkan IO cepat dengan nol menyalin dll dengan cara yang kompatibel dengan Netty (https://netty.io/)

Akhirnya saya ingin mengucapkan terima kasih kepada orang-orang yang bersedia berkeliaran dan menjawab ini. Kami sangat menghargai jawaban...

@shanselman Bergerak cepat adalah tujuan mulia, terutama bagi tim yang berupaya keras untuk kompatibilitas dan merancang berbagai hal dengan cara yang kompatibel, seperti Tim ASP.Net. Saya tahu betapa mereka ingin menyederhanakan domain masalah mereka, dan saya mendukungnya, tapi ...

Bergerak cepat dan pada saat yang sama "juga jauh" dari pelanggan Anda juga bukan hal yang baik. Anda tahu, pelanggan Anda (termasuk saya) memiliki perangkat lunak lama yang serius dan investasi waktu ke dalam aplikasi dan perpustakaan yang ada. Anda tidak bisa begitu saja meninggalkan kami dan pergi ke tempat yang tidak akan/tidak bisa kami ikuti.

Anda harus mempertimbangkan pelanggan Anda yang tidak dapat mengakses .Net core dan harus menggunakan Full Framework setidaknya untuk beberapa waktu lagi dari sekarang. Jika Anda pindah dari Full Framework, Anda meninggalkan banyak orang terdampar di versi yang lebih lama dan membuat perpecahan besar di dunia .Net.

@JimBobSquarePants Saya mendukung Anda di bagian System.Drawing . Ada beberapa diskusi di repo lain tentang mengembalikan System.Drawing . Berdasarkan beberapa komentar di utas ini, saya mengerti akan ada "paket compat" di Windows terlebih dahulu dan kemudian di semua OS untuk System.Drawing .

Saya ingin tahu seperti apa bentuknya, dan apakah itu akan didasarkan pada libgdiplus Mono atau tidak (yang akan menghilangkan beberapa kekhawatiran yang Anda miliki dengan System.Drawing, tapi itu cerita lain)

Oke, menurut saya, ada beberapa masalah yang dipertaruhkan:

1. Ini dikomunikasikan dengan agak buruk.
2. Orang-orang tidak terlibat dalam keputusan itu. Perhatikan bahwa Microsoft tentu saja bebas memilih arah yang mereka suka, tetapi tidak membahas jenis perubahan besar ini dengan komunitas tidak dalam semangat pengembangan sumber terbuka.
3. Tidak ada "skema besar" yang dapat digunakan masyarakat untuk memeriksa jenis keputusan ini. Pada awalnya, .NET Core adalah versi kerangka lengkap lintas platform yang dipangkas. Kemudian, dengan .NET Standard 2.0, tampak bagi banyak orang bahwa .NET Core 2 akan seperti pengganti kerangka kerja lengkap, tentu saja dalam batas yang wajar (tidak ada UWP, WinForms, dll.).
4. .NET Core 2 akan kehilangan beberapa fungsi penting yang ada dalam kerangka kerja penuh, seperti System.DirectoryServices. Sejauh yang saya tahu, ini telah diakui, tetapi mungkin jalan untuk menambahkan fitur-fitur ini ke .NET Core dapat dibuat lebih eksplisit.
5. ASP.NET Core 2 tidak akan berjalan pada kerangka kerja penuh karena kerangka kerja penuh kehilangan fitur-fitur baru. Aku sebenarnya baik-baik saja dengan ini. Jika menambahkan fitur yang hilang ke kerangka kerja penuh terlalu sulit, maka jangan lakukan. Memiliki ASP.NET Core 2 hanya berjalan di .NET Core 2 sebenarnya cukup masuk akal, meskipun menyebutkan mereka sebagai satu produk mungkin bukan cara terbaik untuk menggambarkan hubungan mereka.

Apa yang saya pikir orang benar-benar ingin lihat adalah deskripsi visi platform .NET. Ke arah mana hal-hal akan masuk? Akankah kerangka kerja lengkap hanya menerima perbaikan bug dan semacamnya tetapi tidak ada fitur baru? Apa yang sedang dilakukan untuk menambahkan fitur yang hilang ke .NET Core dan kapan kami dapat mengharapkannya? Dengan menjelaskan hal ini, mudah-mudahan akan sangat membantu dalam mengurangi kecemasan yang dirasakan orang-orang sekarang.

@davidfowl Saya kira ini bukan hanya tentang HTTP 2.0; jika ini benar-benar tentang HTTP 2.0, tidak bisakah Anda memiliki NetFX target ASP.NET Core 2.0 dengan pengecualian dukungan HTTP 2.0? Bahkan mungkin model pluggable sehingga komunitas dapat melakukan HTTP 2.0 di NetFX jika mereka benar-benar menginginkannya?

@cokkiy @popcatalin81 @xprzemekw Jika Anda tidak memiliki sesuatu yang konstruktif untuk dikatakan, jangan berkomentar, komentar semacam ini tidak membantu siapa pun.

Ada alasan yang sah mengapa melakukan langkah yang dijelaskan oleh @davidfowl https://github.com/aspnet/Home/issues/2022#issuecomment -300141134

Alasan mengapa menundanya termasuk (katakanlah asp.net core 3.0):

• EF Core belum siap untuk menggantikan EF 6.0 karena banyak fitur yang hilang
• tidak ada produksi yang siap System.Drawing penggantian
• tidak System.DirectoryServices
• ada penyebutan office xml sdk , tetapi tampaknya sudah tersedia di netstandard pada 05-01 2017 https://www.nuget.org/packages/DocumentFormat.OpenXml/
• paket lain di luar lingkup MS tidak tersedia di .net core (nhibernate, berbagai penyedia db, ikvm)

Alasan mengapa tidak pernah termasuk:

• Orang-orang mem-porting aplikasi ke asp.net core dengan dependensi lama tanpa niat untuk pindah ke .net core.
• Khawatir tentang meninggalkan standar bersih dan tidak terlalu mempedulikannya.
• Beberapa paket pihak ke-3 tidak mungkin pernah di-porting ke .net core (yang bisa dibilang membuatnya usang, tapi itu mungkin hanya pendapat saya)

Contoh komentar yang membangun akan menambahkan alasan Anda mengapa Anda ingin melihat salah satu dari tiga skenario ini atau menyarankan solusi alternatif. Jika Anda hanya ingin menyatakan setuju/tidak setuju gunakan tombol "Reaksi".

@Kukkimonsuta

Orang-orang mem-porting aplikasi ke asp.net core dengan dependensi lama tanpa niat untuk pindah ke .net core.

Sangat setuju. Karena Microsoft telah mengumumkan bahwa ASP.NET Core akan bekerja pada framework .net core dan .net. Dan sekarang meninggalkan mereka di AspNet Core 1.x tidak adil.

Ringkasan terakhir cukup bagus. Saya hanya ingin menambahkan satu atau dua hal:

1.) Seharusnya mungkin untuk menulis Layanan Windows dengan .NET Core (Saya tahu bahwa daemon pada platform *NIX bekerja secara berbeda). Jadi ServiceBase akan tetap dibutuhkan, dan ini adalah prioritas tinggi bersama dengan EF.

2.) Lebih jauh lagi, masih mungkin untuk menulis layanan mandiri dengan .NET Core, dan juga menghostingnya di dalam aplikasi .NET berbasis kerangka penuh yang ada (yaitu layanan gratis dari aplikasi Windows Forms/WPF Anda) untuk memperluasnya.

Yang terakhir ini benar-benar diperlukan untuk skenario migrasi lambat, di mana tidak mungkin untuk membuat jalan pintas dan memulai greenfield.

Sangat setuju. Karena Microsoft telah mengumumkan bahwa ASP.NET Core akan bekerja pada framework .net core dan .net. Dan sekarang meninggalkan mereka di AspNet Core 1.x tidak adil.

Saya juga ingin menekankan lagi bahwa perubahan besar kembali ke .csproj dan msbuild terutama dimaafkan dengan fakta bahwa tidak mungkin untuk merujuk (ASP). Proyek Inti NET dari proyek .NET (kerangka kerja penuh) Anda yang ada.

Perubahan ini membuat yang terakhir tidak mungkin (setidaknya untuk bagian ASP.NET terbesar). Jadi mengapa kompatibilitas sangat penting saat itu (dan menyebabkan banyak rasa sakit), tetapi tidak sekarang (dan sekali lagi menyebabkan banyak rasa sakit)?

maaf saya harus stres juga. Tapi hampir 500 komentar, saya percaya jika saya terlibat sebagai orang microsoft untuk masalah ini saya punya dua pilihan:
1: bisukan masalah ini
2: memikirkan kembali keputusan saya

@gingters Perubahan csproj terutama untuk _.net_ core, agar xamarin, asp.net, uwp dan yang lainnya dapat berbagi kode dan juga merujuk jenis proyek lain seperti kode asli.

Juga, ini memungkinkan proyek asp.net core 2 untuk merujuk proyek kerangka kerja lengkap, sekali lagi, melalui compat shim

@qmfrederik

Bahkan mungkin model pluggable sehingga komunitas dapat melakukan HTTP 2.0 di NetFX jika mereka benar-benar menginginkannya?

Mereka secara teknis bisa. Tapi sepertinya mereka tidak mau. Bagi saya rasanya mereka hanya tidak ingin memikirkan kebutuhan nyata perusahaan / bisnis besar, atau tentang kompatibilitas ke belakang atau kebutuhan untuk mengatasi hal lain selain hal-hal lapangan hijau.

Dan sejujurnya, manajemen ekspektasi di masa lalu sepenuhnya menargetkan bisnis yang ingin secara perlahan memperluas / memigrasikan barang-barang mereka ke lintas platform, sementara juga dapat secara perlahan memperluas / memigrasikan aplikasi mereka yang sudah ada. Jadi langkah ini sama sekali tidak selaras dengan manajemen ekspektasi sebelumnya.

@aL3891

agar xamarin, asp.net, uwp dan yang lainnya dapat berbagi kode

Ya. Tepat. Dan itu juga termasuk aplikasi WPF/Windows Forms untuk menggunakan pustaka .NET Core, yang sekarang tidak mungkin dilakukan ketika Anda ingin melanjutkan ke .NET Core 2.

Bisakah seseorang menjelaskan dengan tepat mengapa perpustakaan ini tidak dapat menargetkan netstandard2.0 ?

Sampai sekarang, saya telah menganggap netcoreapp sebagai moniker untuk executable lintas platform (hanya digunakan dalam proyek executable csproj), tetapi saya tidak pernah menganggapnya sebagai platform, sekarang, itu harus dianggap sebagai platform nyata? Mengapa mengapa mengapa, dan bagaimana kita sampai pada pilihan yang tidak masuk akal ini?