Aspnetcore: Rakitan dihapus dari Microsoft.AspNetCore.App 3.0

Saya pikir paket MVC harus menjadi paket NuGet tambahan juga. MVC sangat bagus, tetapi tidak seperti vanilla ASP.NET Core, sangat disarankan bagaimana aplikasi kita harus ditata yang sebenarnya tidak disukai semua orang, apalagi cocok dengan paradigma semua bahasa .NET. Saya benar-benar percaya kerangka ASP.NET Core yang dibagikan layak untuk bebas MVC atau memiliki versi gratis MVC kedua. Bagaimana menurutmu?

Apa manfaatnya? Bagaimana ini membuat kehidupan orang-orang yang membangun aplikasi ASP.NET Core lebih baik?

Besar! Saya hanya membutuhkan apa yang saya butuhkan ketika saya menggunakan asp.net core.

@davidfowl

Apa manfaatnya? Bagaimana ini membuat kehidupan orang-orang yang membangun aplikasi ASP.NET Core lebih baik?

Untuk alasan yang sama mengapa Anda tidak menyertakan paket yang tercantum di atas masalah ini. Saya hanya berpikir bahwa selalu lebih mudah untuk menambahkan lebih banyak paket ke dalam kerangka kerja yang akan dikirimkan dengan .NET Core 3.0 daripada menghapus paket di kemudian hari. Mengapa Anda tidak mulai menambahkan penyebut umum terkecil untuk menjalankan aplikasi Vanilla ASP.NET Core dan kemudian menawarkan sisanya sebagai paket NuGet. Jika ini ternyata menjadi masalah bagi pengembang maka Anda selalu dapat menambahkan lebih banyak barang nanti, tetapi Anda tidak akan dapat menghapus barang lagi nanti dengan mudah.

Karena kita harus mencapai keseimbangan dengan menjadi berguna secara default juga.

Ok, saya pikir vanilla ASP.NET Core sudah berguna (dan saya pikir Anda juga berpikir begitu, jika tidak, mengapa Anda tidak membuatnya berguna?), tetapi jika Anda sudah menetapkan pikiran tentang apa yang seharusnya ada dalam kerangka kerja dan apa yang tidak maka tidak apa-apa ;)

Jika Anda seorang purist, Anda tidak akan memiliki sebagian besar middleware atau MVC atau SignalR di dalam kotak karena mereka tidak sepenuhnya diperlukan. Menggambar garis ini antara apa yang seharusnya menjadi dan tidak set default adalah cukup banyak firasat dan hal yang kabur (berdasarkan pengalaman, melihat platform lain dulu dan sekarang dan membuat panggilan). Pada ASP.NET Core 3.0 kami tidak memiliki rencana untuk mencabutnya (setidaknya saat ini).

Ya saya tahu ini selalu merupakan panggilan yang sulit untuk dilakukan, tetapi saya terkadang tidak yakin apa pembenaran untuk kecenderungan (oleh Microsoft) untuk mengasapi hal-hal lebih dari yang diperlukan. Cara bagaimana Anda memposisikan produk Anda sendiri di pasar adalah bagaimana hal itu akan dirasakan. ASP.NET Core seharusnya menjadi kerangka kerja web modern yang dapat dikomposisi dan fleksibel, tetapi cara Anda memposisikan semuanya adalah bahwa ASP.NET Core tidak berguna kecuali Anda memaksa MVC + SignalR + Identity + EF ke semua orang. Menurut pendapat saya, Anda telah membuat panggilan di mana garis harus ditarik, itu sebabnya MVC dan SignalR tidak tertanam di ASP.NET Core tetapi kerangka kerja terpisah yang dapat ditambahkan bila diinginkan, jadi mengapa Anda mengaburkan garis-garis ini sekarang? Rasanya tidak konsisten dan saya tidak bisa memikirkan nilai apa pun yang Anda dapatkan darinya. Alih-alih hanya mempromosikan ASP.NET Core + sistem ramah lingkungan open source yang berkembang, Anda mempromosikan pengalaman web yang sangat sempit. Yang dilakukannya hanyalah membuat frustrasi dengan mereka yang ingin sedikit berbeda dan lebih banyak bekerja untuk diri sendiri saat Anda akhirnya mendorong hal-hal pada orang yang mungkin tidak mereka inginkan.

Ini tidak seperti orang tidak akan menggunakan MVC jika Anda tidak memasukkannya ke dalam kerangka kerja default. Jadikan satu paket NuGet dan tidak ada yang akan mengeluh bahwa mereka harus mendapatkan MVC dari NuGet. Kemungkinan besar lebih banyak orang akan datang dan bertanya mengapa Anda membengkakkan kerangka kerja default dengan hal-hal yang tidak mereka inginkan seperti saya.

Saya menganggap bahwa ini adalah diskusi dan masih sesuatu yang mungkin kalian pertimbangkan, jadi jika ada satu hal yang saya ingin Anda tanyakan adalah membawa pertanyaan ini dengan tim Anda mungkin lagi dan melihat apakah Anda benar-benar siap dengan ini atau jika Anda dapat melunak terhadap ide saya :)

PS: Tidak yakin apakah itu masalahnya, tetapi saya berharap SignalR juga merupakan paket NuGet yang terpisah. Ini seperti Anda akan memasukkan Bootstrap dan Angular2 ke dalam kerangka kerja default Anda. Jika kedua produk ini dikembangkan oleh Microsoft maka Anda mungkin akan melakukannya, tetapi itu tidak masuk akal dan saya pikir hanya karena dilakukan oleh pihak ketiga, Anda melihat bagaimana itu tidak masuk akal.

TBH Saya ingin melihat lebih banyak barang dihapus dari instalasi default. Terutama MVC. Inilah yang membuat Kerangka alternatif di atas ASP.NET Core semakin menarik. Saya juga bertanya-tanya mengapa hal-hal seperti ContentResult hidup di MVC dan tidak di inti. Ini banyak digunakan dalam fungsi Azure dan sekarang saya selalu harus merujuk hal-hal MVC - hanya untuk ContentResult.

Saya pikir intinya lebih bahwa itu seharusnya tidak berdampak negatif pada Anda untuk memiliki barang-barang MVC di ASPNET SDK. Sebagian besar pengembang akan menggunakannya sehingga pengiriman seperti itu lebih disukai daripada beban pemulihan yang membengkak. Jika Anda tidak menginginkannya, Anda tidak bisa menggunakannya. Sebagian besar paket yang tercantum di atas membawa dependensi pihak ke-3 (json), memiliki beberapa aspek berat (pisau cukur), atau secara konseptual terpisah dari ASPNET dan sering dirujuk di luar SDK (EFCore).

Sebanyak saya setuju dengan default ke minimum untuk mendorong lapangan bermain yang setara untuk kerangka kerja OSS, itu harus seimbang. Pada hari-hari awal inti (beta dan bahkan 1.0) hal-hal adalah paket di mana-mana dan itu JAUH lebih membingungkan dan pemulihan membutuhkan waktu lama.

@psibernetic bahkan jika barang ada dalam paket terpisah, penginstal inti .net dapat meletakkan paket-paket ini di cache lokal.

@psibernetic Anda adalah orang kedua yang menyebutkan bahwa keseimbangan itu penting, tetapi apa artinya itu? Keseimbangan antara apa? Jangan bicara ekstrem, karena itu jelas tidak baik, mari bicara proposal realistis di sini. Jika MVC adalah satu paket NuGet, bagaimana dampaknya terhadap kegunaan? Itu benar-benar tidak dan itulah poin saya. Berpikir bahwa Anda akan menyelesaikan satu ekstrem dengan menerapkan ekstrem yang berlawanan adalah pemikiran yang sempit. Ada banyak di antaranya. Kerangka kerja tidak harus membengkak dan MVC dan SignalR juga tidak harus dipecah menjadi 100 paket. Keduanya dapat dihindari secara bersamaan.

Beri saya satu kasus dunia nyata di mana memiliki MVC sebagai satu paket NuGet akan membingungkan, pemulihan akan memakan waktu lama, atau salah satu dari negatif lain yang telah Anda sebutkan?

Dan berbicara tentang waktu pemulihan ...

IMHO lebih penting untuk memiliki wadah awal yang cepat atau arsitektur tanpa server (karena itulah yang memiliki dampak dunia nyata pada bisnis) daripada memiliki pembangunan yang sedikit lebih cepat di mesin pengembang. Ya, yang terakhir juga sangat penting dan saya ingin itu menjadi sangat cepat, tetapi jika saya harus memberi peringkat kepentingannya maka saya lebih suka menerima pukulan kecil pada mesin dev saya daripada infrastruktur produksi saya di cloud. Jadi menjaga jejak sekecil mungkin hanya (jika tidak lebih) penting daripada menjaga waktu pemulihan tetap rendah.

Apa manfaatnya? Bagaimana ini membuat kehidupan orang-orang yang membangun aplikasi ASP.NET Core lebih baik?

Saya pikir ini adalah bloatware yang tidak diinginkan untuk semua pengguna lain yang tidak menggunakan MVC, seperti CandyCrush yang sudah diinstal sebelumnya di PC Windows 10 saya. Inti Asp.net diberitakan itu menjadi kurang berpendirian dengan sepenuhnya dapat dikonfigurasi, seperti yang diperlukan middleware dll dotnet template memungkinkan MVC untuk menjadi paket disertakan default tanpa perlu dimasukkan ke inti?

Ada banyak kerangka kerja lain di luar sana seperti Nancy, ServiceStack, dan Giraffe yang semuanya memiliki kelebihan dan tidak boleh memiliki kelebihan/konflik dengan pemasangan paksa MVC yang tidak diinginkan/tidak dibutuhkan. Sepertinya tidak konsisten mengingat otentikasi, pisau cukur, EF dll semuanya dikemas tetapi MVC, anak emas dapat menjadi bagian dari kerangka inti ketika itu bukan inti?

Jika karena MVC begitu erat digabungkan ke inti sehingga decoupling akan menjadi banyak pekerjaan, saya bisa mendapatkannya, tetapi atas dasar itu umumnya membuat beberapa dev hidup lebih mudah, tampaknya malas dan sangat mirip dengan asp.net lama Mentalitas MVC yang saya harap kita hindari.

.NET Core seharusnya menjadi klon modular ramping dari node.js untuk .NET tetapi tampaknya tidak memiliki niat untuk mereplikasi karakteristik yang mendorong ekosistemnya yang berkembang dan dinamis - inti kecil yang fleksibel dengan fitur yang disertakan pada intinya menguntungkan semua itu berkat tidak dibundel dengan kerangka web berpendirian apa pun, matang dengan eksperimen menikmati sejumlah kerangka kerja populer yang sehat dengan komunitas independen mereka sendiri.

Maksud saya, saya membuat tim ASP.NET percaya bahwa mereka sedang membangun kerangka kerja terbaik yang mereka bisa, tetapi tidak semua orang setuju dengan semua pendapat yang dipilih atau tingkat kerumitan yang diperlukan untuk menyelesaikan sesuatu. Segala sesuatu di .NET Core dikembangkan dengan manfaat dari tinjauan ke belakang dengan banyak terinspirasi oleh pendekatan apa yang terlihat berhasil di platform lain, dengan memberikan pendapat tentang teknologi apa yang digunakan Anda kelaparan inovasi berikutnya yang datang dari .NET dan bahkan ketika hal berikutnya mengumpulkan daya tarik pada platform lain ASP.NET Core akan berada pada posisi yang kurang menguntungkan untuk meniru kesuksesannya karena kami akan selamanya membayar "pajak MVC" default ke depan di mana setiap orang diharapkan menggunakan model dev untuk semua Web Aplikasi tanpa batas.

Ringannya Node juga membuatnya cocok untuk mengembangkan sejumlah kasus penggunaan lain seperti Electron, Native Mobile Apps, IOT, skrip shell, dll. yaitu tidak ada yang diuntungkan dari memiliki kerangka kerja web yang dibundel dalam instalasi default. Semakin membengkak instalasi default menjadi semakin tidak berguna untuk digunakan dalam skenario lain.

IMO defaultnya harus kembali ke visi asli .NET Core untuk memiliki inti modular yang ramping dengan fokus membuatnya lebih mudah untuk menambahkan fitur (yang dapat dimanfaatkan semua orang), yaitu bukan dengan menggabungkannya secara default dan membengkakkan default Install.

Terima kasih atas masukannya. Biarkan saya berbagi beberapa pemikiran.

1. Kami tidak memangkas rakitan karena kami hanya merasa menyukainya. Setiap perakitan yang kami keluarkan adalah perubahan besar dan menambah biaya peningkatan dari 2.x ke 3.0. Ini adalah prinsip panduan yang kami gunakan untuk memutuskan apa yang masuk ke Microsoft.AspNetCore.App: https://github.com/aspnet/AspNetCore/blob/master/docs/SharedFramework.md. Majelis yang kami usulkan untuk dihapus tidak memiliki beberapa kriteria untuk dimasukkan dalam kerangka kerja bersama. Khususnya, rakitan ini: (1) memiliki dependensi pada kode pihak ke-3 yang tidak dapat kami layani (2) rakitan itu sendiri tidak digunakan lagi di 3.0 atau (3) mereka menerapkan protokol atau mekanisme auth yang sangat dapat berubah ( misalnya, Facebook/Google/Twitter dapat memutuskan besok untuk mengubah cara kerja auth)

2. Menghapus MVC dari Microsoft.AspNetCore.App bukanlah sesuatu yang akan kami pertimbangkan. Meskipun kami menyadari tidak semua pengguna merujuk MVC dalam aplikasi mereka, kami yakin ini adalah bagian utama dari penawaran ASP.NET Core. Kami berencana untuk menyimpan ini di Microsoft.AspNetCore.App.

3. MVC telah menjadi bagian dari Microsoft.AspNetCore.App sejak 2.1, tetapi seperti yang akan Anda lihat di 2.1 "Empty Web" template , Anda tidak harus menggunakan MVC. Kehadirannya dalam kerangka kerja bersama tidak memaksa Anda untuk menggunakannya dalam aplikasi Anda. Anda tetap dapat menggunakan alternatif, menulis kerangka tampilan Anda sendiri, atau menggunakan lebih banyak API aspnetcore "mentah" untuk langsung membaca dan menulis permintaan dan tanggapan HTTP.

4. @dustinmoris : Saya hanya berpikir bahwa selalu lebih mudah untuk menambahkan lebih banyak paket ke dalam kerangka kerja yang akan dikirimkan dengan .NET Core 3.0 daripada menghapus paket di kemudian hari. Mengapa Anda tidak mulai menambahkan penyebut umum terkecil untuk menjalankan aplikasi Vanilla ASP.NET Core dan kemudian menawarkan sisanya sebagai paket NuGet. Jika ini ternyata menjadi masalah bagi pengembang maka Anda selalu dapat menambahkan lebih banyak barang nanti, tetapi Anda tidak akan dapat menghapus barang lagi nanti dengan mudah.

   Itulah yang kami coba lakukan. Lebih mudah menambahkan daripada menghapus. Kami menambahkan terlalu banyak hal di 2.0, dan kami menyesuaikan kembali ke apa yang kami yakini sebagai serangkaian hal yang dapat dipertahankan untuk masa depan yang dapat diperkirakan. Sebagian besar rakitan yang dihapus dari Microsoft.AspNetCore.App akan tetap ditawarkan sebagai paket NuGet. Jika nanti kami menemukan bahwa 90% dari semua pelanggan mereferensikan paket yang sama, itu adalah kandidat yang baik untuk kerangka kerja bersama. Namun, seperti yang disebutkan dalam dokumen panduan , seberapa banyak API digunakan merupakan metrik penting, tetapi bukan satu-satunya faktor yang kami pertimbangkan.

5. "Vanila" itu subjektif. Bagi banyak pengguna kami, MVC dan SignalR adalah "vanila".

6. Beberapa orang mengatakan bahwa .NET Core seharusnya menjadi ini atau itu atau hal lain. Segalanya berubah, kami mengumpulkan umpan balik pengguna, kami mengamati bagaimana produk digunakan, dan kami mencoba menyesuaikan default agar sesuai dengan apa yang kami pikir akan menguntungkan sejumlah besar pelanggan. Penyesuaian yang diusulkan dalam masalah ini adalah cerminan dari umpan balik yang kami terima di .NET Core 2.x.

Pikiran terakhir: masalah ini tidak akan membuat semua orang senang. Jika sepertinya kami mengabaikan umpan balik Anda, saya mohon maaf. Ketahuilah bahwa kami memiliki ratusan ribu pelanggan, dan hanya sebagian kecil dari mereka yang datang ke GitHub untuk berbagi umpan balik. Kami juga mengumpulkan informasi dari kunjungan langsung, panggilan telepon, email, media sosial, permintaan dukungan pelanggan, blog, telemetri Visual Studio, dan banyak lagi. Semua ini adalah bagian dari apa yang kami pertimbangkan saat kami membuat keputusan dan apa yang merupakan bagian dari pengalaman default dan apa yang tidak.

Jika ada sesuatu yang tidak jelas tentang motivasi atau alasan kami, beri tahu saya dan saya akan mencoba mengklarifikasi.

Jika Anda memiliki begitu banyak kontak pelanggan langsung, kapan terakhir kali Anda bertanya berapa banyak dari mereka yang menggunakan MVC dan SignalR? Apakah ada metrik penggunaan nyata di balik pendirian ini untuk mempertahankannya secara pasti alih-alih memiliki masing-masing dalam satu paket NuGet tunggal yang dapat dengan mudah diinstal saat dibutuhkan?

@dustinmoris termasuk MVC dalam runtime bersama berarti dikirimkan sudah dikompilasi sebelumnya, ini adalah manfaat yang akan hilang, yang akan meningkatkan waktu startup minimal, menjadikannya, IMO, trade-off yang buruk dalam contoh Anda memulai dengan cepat kontainer buruh pelabuhan. Selain itu, setiap penerapan sekarang perlu mengirimkan paket bersama dengan aplikasi karena tidak dalam waktu proses, ini meningkatkan ukuran paket penerapan setiap aplikasi MVC. Akhirnya, paket apa pun yang bergantung pada MVC di runtime juga harus menjadi penyebaran terpisah, tidak yakin berapa banyak jika ada karena saya tidak dapat menemukan daftar lengkapnya.

Semua itu mengatakan, dan ingatlah, saya memiliki 0 afiliasi dengan Microsoft atau tim aspnet, saya BISA melihat runtime terpisah yang dikirimkan yang merupakan aspnetcore barebone JIKA komunitas benar-benar menyuarakannya dan membuktikan itu adalah keinginan utama. Misi ini memberikan pengalaman yang luar biasa untuk sebanyak mungkin aplikasi dan pengembang dan faktanya saat ini adalah persentase yang sangat tinggi dari mereka yang mendapat manfaat dari MVC dalam runtime bersama. @natemcmaster apakah ada cara yang lebih disukai bagi individu yang bersangkutan untuk memilih ini untuk masa depan, masalah GitHub mungkin, dan apakah ini solusi yang masuk akal?

@psibernetic Anda dipersilakan untuk memulai masalah GitHub baru untuk menghapus MVC dari kerangka kerja bersama, tetapi seperti yang saya nyatakan di atas, menghapus MVC dari Microsoft.AspNetCore.App bukanlah sesuatu yang akan kami pertimbangkan, jadi masalah ini tidak mungkin untuk mendapatkan daya tarik dalam tim kita.

@Bomret Hampir setiap aplikasi pelanggan dunia nyata yang telah kami periksa menggunakan MVC dalam beberapa cara. Ada banyak manfaat dari menyimpannya dalam kerangka kerja bersama, dan saya tidak melihat alasan yang jelas mengapa kita harus menghapusnya.

@Natemcmaster : Saya menggunakan ponsel saya sekarang, tetapi terima kasih atas penjelasannya dan saya hanya
menyadari bahwa ini tentang metapackage ketika saya berbicara tentang
kerangka bersama.

@natemcmaster Saya pikir @forki , @dustinmorris , @gerardtoconnor dan @mythz telah menyatakan alasan yang sangat masuk akal bahwa saya belum mendengar argumen kontra. Akan sangat menyenangkan untuk memiliki runtime/lib web dasar yang dapat dibangun oleh pembuat kerangka kerja di atas seperti nodejs alih-alih menggabungkan hal-hal yang berpendirian dengannya. Seperti yang telah disebutkan sebelumnya, node sangat sukses karena tidak terlalu banyak mengamanatkan tetapi memberikan abstraksi yang bagus yang dapat Anda bangun di atasnya. MVC tidak akan hilang, itu hanya akan mundur dan menjadi pilihan untuk dibuat di antara berbagai lib web dan kerangka kerja lainnya. Dengan memasukkannya, Anda membuat pendirian untuk itu. Tentu saja sebagian besar pengembang hanya menerimanya saat dikirimkan bersama runtime, alih-alih melihat lebih jauh. Menurut pendapat jujur ​​saya, itu hanya terdengar seperti politik dan pemasaran - jangan tersinggung.

Ini disebut "Microsoft.AspNetCore.App", mengapa tidak membuat yang kedua "Microsoft.AspNetCoreMVC.App"?

Bagaimanapun saya mengerti sangat sulit untuk menarik garis, tetapi saya pikir umpan balik umum di sini adalah bahwa Anda memiliki semakin banyak orang yang menyukai apa yang Anda lakukan dengan aspnet core, tetapi siapa yang tidak terlalu menyukai hal-hal seperti MVC, pisau cukur , EF atau sinyalR.

Memang. Anda dapat mengandalkan komunitas untuk menjadi cukup bersemangat untuk datang dengan banyak ide untuk lib dan kerangka kerja untuk menangani api, web, soket web, templat, akses db, dan sebagainya. Kalian akan memberikan satu opsi bagi mereka yang memiliki MVC, Razor, EF dll. Tapi bukan satu-satunya atau default.

@natemcmaster Kesalahan saya, saya sebenarnya berbicara tentang kerangka kerja bersama dalam masalah ini di sini. Saya pikir alasan yang sama juga berlaku untuk paket meta, tetapi sejujurnya saya tidak terlalu peduli tentang itu, karena saya sudah dapat mereferensikan paket individual alih-alih paket meta, tetapi saya tidak dapat dengan mudah memangkas kerangka kerja bersama jika saya ingin menyimpannya. wadah sekecil mungkin, jadi saran Anda untuk membuka masalah baru untuk kerangka kerja bersama masuk akal 👍

@natemcmaster Bisakah Anda dengan cepat mengonfirmasi jika saya memahami hal-hal dengan benar:

• Akan ada kerangka kerja ASP.NET Core bersama yang dimasukkan ke dalam runtime .NET Core berikutnya (3.0), yang berarti bahwa ASP.NET Core dikirimkan sebagai bagian dari instalasi .NET Core di suatu lingkungan.

• Selain itu ada paket meta yang disebut Microsoft.AspNetCore.App dan Microsoft.AspNetCore.All yang merupakan kumpulan paket NuGet untuk aplikasi ASP.NET Core

• Kerangka kerja Inti ASP.NET bersama < paket meta Microsoft.AspNetCore.App yang mencakup hal-hal seperti EF Core?

• Saya dapat membuat aplikasi web ASP.NET Core tanpa harus menyertakan paket meta Microsoft.AspNetCore.App yang berisi EF Core, SignalR, MVC, dll. jika saya hanya ingin membuat API yang sangat kecil?

• Apa pun yang kalian lakukan, apakah mungkin untuk membuat wadah Docker dengan hanya dependensi paling minimal untuk ASP.NET Core untuk menjalankan API kecil?

Akan ada kerangka kerja ASP.NET Core bersama yang dimasukkan ke dalam runtime .NET Core berikutnya (3.0), yang berarti bahwa ASP.NET Core dikirimkan sebagai bagian dari instalasi .NET Core di suatu lingkungan.

Ya

Selain itu ada paket meta bernama Microsoft.AspNetCore.App dan Microsoft.AspNetCore.All yang merupakan kumpulan paket NuGet untuk aplikasi ASP.NET Core

Tidak. Ada konsep baru yang disebut FrameworkReference dan Microsoft.AspNetCore.App akan menjadi salah satunya. Microsoft.AspNetCore.All tidak akan ada di 3.0.

Kerangka kerja ASP.NET Core bersama < paket meta Microsoft.AspNetCore.App yang mencakup hal-hal seperti EF Core?

Tidak, itu tidak termasuk EF.

Apa pun yang kalian lakukan, apakah mungkin untuk membuat wadah Docker dengan hanya dependensi paling minimal untuk ASP.NET Core untuk menjalankan API kecil?

Dengan pemangkasan perakitan dan tautan ya, bukan dengan menghapus paket karena tidak akan ada untuk ASP.NET Core.

@natemcmaster

Kami tidak memangkas rakitan karena kami hanya merasa menyukainya. Setiap perakitan yang kami keluarkan adalah perubahan besar dan menambah biaya peningkatan dari 2.x ke 3.0.

Tempat yang tepat untuk melakukan koreksi apa pun adalah di dalam jendela versi utama v3 yang secara efektif merupakan satu-satunya saat perubahan seperti ini dapat terjadi, yaitu saat yang sama dengan penghapusan paket-paket lain.

Menghapus MVC dari Microsoft.AspNetCore.App bukanlah sesuatu yang akan kami pertimbangkan. Meskipun kami menyadari tidak setiap pengguna mereferensikan MVC dalam aplikasi mereka.

Ini disebut "Microsoft.AspNetCore.App" yang secara logis dibaca sebagai "referensikan paket ini" jika Anda membuat "ASP.NET Core App".

kami percaya ini adalah bagian utama dari penawaran ASP.NET Core. Kami berencana untuk menyimpan ini di Microsoft.AspNetCore.App.

Ini semakin mendekati inti masalah di mana tampaknya tujuan ASP.NET Core bergerak menjauh dari membina ekosistem gaya node.js-esque yang ramping dan terbuka. Apakah niat tim untuk semua orang untuk menggabungkan Aplikasi Inti ASP.NET sebagai identik dengan Aplikasi MVC? Beberapa nilai jual ASP.NET Core adalah "Bayar untuk bermain" dan dipisahkan "layering" tetapi ini menunjukkan bahwa "ASP.NET Core App" selamanya dimaksudkan untuk = Aplikasi MVC.

Akan lebih jelas bagi semua orang yang terlibat jika paket-paket itu lebih eksplisit di mana:

• Microsoft.AspNetCore.App => Basis untuk semua Aplikasi Inti ASP.NET
• Microsoft.AspNetCore.Mvc => ASP.NET Core MVC App

Tetapi jika "Microsoft.AspNetCore.App" tidak dapat disentuh, bisakah kita setidaknya memiliki paket meta "garis dasar" resmi (atau FrameworkReference) hanya dengan fitur server inti (yaitu tanpa lib yang berpendirian), beberapa penamaan potensial:

• Microsoft.AspNetCore.[Dasar | Telanjang | Ringan | Dasar]

("Inti" juga akan sesuai tetapi sudah ada penggunaan istilah yang berlebihan).

Tanpa ada paket/nama meta resmi, itu tidak akan dapat diakses seperti "Microsoft.AspNetCore.App" yang saat ini direkomendasikan yang merupakan dasar yang disarankan untuk semua Aplikasi Inti ASP.NET.

Kendala melahirkan inovasi di mana jika MVC hanya bisa berjalan di lapangan bermain yang sama seperti orang lain mungkin kita semua bisa memiliki akses ke fitur yang memungkinkan kita untuk dengan mudah dan eksplisit menyatakan produk mana (alias paket) yang dibutuhkan Aplikasi, misalnya bisa terlihat sesuatu Suka:

• Microsoft.AspNetCore.Mvc+SignalR+EF

Di mana setiap orang dapat dengan mudah mendeklarasikan dan hanya menginstal apa yang mereka butuhkan dan perkakas di belakang layar dapat menggabungkan paket meta "Microsoft.AspNetCore.Mvc", "Microsoft.AspNetCore.SignalR" dan "Microsoft.AspNetCore.EF". (Atau alt solusi superior untuk memenuhi maksud).

Kehadirannya dalam kerangka kerja bersama tidak memaksa Anda untuk menggunakannya dalam aplikasi Anda.

Kedengarannya seperti alasan untuk setiap monolit yang pernah dibuat. "Anda tidak harus menggunakan semua yang kami bundel, itu hanya ada untuk kenyamanan Anda".

Anda masih dapat menggunakan alternatif, menulis kerangka tampilan Anda sendiri,

Ini tidak ramah seperti yang Anda pikirkan, misalnya ketika kami sedang mengembangkan alternatif "tampilan kerangka kerja" kami sendiri untuk MVC dan Razor, kami mengalami perilaku ajaib di .NET Core di mana build akan gagal ketika menjalankan perintah standar untuk menerbitkan file .NET Core. Proyek Inti .NET, yaitu:

 dotnet publish -c Release

Yang akan gagal dengan:

EXEC(1,11): error CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?) [C:\src\NetC
oreWebApps\WebApp\src\WebApp\WebApp.csproj]
EXEC(1,54): error CS0518: Predefined type 'System.String' is not defined or imported [C:\src\NetCoreWebApps\WebApp\src\WebApp\WebApp.csproj]
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.razor.viewcompilation\2.0.0\build\netstandard2.0\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.targets(60,5):

Perilaku yang mengejutkan mengingat kami sedang mengembangkan alternatif untuk MVC yang secara eksplisit tidak mereferensikan MVC, Razor, atau menyertakan halaman .cshtml karena tujuannya adalah untuk membangun Aplikasi tanpa menggunakannya.

Setelah menjelajahi beberapa utas GitHub mencoba solusi yang berbeda, saya menemukan orang lain mengalami masalah yang sama di mana solusinya akhirnya memilih keluar dari kompilasi MVC Razor yang melanggar build dengan:

dotnet publish -c Release /p:MvcRazorCompileOnPublish=false

Yang memungkinkan proyek untuk diterbitkan. Selama uji coba sakelar yang berbeda untuk memperbaiki build yang rusak, kami juga menemukan bahwa kami dapat mengurangi jejak kami yang diterbitkan sebesar 150 .dlls di /refs/*.dll dengan memilih keluar dari metadata yang tidak perlu membengkakkan Aplikasi Web .NET Core 2.0 kami dengan memilih keluar dari metadata yang dibutuhkan oleh Razor dengan:

<PreserveCompilationContext>false</PreserveCompilationContext>

Jadi pada dasarnya dipaksa untuk bermain whack-a-mole untuk mencari tahu sakelar mana yang perlu kami beri tahu perkakas bahwa kami tidak menggunakan MVC untuk mencegahnya merusak pembuatan proyek dan dari mengeluarkan metadata yang tidak perlu yang hanya dibutuhkan Aplikasi MVC/Razor. Akan jauh lebih baik untuk memulai dengan paket metadata "dasar" di mana masalah seperti itu tidak mungkin terjadi karena perkakas tidak dapat mengasumsikan setiap Aplikasi menggunakan MVC karena bit MVC tidak akan ada.

Meskipun mudah untuk mengatakan bahwa ASP.NET Core masih merupakan platform yang ramah yang mendorong eksperimen, pembuatan, dan penggunaan "kerangka tampilan" alternatif, menggabungkan Kerangka Kerja Web berpendirian yang ditentukan seperti MVC hanyalah tentang hal paling bermusuhan yang dapat dilakukan untuk mencegah pembuatan dan penggunaan alternatif tersebut. Luangkan waktu sejenak untuk melihat-lihat jumlah alternatif populer yang muncul adalah ukuran yang baik untuk melihat seberapa mengundang platform bagi mereka.

Jika dimaksudkan bahwa setiap Aplikasi Inti ASP.NET harus menyertakan MVC daripada setiap "kerangka tampilan" alternatif lainnya (termasuk satu drop-in file .cs dari metode ext) akan tampak lebih "berat-berat " dan lebih rumit daripada menggunakan MVC yang dibundel, karena semuanya harus dibundel dengannya + apa pun yang dibutuhkan kerangka kerja tampilan.

Singkatnya, akan lebih baik jika "MVC" ikut serta dan tidak disertakan dalam paket .App , tetapi jika keputusannya tidak dapat diubah, bisakah kita setidaknya memiliki basis paket meta garis dasar resmi yang tidak tidak memasukkannya?

Ketahuilah bahwa kami memiliki ratusan ribu pelanggan, dan hanya sebagian kecil dari mereka yang datang ke GitHub untuk berbagi umpan balik.

IMO permintaan untuk paket awal yang tidak membengkak sedang kurang terwakili, anekdot: dari semua templat proyek C#/.NET yang kami buat untuk VS 2012, VS 2013, VS 2015, VS 2017 dan .NET Core, secara konsisten merupakan templat paling populer sejauh ini selalu menjadi template "Empty", yang juga sering menjadi kritik terhadap ASP.NET klasik bahwa template ASP.NET kosong default VS.NET tidak cukup Empty. Ini adalah saat Anda dapat membuat ASP.NET .NET Framework klasik "Kosong" tanpa MVC, tetapi sekarang dalam kerangka ASP.NET Core yang lebih baru, lebih ringan, dan lebih modular, MVC disertakan dalam paket awal minimum yang disarankan.

Kami juga mengumpulkan informasi dari kunjungan langsung, panggilan telepon, email, media sosial, permintaan dukungan pelanggan, blog

Orang tidak suka bloat yang sering disamakan dengan unremovable kompleksitas, yang mungkin diminta adalah membuat project sesederhana mungkin, yang seharusnya menjadi fokus dan bisa dikerjakan tanpa membengkakkan default project.

Dalam pengalaman saya, menjadi eksplisit lebih mudah untuk dipikirkan daripada kerangka kerja yang membengkak dengan perilaku ajaib. Jika eksplisit, Anda dapat berinteraksi dengannya, mencarinya, membacanya, menghapusnya, menguji berjalan tanpa menggunakannya (untuk melihat apakah itu penyebab masalah) dan itu terlihat saat membandingkan proyek dengan konfigurasi yang berbeda. Tetapi dengan perilaku ajaib dari alat MVC yang merusak build dari proyek mvc/razor-less saya di atas, saya tidak tahu bagian mana dari proyek saya yang memicunya, mengapa itu berjalan, cara menonaktifkannya, atau cara mengatasinya. Saya masih tidak yakin bahwa proyek saya yang tidak menggunakan MVC tidak diperlambat karena MVC dibundel atau menghasilkan output yang kurang optimal karena perlu mengakomodasi MVC atau Razor.

Telemetri Visual Studio, dan banyak lagi.

Akan sulit untuk membandingkan telemetri popularitas paket meta garis dasar yang tidak ada, jika memang IMO, itu akan memiliki popularitas yang lebih dari cukup untuk mendapatkan penyertaannya. Sebelumnya "Microsoft.AspNetCore.All" ditujukan untuk ujung lain dari spektrum dan termasuk alam semesta tetapi bukan kebalikan yang lebih berguna dari memiliki dasar yang berguna minimal.

Masuk akal jika Anda tidak membangun Aplikasi MVC dan opsi untuk memilih garis dasar tanpa itu sama dapat diaksesnya, mengapa Anda tidak memilihnya daripada opsi starter yang lebih membengkak yang berisi MVC?

@Bomret

Akan sangat menyenangkan untuk memiliki runtime/lib web dasar yang dapat dibangun oleh pembuat kerangka kerja di atas seperti nodejs alih-alih menggabungkan hal-hal yang berpendirian dengannya.

Tapi itulah cara kerjanya. Anda bebas membuat aplikasi dengan cara yang Anda inginkan. Jika Anda tidak ingin menggunakan MVC, jangan tambahkan middleware. Ya, templatnya ada tetapi Anda dapat mengubah aplikasi Anda untuk melakukan apa yang Anda inginkan, menggunakan apa pun yang Anda inginkan.

Saya pikir Anda sedikit salah mengartikan kerangka kerja bersama di sini. Anda hanya perlu melihatnya sebagai semacam perpustakaan standar yang dikirimkan dengan .NET Core. Untuk membuat referensi Node: Bayangkan versi Express saat ini dibundel dengan Node.js. Anda tidak _memiliki_ untuk menggunakannya tetapi sudah ada saat Anda ingin menggunakannya.

Dan untuk MVC, saya yakin Anda tidak tahu persis apa yang sebenarnya termasuk dalam ASP.NET Core MVC. Jika Anda tidak ingin menggunakan pengontrol dan tampilan Razor, baiklah, tetapi Anda mungkin masih akan menggunakan cukup banyak fungsi MVC di aplikasi Anda.

Jika Anda tidak ingin menggunakan pengontrol dan tampilan Razor, baiklah, tetapi Anda mungkin masih akan menggunakan cukup banyak fungsi MVC di aplikasi Anda.

Seperti apa?

Jika Anda tidak ingin menggunakan pengontrol dan tampilan Razor, baiklah, tetapi Anda mungkin masih akan menggunakan cukup banyak fungsi MVC di aplikasi Anda.

Ya tolong beri tahu, menemukan sedikit menggurui, sebagian besar dari kita terlibat dalam kerangka kerja alternatif yang dibangun di atas middleware/kestrel inti sehingga kami memiliki gagasan yang layak tentang apa yang kami gunakan, pengontrol dan tampilan Razor adalah bagian kecil dari MVC, kami tahu bahwa. Kerangka kerja F#, Giraffe/Saturnus & Zebra, berkinerja lebih baik daripada MVC dengan perutean yang lebih baik dan model pemrosesan yang disederhanakan. Dalam rendering, Zebra x2 lebih cepat daripada MVC di TechEmpower, inilah mengapa kami lebih memilih untuk tidak menggunakannya secara default. jika assembly-trimming/linker mampu mengurangi footprint kemudian, itu setidaknya sesuatu tetapi akan ideal jika tidak disertakan secara default untuk memungkinkan lapangan bermain yang lebih merata untuk kerangka kerja lain, dapatkan hasil imbang maksimum ke platform inti asp.net.

@mythz dari perspektif organisasi Anda benar, ada beberapa divisi logis di sini. Namun setiap subdivisi datang dengan kompleksitas tambahan yang signifikan dan overhead rekayasa yang membutuhkan waktu lama untuk meningkatkan fitur produk. Ketika kami mengharapkan sebagian besar pelanggan untuk mengambil keuntungan dari komponen MVC maka tidak sepadan dengan biaya untuk membaginya. Kelemahan untuk devs yang tidak menggunakannya dapat diabaikan, beberapa MB tambahan di direktori instal dan tidak ada dampak runtime kecuali Anda memuatnya.

Saya hanya bisa menunjuk ke @mythz untuk mengilustrasikan maksudnya. Semakin banyak hal yang digabungkan, semakin mereka terjerat. Maksudku Wa!? MVC memengaruhi pembuatan aplikasi Asp bahkan jika Anda tidak mereferensikannya di mana pun?!

@mencolek
Seperti yang telah ditulis orang lain: tidak. Ini adalah hal-hal bundling yang tidak ada hubungannya dengan runtime dasar. Gambar kerangka kerja ekspres akan dibundel dengan simpul secara default, menurut Anda ekosistem akan menjadi begitu hidup dan beragam?

Saya juga sama sekali tidak mengerti bagaimana menghapus MVC, SingalR dll. dari instalasi dasar dan menyediakannya sebagai paket NuGet tunggal yang masing-masing dapat diberi label sebagai "kompleksitas tambahan". Pengembang menginstal paket tambahan dalam banyak kasus. Dan jika menyediakannya sebagai paket tambahan akan meningkatkan waktu pemulihan "secara signifikan", mereka tetap terlalu gemuk.

@Tratcher

Namun setiap pembagian

Subdivisi yang dimaksud adalah decoupling MVC sehingga ASP.NET Core Apps dapat memiliki dasar minimal yang berguna tanpa kerangka kerja pengembang yang berpendirian yang menentukan apa yang harus mereka gunakan untuk mengembangkan ASP.NET Core Apps.

hadir dengan kompleksitas yang ditambahkan secara signifikan dan overhead rekayasa yang membutuhkan waktu lama untuk meningkatkan fitur produk.

Untuk memperjelas bagaimana ini berbunyi: diperlukan terlalu banyak overhead rekayasa untuk menghapus overhead yang tidak perlu dari setiap Aplikasi Inti ASP.NET yang tidak menggunakan MVC karena jika MVC harus bekerja seperti setiap kerangka kerja alternatif lain yang secara signifikan akan menambah kompleksitas "ke MVC".

Jika MVC memerlukan kompleksitas yang signifikan untuk bekerja dalam opsi ekstensibilitas yang sama yang harus dijalankan oleh setiap kerangka kerja alternatif lainnya, maka itu menunjukkan masalah dengan MVC dan fitur apa pun yang ditambahkan untuk membuatnya bekerja lebih mulus dapat ditambahkan untuk keuntungan semua orang. Sama seperti membedah monolit, kompleksitas perkakas dan runtime akan lebih ramping dan kurang kompleks dengan kompleksitas tambahan yang dipindahkan ke tempatnya di MVC dan integrasi/perkakasnya.

Alih-alih, kami berakhir dengan situasi di mana MVC tertanam dalam alat default yang dapat merusak proyek penerbitan dan mengasapi keluaran proyek yang tidak menggunakannya. Karena itu tidak berfungsi seperti yang lainnya, tidak ada cara untuk mengatakan bahwa Anda menggunakan MVC atau cara apa pun untuk mengatakan bahwa Anda tidak menggunakan MVC, itu selalu diasumsikan.

Saat kami mengharapkan sebagian besar pelanggan memanfaatkan komponen MVC

Yah itulah yang diharapkan, untuk merugikan setiap alternatif lain itu adalah kerangka kerja yang ditentukan yang dibundel dalam instalasi minimum yang direkomendasikan default, seperti Apple memberi semua orang lagu U2 gratis apakah mereka suka atau tidak.

Kerugian bagi pengembang yang tidak menggunakannya dapat diabaikan

Akankah pengembang mendapat manfaat dari ekosistem yang lebih sehat dengan lebih banyak variasi, opsi, dan inovasi?

Apakah pengembang mendapat manfaat dari kebingungan tambahan dan definisi kabur tentang apa itu "ASP.NET Core App"? "Dulu seperti node.js untuk .NET, tetapi sekarang ini lebih merupakan kerangka kerja vendor tunggal yang berpendirian di mana pada dasarnya setiap Aplikasi dimulai dengan sekelompok hal berpendirian yang menentukan bagaimana Anda harus membangun Aplikasi Web, Anda dapat menganggapnya sebagai setiap Aplikasi sudah diinstal sebelumnya dengan express dan dependensinya secara default - Anda diharapkan untuk menggunakannya"

Apakah pengembang mendapat manfaat dari casing khusus MVC? Itu tidak diinstal atau diperbarui seperti yang lain dan bergantung pada perkakas tersembunyi dan perilaku ajaib yang harus Anda cari tahu ada dan nonaktifkan. Casing khusus seperti inilah yang menambah kompleksitas yang tidak disengaja, ketika menalar tentang proyek Anda, Anda harus mempertahankan seperangkat aturan yang berbeda tentang cara kerja MVC vs cara kerja yang lainnya.

Jika eksplisit, itu akan meningkatkan keterbacaan dan Anda dapat mengetahui dari konfigurasi proyek bahwa itu adalah Aplikasi MVC, misalnya:

• Microsoft.AspNetCore.Mvc

Yang menandakan itu adalah Aplikasi MVC dan untuk menginstal semua dependensi dan mengonfigurasi otomatis semua kebutuhan perkakas MVC yang dipesan lebih dahulu - idealnya menggunakan model terbuka yang sama yang dapat diakses semua orang.

Dengan menyimpannya di proyek "Microsoft.AspNetCore.App" default, Anda selamanya mengikatnya dengan setiap Aplikasi Inti ASP.NET dan membuatnya tidak menguntungkan untuk apa pun yang lebih baik yang akan datang. ASP.NET Web Pages adalah kerangka kerja tampilan Razor lain yang ditambahkan ke ASP.NET bertahun-tahun yang lalu yang diinstal dan juga memiliki perilaku sihir invasif yang diaktifkan secara default. Itu datang dengan IDE Matriks Web sendiri yang tidak lagi didukung atau tersedia untuk diunduh sehingga yang tersisa adalah kasus di mana kompleksitas teknologi mati selamanya tertanam di ASP.NET klasik dan secara aktif menyebabkan masalah untuk Kerangka Kerja Web aktif lainnya terikat untuk menggunakan halaman Razor .cshtml yang selamanya perlu membawa bagasi di bawah ini untuk secara eksplisit mencegah Halaman Web melanggar kerangka kerja tampilan mereka dengan:

<appSettings>
    <add key="webPages:Enabled" value="false" />
</appSettings>

Untuk mengulangi permintaan fitur dalam urutan preferensi adalah:

1. Ubah "Microsoft.AspNetCore.App" menjadi dasar minimal yang berguna untuk semua Aplikasi Inti ASP.NET (yaitu tanpa MVC).
2. Pertahankan paket meta seperti "Microsoft.AspNetCore.Base" yang dapat digunakan semua orang yang tidak menggunakan MVC sebagai dasar minimal yang berguna.

Jika tidak satu pun dari ini yang akan dipertimbangkan, bisakah kita setidaknya memiliki flag di seluruh proyek seperti mvc:enabled = false yang dapat diperiksa oleh semua alat MVC untuk menonaktifkan dan mencegahnya berjalan?

@mythz Anda memasukkan kata-kata ke dalam mulut saya. Kompleksitas tambahan bukan pada MVC, ini untuk membangun infrastruktur, pengemasan, penginstal, dll. yang diperlukan untuk membuat dan mengirimkan lapisan komponen lain terlepas dari apa lapisan itu terdiri.

Jika tidak satu pun dari ini yang akan dipertimbangkan, bisakah kita setidaknya memiliki flag di seluruh proyek seperti mvc:enabled = false yang dapat diperiksa oleh semua perkakas MVC untuk menonaktifkan dan mencegahnya berjalan?

Bisakah Anda lebih spesifik tentang fitur perkakas apa yang ingin Anda lihat dinonaktifkan? Itu mungkin layak menjadi masalah terpisah.

@Tratcher

Kompleksitas tambahan bukan pada MVC, ini untuk membangun infrastruktur, pengemasan, penginstal, dll. yang diperlukan untuk membuat dan mengirimkan lapisan komponen lain terlepas dari apa lapisan itu terdiri.

yaitu kompleksitas tambahan dari apa yang diperlukan agar MVC berfungsi.

Bisakah Anda lebih spesifik tentang fitur perkakas apa yang ingin Anda lihat dinonaktifkan? Itu mungkin layak menjadi masalah terpisah.

2 masalah yang saya hadapi adalah perlunya mengkonfigurasi /p:MvcRazorCompileOnPublish=false secara manual yang mencegah proyek saya (tanpa halaman .cshtml) untuk dipublikasikan. Bendera lain yang harus dinonaktifkan adalah:

<PreserveCompilationContext>false</PreserveCompilationContext>

Seperti kebanyakan perilaku sulap, saya berasumsi ada lebih banyak tetapi hanya mengetahuinya ketika saya mengalaminya.

Pada dasarnya flag untuk menentukan bahwa MVC tidak digunakan dan untuk menonaktifkan semua perkakas atau konsesi yang diaktifkan secara default yang ditambahkan karena MVC.

@mythz lanjutkan dan ajukan masalah itu.

Anda sebenarnya dapat membuat kerangka kerja bersama yang serupa untuk tumpukan layanan jika MVC dan SignalR dll tambahan menjadi perhatian bagi pengguna Anda.

@davidfowl Kedengarannya sangat luar biasa, saya bisa melihat beberapa kasus penggunaan berbeda untuk kerangka kerja yang disediakan komunitas. Apakah ada dokumentasi tentang itu?

Seperti yang dapat Anda bayangkan, ini bukan sesuatu yang akan kami bangun sebagai dukungan kelas satu karena jumlah orang yang melakukan ini sedikit. Dikatakan bahwa Anda dapat melihat bagaimana kami membangun perilaku kami dan meniru perilaku itu.

@davidfowl Paket dasar minimal akan berguna untuk semua aplikasi non MVC - misalnya akan ada banyak aplikasi ringan dan layanan mikro lainnya yang ingin melewati semua kerangka kerja dan menulis langsung ke respons itu sendiri. IMO opsi ini harus tersedia di dalam kotak, kami lebih suka untuk tidak memulai dari basis tidak resmi yang terdiri dari versi paket yang tidak kami kendalikan. Idealnya semuanya akan menjadi aditif dari paket dasar alih-alih memulai dari garis singgung berbeda yang dipertahankan secara eksternal. Tapi mungkin ini adalah satu area di mana komunitas eksternal dapat berkumpul untuk mempertahankan subset dasar "AspNetCore" yang berguna untuk semua Aplikasi dan Kerangka Kerja non MVC.

Dengan mengatakan di mana kita harus mencari untuk membuat Kerangka kustom? Mungkin akan semudah memulai dari salinan apa yang digunakan untuk membuat "Microsoft.AspNetCore.App" dan menghapus semua pustaka yang tidak penting untuk mengembalikannya ke subset minimal yang berguna.

@mythz mengapa Anda membutuhkan kerangka kerja, Anda bisa langsung menggunakan server Kestrel. Ini hanya untuk mengatakan bahwa mungkin versi cahaya Anda bukanlah ide orang lain tentang cahaya atau inti. Saat ini kami memiliki pendapat dan akan luar biasa jika komunitas dapat melangkah ke sini dan membuat template dan kerangka kerja bersama alternatif yang cukup minim. Kami OSS, semua yang diperlukan untuk membuat sesuatu kustom ada di sana dan kami sangat responsif dan dengan senang hati akan membantu.

@natemcmaster Dapat membantu dengan detail tentang cara membuat kerangka kerja bersama khusus.

@davidfowl Anda menyarankan untuk membuat yang khusus, saya hanya setelah dapat memulai dari basis yang bermanfaat minimal tanpa kerangka kerja yang berpendirian. Kami tidak ingin mereferensikan beberapa paket satu per satu karena alasan yang sama, rekomendasinya adalah untuk semua ASP.NET Core Apps untuk merujuk "Microsoft.AspNetCore.App" - lebih mudah diakses untuk dapat mereferensikan satu paket.

Ini hanya untuk mengatakan bahwa mungkin versi cahaya Anda bukanlah ide orang lain tentang cahaya atau inti.

Semua orang tampaknya cukup bulat di sini bahwa MVC tidak termasuk dalam paket dasar. Satu-satunya "produk" lain yang tampaknya disertakan adalah SignalR yang saya bayangkan akan memiliki penggunaan yang lebih sedikit daripada MVC dan lebih sedikit alasan untuk dimasukkan. Saya tidak terlalu akrab dengan apa yang ada di setiap paket tetapi yang lainnya tampaknya berguna secara umum dan merupakan bagian yang kondusif dari "platform" ASP.NET Core.

OK izinkan saya membuang saran untuk mencoba menjadi konstruktif di sini. Kami tidak mengubah Microsoft.AspNetCore.App, kami pikir itu adalah sesuatu yang sebagian besar pengguna akan butuhkan dan gunakan. Mari perkenalkan lapisan lain yang merupakan kerangka kerja bersama "inti" ini (awalnya kami melakukan sesuatu seperti ini dengan https://www.nuget.org/packages/Microsoft.AspNetCore/2.2.0-preview3-35497). Itulah kerangka kerja bersama tempat Anda akan mendasarkan kerangka kerja lain ini (seperti Nancy dan ServiceStack) di atasnya.

Kami masih akan mengirimkan template default kami dengan Microsoft.AspNetCore.App sama seperti sekarang tetapi pembuat kerangka seperti Anda dapat memiliki template lain yang menggunakan kerangka dasar bersama.

PS: Utas ini tidak mulai mewakili mayoritas pelanggan kami dari jarak jauh, jadi saya tidak akan menarik kesimpulan dari sini saja. Kami mendapatkan umpan balik dari banyak tempat dan github memiliki panduan kami yang paling vokal dan bersemangat.

Ya, saya pikir itu lebih dekat dengan memuat banyak hal penting untuk mengonfigurasi Aplikasi dan menjalankannya. Dari deps di Microsoft.AspNetCore.App kami juga menggunakan:

• Microsoft.Extensions.Primitives
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstraksi
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstraksi
• Microsoft.AspNetCore.Logging.Abstraksi
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

Jadi hal-hal seperti HTTP, Hosting, Logging, dan abstraksi Konfigurasi (berguna untuk sebagian besar aplikasi HTTP) juga bagus untuk disertakan dan apa pun yang dianggap pantas oleh siapa pun. Satu-satunya preferensi saya adalah tidak menyertakan MVC/SignalR.

dan sekarang menjadi menarik. seperti yang sudah dikatakan david: orang memiliki perbedaan
gagasan tentang apa arti "inti". Dari POV saya, saya tidak berpikir DependencyInjection
harus masuk. /mengangkat bahu

Am Do., 8. Nov. 2018 um 08:30 Uhr schrieb Demis Bellot <
[email protected]>:

Ya saya pikir itu lebih dekat dengan mengandung banyak hal penting untuk
mengonfigurasi Aplikasi dan menjalankannya. Dari deps in
Microsoft.AspNetCore.App
https://www.nuget.org/packages/Microsoft.AspNetCore.App kami juga
menggunakan:

• Microsoft.Extensions.Primitives
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstraksi
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstraksi
• Microsoft.AspNetCore.Logging.Abstraksi
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

Jadi hal-hal seperti HTTP, Hosting, Logging, dan abstraksi Konfigurasi
(berguna untuk sebagian besar aplikasi HTTP) juga akan menyenangkan untuk dimasukkan dan apa pun
orang lain yang dianggap pantas. Satu-satunya preferensi saya adalah tidak memiliki
MVC/SinyalR disertakan.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-436898980 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AADgNOzUVEHlJNBrPD5P2BsQj6UQdqyvks5us92zgaJpZM4YAsZ1
.

@mythz Sebagian besar termasuk secara transitif.

@forki Selamat datang di dunia kami.

Kami tidak mengubah Microsoft.AspNetCore.App, kami pikir itu adalah sesuatu yang sebagian besar pengguna akan butuhkan dan gunakan.

Kata-kata terakhir yang terkenal. Inilah pembenaran dari setiap keputusan buruk - "KAMI pikir MEREKA membutuhkannya".

Anda tahu apa yang saya pikirkan? Microsoft harus mulai memperlakukan basis pengembangnya sebagai insinyur cerdas independen dan bukan sebagai pengembang domba, dan ya kalian memiliki banyak pengembang domba, yang akan mengikuti dan menggunakan apa pun yang Anda berikan kepada mereka, tetapi pengembang lain yang lebih vokallah yang akan membuat komunitas dan membangun startup baru di .NET stack.

Terkadang ada baiknya untuk mendengarkan power user.

Terlepas dari itu, kami tidak akan mengubah Microsoft.AspNetCore.App. Saya menawarkan kompromi yang menurut saya memenuhi persyaratan di sini.

@forki jika Anda menggunakan aspnet core, Anda tetap dihadapkan dengan DI, lebih baik membuatnya menyertakan metode kenyamanan secara default (Dapatkan layanan, GetRequiredServicedan suka ada di paket itu). Dan hei F# bahkan tidak dapat membuatnya sendiri karena batasan T :> U yang hilang https://github.com/fsharp/fslang-suggestions/issues/255 jadi _(ツ)_/¯

Saya ingin agar kerangka kerja bersama dasar @davidfowl disebutkan... Saya pikir @mythz dan @dustinmorris akan baik-baik saja dengan pendekatan seperti itu. Ini juga tepat untuk Saturnus @Krzysztof-Cieslak

kamu tetap dihadapkan dengan DI

Saya tahu dan kami berdiskusi beberapa kali. Hanya saja aku lebih suka tidak
;-) tapi begitulah adanya...

Am Fr., 9. Nov. 2018, 10:57 hat Nino Floris [email protected]
geschrieben:

@forki https://github.com/forki jika Anda menggunakan aspnet core, Anda
berhadapan dengan DI, lebih baik membuatnya termasuk metode kenyamanan dengan
default (Dapatkan layanan, GetRequiredService, dan sejenisnya ada di dalamnya
kemasan). Dan hei F# bahkan tidak bisa membuatnya sendiri karena hilang
T :> U kendala fsharp/fslang-suggestions#255
https://github.com/fsharp/fslang-suggestions/issues/255 jadi _(ツ)_/¯

Saya ingin memiliki kerangka kerja bersama dasar itu @davidfowl
https://github.com/davidfowl disebutkan... Saya pikir @mythz
https://github.com/mythz dan @dustinmorris
https://github.com/dustinmorris keduanya akan baik-baik saja dengan pendekatan seperti itu.
Ini juga tepat untuk Saturnus @Krzysztof-Cieslak
https://github.com/Krzysztof-Cieslak

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-437309244 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AADgNGP3d8R0otOAuUQC7AYK6O2dzJ3mks5utVGegaJpZM4YAsZ1
.

Memperbarui pos asli untuk menyertakan:

• Microsoft.AspNetCore.Authentication.JwtBearer
• Microsoft.AspNetCore.Authentication.OpenIdConnect

Ini ditarik keluar dari kerangka kerja bersama dan akan dikirimkan sebagai paket NuGet. Rakitan ini memiliki ketergantungan pada IdentityModel API yang belum sesuai dengan pedoman untuk kerangka kerja bersama. Kami telah mulai bekerja dengan tim IdentityModel dan mempertimbangkan untuk memasukkannya kembali ke dalam kerangka kerja bersama di masa mendatang. cref https://github.com/aspnet/AspNetCore/pull/6035

Perbarui posting asli untuk menyertakan Microsoft.AspNet.WebApi.Client. Lihat https://github.com/aspnet/AspNetCore/pull/6552#issuecomment -453177732.

Saya sering cukup bingung karena itu yang harus saya sertakan.

Talking Visual Studio - Apakah saya harus membuka simpul Microsoft.AspNetCore.App dan merujuk silang semua yang ada di bawah sana dengan apa yang mungkin telah saya instal secara individual?

Saya sedang membersihkan rumah dan melihat saya memiliki paket-paket ini. Jadi mana yang berlebihan?

<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.6.0-beta2" />
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.AspNetCore.NodeServices" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.SpaServices.Extensions" Version="2.2.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.2.1">

Saya cukup terkejut melihat bahwa bahkan alat SpaServices dan EntityFramework saat ini disertakan (yang tidak saya sadari sebelumnya - dan hebat) - tetapi saya juga memiliki beberapa referensi 2.2.1 lama yang tidak dapat membantu apa pun.

Intinya - dapatkah beberapa pekerjaan koordinasi yang lebih baik dilakukan dengan tim Visual Studio untuk memastikan bahwa IDE hanya sedikit lebih cerdas dengan memahami paket-paket mega ini dan memberi tahu saya bahwa aman untuk menghapus sesuatu - dan kemudian di v3 memberi tahu saya bahwa saya perlu menambahkannya masuk lagi ;-)

@simeyla terima kasih atas umpan baliknya. Apa yang Anda katakan terkait dengan subjek, tetapi itu bukan tentang topik ini. Alat untuk mengoptimalkan referensi paket akan menjadi fitur Visual Studio baru. Fitur ini dapat berguna secara umum, tidak hanya untuk skenario ini, jadi saya sarankan untuk mengirimkan umpan balik ini ke Visual Studio secara langsung. Di VS, gunakan "Bantuan > Kirim Umpan Balik...". Jika Anda membagikan tautan setelah Anda membuat postingan, saya dapat meneruskannya secara internal ke tim rekan kami yang bekerja di VS.

Di 3.0, kami akan menghilangkan metapackage Microsoft.AspNetCore.App sama sekali dan membuat banyak penyesuaian pada paket mana yang kami kirimkan. Kami telah mulai mendokumentasikan cara memutakhirkan dari 2.x ke 3.0 dan akan terus memperbarui dokumen ini saat kami menyelesaikan daftar pengiriman rakitan di 3.0.

Pindah ke pencapaian 'Diskusi' karena item ini tidak melacak pekerjaan apa pun, tetapi kami akan memperbaruinya sebagai detail perubahan implementasi.

Menambahkan Microsoft.Extensions.DependencyModel ke daftar. Diubah sebagai bagian dari https://github.com/aspnet/AspNetCore/pull/10271

Pertanyaan di sini @natemcmaster @DamianEdwards , disebutkan bahwa templat memiliki semua yang diperlukan untuk membangun secara lokal. Dengan pemikiran ini dan penghapusan pustaka Auth, apakah itu berarti bahwa templat autentikasi apa pun tidak akan dibuat offline di 3.0? Saya mengerti bahwa tidak ada perpustakaan auth yang akan berfungsi secara offline, tetapi jika saya tidak memiliki cache nuget, secara teoritis saya bisa mendapatkan kegagalan build setelah memperbarui template auth baru jika saya offline. Itu sepertinya pengalaman buruk.

Ya, itulah salah satu hasil dari perubahan ini. Pada Pratinjau 6 (segera hadir), dotnet new mvc , dotnet new razor , dotnet new web dan lainnya tidak memiliki PackageReferences, jadi mereka tidak akan terpengaruh, tetapi menentukan opsi tambahan , seperti --auth individual dapat menghasilkan PackageReference yang memerlukan pengunduhan paket.

Kami membuat tradeoff yang disengaja di sini. Meskipun template yang memiliki PackageReference tidak akan memulihkan offline pada mesin yang bersih, kami juga menghindari banyak masalah yang datang dari mencoba membuat cache NuGet offline yang telah diisi sebelumnya (sebagai permulaan, checkout https://github.com/dotnet/ dotnet-docker/issues/237, https://github.com/NuGet/Home/issues/6309, dan http://blog.ctaggart.com/2019/03/using-nuget-lock-file-for-reproducible .html).

@natemcmaster benar-benar mengerti dan saya mendapatkan alasannya, hanya perlu didokumentasikan dengan baik atau akan ada banyak masalah yang terbuka pada rilis 3.0 awal di mana orang mengatakan dotnet new webapp --auth Individual tidak membangun.

Adakah yang bisa mendidik saya tentang mengapa Microsoft.AspNetCore.Authentication.JwtBearer dikompilasi dengan ketergantungan pada .netcoreapp3.0? Tidak bisa di .netstandard2.x? Saya ingin menggunakannya di perpustakaan kelas dan saya ingin menyimpan semua classlibs saya .netstandard

@buvinghausen https://github.com/aspnet/Announcements/issues/324

@Pilchie Saya pikir masalah ini layak disebut dalam dokumentasi untuk ASP.NET Core 3.0. Seperti disebutkan di atas, pengguna yang meningkatkan ke 3.0 perlu menambahkan <PackageReference> untuk mengkompensasi API yang pindah dari Microsoft.AspNetCore.App.

@Bomret Hampir setiap aplikasi pelanggan dunia nyata yang telah kami periksa menggunakan MVC dalam beberapa cara. Ada banyak manfaat dari menyimpannya dalam kerangka kerja bersama, dan saya tidak melihat alasan yang jelas mengapa kita harus menghapusnya.

Kami tentu saja tidak, dan saya tahu beberapa orang di toko lain yang menggunakan .net core untuk aplikasi tanpa server, api web, dll, di mana kami sama sekali tidak membutuhkan MVC.

Penutupan, karena kami telah mengirimkan 3.0 hari ini.

Kita perlu memindahkan daftar ini ke dokumen

@davidfowl telah ditambahkan: https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#remove -obsolete-package-references

@pranavkm daftar itu sebenarnya kebalikannya: Hal-hal yang bukan lagi paket tetapi kemungkinan masih dalam kerangka kerja bersama.

Ini tentang hal-hal yang telah dihapus dari kerangka kerja bersama, tetapi kemungkinan sekarang hanya tersedia sebagai paket.

@scottaddie ini adalah daftar yang perlu kita rujuk di dokumen pembuatan pustaka ASP.NET Core.

@DamianEdwards ini - https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#add -package-references-for-removed -perakitan?

Itu dia :)

Terlambat ke pesta tetapi ini tidak terasa membantu saya mencapai tujuan menyederhanakan perkembangan saya.

a) Tampaknya sekarang jika ada peningkatan pada komponen AspNetCore (katakanlah, SignalR), maka kita perlu menunggu "paket dotnet" baru untuk Microsoft.AspNetCore.App dirilis untuk menggunakannya, dengan membawa semuanya lain dalam paket itu?
b) Tidak dapat lagi membuat kelas utilitas untuk AspNetCore di pustaka kelas netstandard (misalnya, middleware Auth). Sekarang perpustakaan kelas harus netcoreapp3.0 untuk menampung barang-barang ini. Ini berarti membagi perpustakaan kelas utilitas kami menjadi implementasi netstandard / netcore.
EDIT: c) Bagaimana saya benar-benar menentukan versi paket mana yang saya gunakan jika saya melakukannya <Project Sdk="Microsoft.NET.Sdk.Web"> ? Jelas kami ingin memiliki build yang dapat direproduksi di cabang yang berbeda setelah memperbarui dotnet.

a) Tampaknya sekarang jika ada peningkatan pada komponen AspNetCore (katakanlah, SignalR), maka kita perlu menunggu "paket dotnet" baru untuk Microsoft.AspNetCore.App dirilis untuk menggunakannya, dengan membawa semuanya lain dalam paket itu?

SignalR dikirimkan pada jadwal yang sama dengan AspNetCore lainnya sehingga tidak ada perubahan penjadwalan di sini.

SignalR dikirimkan pada jadwal yang sama dengan AspNetCore lainnya sehingga tidak ada perubahan penjadwalan di sini.

Jadi ini hanya contoh yang buruk? Bisakah hal yang sama dikatakan tentang semua paket NuGet lain yang telah dihapus?

SignalR dikirimkan pada jadwal yang sama dengan AspNetCore lainnya sehingga tidak ada perubahan penjadwalan di sini.

Jadi ini hanya contoh yang buruk? Bisakah hal yang sama dikatakan tentang semua paket NuGet lain yang telah dihapus?

Aku pikir begitu. Semua komponen .NET Core dan ASP.NET Core menggunakan jadwal pengiriman yang sama. Jika ada yang tidak maka harus dikirim dalam paketnya sendiri.

Aku pikir begitu. Semua komponen .NET Core dan ASP.NET Core menggunakan jadwal pengiriman yang sama. Jika ada yang tidak maka harus dikirim dalam paketnya sendiri.

Aku akan mengambil kata-kata Anda untuk itu. Saya tidak punya contoh penghitung khusus. Itu tidak "terasa" seperti itu ketika memperbarui paket AspNetCore NuGet di masa lalu.