Dalam standup, Damian menyebutkan bahwa mungkin hal-hal terkait Nuget akan pindah ke sesuatu yang akan menjadi pengganti package.config saat ini. Jelas keputusan ini adalah jalan yang adil, saya ragu Anda akan mendapatkan jawaban konkret pada saat ini.

Dan saya tidak setuju bahwa "JSON lebih sederhana untuk mewakili dependensi itu". Ada pro dan kontra. Lihat ini https://Gist.github.com/darrelmiller/07fed784d2c20de9f5d3719977167181

Saya setuju tentang perubahan _if_ pindah ke nuget.json. itulah satu-satunya bagian dari project.Json yang menurut saya perlu diedit oleh pengembang.

@darrelmiller Yaml mungkin merupakan alternatif yang lebih baik dalam hal verbositas. Dan Anda curang dengan string yang dipisahkan koma alih-alih array;).

@sandorfr Itu. Namun, saya menduga salah satu alasan untuk kembali ke sistem proyek berbasis XML adalah karena alat yang signifikan yang ada di sekitar sistem proyek berbasis XML di ekosistem .net. Komentar saya bukan untuk mencoba dan mengidentifikasi format terbaik, hanya untuk menunjukkan bahwa XML pada dasarnya tidak buruk.

Ya dan itu adalah berita terburuk minggu ini. Ini seperti dibawa kembali ke masa lalu... :( Memang Xml tidak buruk, namun msbuild... Dan proyek dasar msbuild xml tidak akan semulus yang Anda gambarkan.

Namun, saya menduga salah satu alasan untuk kembali ke sistem proyek berbasis XML adalah karena alat yang signifikan yang ada di sekitar sistem proyek berbasis XML di ekosistem .net.

Saya hanya tidak mengerti mengapa semua hal telah diakhiri dengan " inti " untuk menunjukkan itu adalah hal baru jika tujuannya juga untuk membawa bagasi ke depan seperti msbuild.

Prosesnya terlalu menyakitkan selama lebih dari dua tahun tetapi banyak orang baik-baik saja karena semua penambahan dan peningkatan baru menyelaraskan ekosistem dengan ekosistem lain dan semuanya adalah perubahan untuk alasan yang baik. Namun, tiba-tiba, pengembang perusahaan materi gelap mulai memberikan umpan balik di balik pintu tertutup dan kami melihat banyak bagasi yang harus dibawa ke depan.

Tidak banyak ekosistem di luar sana yang memiliki konfigurasi berbasis XML. Faktanya, semua ekosistem yang dirancang baru merangkul format lain (YAML, JSON, dll.). Lihat reaksi semua orang di media sosial, saya tidak melihat banyak orang yang menyukai perubahan ini. Namun, umpan balik yang telah diberikan secara pribadi tampaknya lebih penting bagi tim. Itu bukan hal yang buruk, saya mengerti alasannya tetapi itu hanya menunjukkan cara keputusan diproses di ekosistem ini.

+1 pada berita terburuk minggu ini. Di mana diskusi tentang ini? Saya tidak dapat menemukan apa pun, hanya keputusan sepihak.

Saya tidak melihat dukungan komunitas untuk keputusan ini, dan banyak yang menentang (85% hingga 15% pada hitungan terakhir). Bagaimana jalannya diskusi, siapa yang membuat keputusan, berdasarkan informasi apa?

Apakah ini cara kami melakukan sesuatu di .NET Core? Mengorbankan kualitas di balik pintu tertutup karena kami ingin mendukung daftar teknologi lama yang dirahasiakan?

Mari kita lakukan ekstensi VS yang membuat .csproj dari project.json yang dapat dimanfaatkan oleh orang-orang yang menggunakan teknologi lama tersebut.

Tapi jangan mengirim kami kembali ke mimpi buruk file proyek berbasis XML. Mereka adalah ide yang buruk ketika diperkenalkan, dan kami telah membayar pajak penggabungan yang buruk dan keterbacaan yang sulit selama lebih dari satu dekade. Itu cukup.

Saya pikir Anda terlalu pesimis - dan saya rasa itu terutama karena kita semua terkejut dengan ini. Biarkan mereka membagikan lebih banyak info tentang rencana mereka dan kemudian kita akan lihat. @DamianEdwards dengan jelas mengatakan bahwa mereka ingin mempertahankan bagian yang baik dari model project.json.

Menurut pendapat saya itu akan menjadi:

• tidak harus menentukan setiap file cs
• dapat memodifikasi file tanpa harus membongkar proyek
• dapat memodifikasi dependensi nuget secara langsung di file (dengan IntelliSense)
• mampu mengganti paket nuget dengan sumber lokal melalui global.json

Dalam hal kompilasi, saya hanya berpikir bahwa mungkin untuk mengkompilasinya tanpa menginstal Visual Studio. Bagi saya, tidak masalah jika perintah sebenarnya adalah "dotnet build" atau "msbuild". Yang penting adalah bahwa harus ada cara untuk mengkompilasi seluruh solusi, yang - omong-omong - belum ada di "dotnet cli" (setidaknya tidak sejauh yang saya tahu).

Jika ini dapat dicapai, saya setuju dengan sintaks apa pun yang mereka gunakan. XML tidak bagus tetapi JSON jelas memiliki kekurangannya juga.

Sunting: Saya pikir ini tidak mengubah ide mendasar (dan hebat) dari .NET Core dll.

IMHO, masalah utamanya adalah jenis perubahan drastis ini sebelum RTM tidak baik. Jika ini terjadi dalam waktu beta maka mungkin pengembang/tim tidak akan terlalu terkejut. Pikirkan tentang investasi yang dilakukan orang sejak 2 tahun terakhir . Pikirkan tentang produk/perpustakaan/kerangka saat ini tergantung pada sistem project.json . Asp.Net ada di RC bukan di pratinjau/alfa/beta, jenis perubahan ini merusak kepercayaan pengembang/tim :(.

IMHO, masalah utamanya adalah jenis perubahan drastis ini sebelum RTM tidak baik.

Saya juga berpikir begitu pada awalnya, tetapi sejauh yang saya pahami, ini tidak akan menghasilkan perubahan apa pun pada kode aplikasi Anda. Itu hanya akan memengaruhi file project.json/xproj/csproj Anda dan mereka mengatakan bahwa perubahan itu mungkin otomatis - jadi ini akan mirip dengan langkah migrasi proyek lama yang baik yang telah terjadi berkali-kali ketika Anda memutakhirkan Visual Studio.

BTW Saya selalu berpikir memiliki file project.json dan xproj (yang berisi namespace default untuk template Visual Studio dan beberapa jalur keluaran, jadi Anda harus mengeditnya juga kadang-kadang) aneh.

BTW Saya selalu berpikir memiliki file project.json dan xproj (yang berisi namespace default untuk template Visual Studio dan beberapa jalur keluaran, jadi Anda harus mengeditnya juga kadang-kadang) aneh.

Mungkin aneh tetapi mereka menjawab hal-hal yang berbeda project.json adalah satu-satunya file yang diperlukan untuk membangun proyek inti .net dan xproj terkait dengan perkakas berpemilik alias visual studio. Ini sangat mirip dengan package.json dan .idea jika Anda menggunakan webstorm untuk mengerjakan proyek simpul Anda. Hanya pemisahan kekhawatiran. Visual studio dapat menyembunyikan project.json di bawah Properties jika mereka suka dan menawarkan pengalaman gui yang dikurasi jika mereka suka tanpa mencampur semuanya.

saya telah menggunakan hal-hal ini di mac di VS Code begitu lama sehingga saya lupa semua tentang xproj. OTOH, saya benar-benar melewatkan debugging dan lebih banyak lagi dari Visual Studio!

Saya pikir Anda terlalu pesimis - dan saya rasa itu terutama karena kita semua terkejut dengan ini

Tidak, maaf saya tidak percaya saya terlalu pesimis. XML adalah format yang buruk untuk situasi apa pun di mana Anda akan melakukan penggabungan kode, yaitu semua proyek perangkat lunak. XML tidak dirancang untuk hal-hal seperti file konfigurasi dan file proyek, dan seharusnya tidak pernah digunakan untuk mereka, .NET hanya bernasib buruk untuk dibangun kembali ketika semua orang mengira XML dapat menyelesaikan segalanya.

http://c2.com/cgi/wiki?XmlSucks
http://www.ibm.com/developerworks/xml/library/x-sbxml/index.html
http://nothing-more.blogspot.co.za/2004/10/where-xml-goes-astray.html

Sekarang, .NET Core sedang dibangun ketika semua orang berpikir JSON akan menyelesaikan semuanya. Saya tidak percaya JSON lebih merupakan solusi jangka panjang daripada XML, tetapi saya tahu bahwa lebih mudah untuk menggabungkan konflik JSON daripada yang XML.

Saya telah menemukan angin segar tidak berurusan dengan sampah XML untuk file proyek, saya merasa lebih mudah untuk membaca file JSON, saya telah menemukan file JSON lebih mudah untuk bekerja dengan di luar Visual Studio, dan saya tidak ingin kembali ke XML/MSBuild.

Ya, ini adalah perasaan pribadi saya, dan ya itu subjektif, tetapi berdasarkan komentar di Twitter dan di tempat lain saya tidak percaya itu terisolasi. Sejujurnya, keputusan ini membuat saya benar-benar meragukan seluruh arah .NET Core, dan terutama cara pengambilan keputusan penting seperti ini.

@DamianEdwards dengan jelas mengatakan bahwa mereka ingin mempertahankan bagian yang baik dari model project.json.

Dari sudut pandang saya, bagian terbaik dari model project.json adalah bahwa itu bukan csproj, bukan MSBuild, dan bukan XML. Akankah bagian "baik" itu disimpan? Ternyata tidak. Setelah kami tertipu untuk percaya bahwa mereka akhirnya menjadi kacau, ternyata itu semua salah arah. Kami diberitahu tentang sistem pembangunan baru, tentang Gulp dan project.json dan bagaimana hal-hal akan berbeda sekarang, dan kemudian ternyata itu semua palsu dan MSBuild lama yang jelek kembali lagi.

Saya pikir format JSON dan XML hampir sama dalam hal penggabungan - keduanya memiliki tag penutup (walaupun itu hanya kurung kurawal di JSON) yang berarti Anda memiliki masalah dengan skenario kosong/satu/banyak. Ubah saja array JSON kosong menjadi array dengan item. Saya berpendapat bahwa JSON bahkan memiliki kelemahan tambahan dari koma akhir yang mengubah dua baris jika Anda menambahkan item ke daftar.

Anda harus pindah ke YAML, dll jika Anda ingin menghindarinya.

IMO masalah dengan csproj bukan dengan XML tetapi dengan bagaimana Visual Studio memperlakukannya dan itu berisi setiap file cs. Jika ini diperbaiki dan jika perkakas tidak secara acak mengubah hal-hal dalam file, penggabungan seharusnya tidak menjadi masalah lagi.

Namun, dalam hal keterbacaan saya juga lebih suka JSON. Saya dapat menulis project.json dari awal - saya rasa saya tidak akan lagi dapat melakukannya dengan csproj (csproj memerlukan ProjectGuid acak, dll). Jadi kami pasti membutuhkan dukungan perkakas/baris perintah untuk ini.

Perhatian utama saya tentang semua ini yang belum banyak saya dengar adalah bahwa project.json jauh lebih deklaratif dalam hal referensi daripada file proyek .csproj . Keindahan dependensi dalam file project.json dan mengapa saya berharap untuk memigrasi basis kode kami ke sana adalah Anda hanya mengatakan "Saya membutuhkan dependensi ini" dan tidak masalah apakah itu proyek lokal atau paket NuGet. Dalam kasus kami, ini akan memberi kami banyak fleksibilitas dan opsi baru yang keren. Sebaliknya, saat ini referensi dalam file .csproj adalah jalur relatif keras ke file .dll pada disk. Saat ini, menambahkan entri ke package.config Anda dalam proyek tradisional tidak benar-benar melakukan apa-apa, Anda juga perlu menambahkan referensi ke .dll dari paket itu ke file .csproj . Itu dilakukan untuk Anda oleh alat NuGet di dalam Visual Studio, tetapi saya tidak ingin menggunakan alat itu saat menambahkan sebaris teks ke file project.json jauh lebih sederhana.

Saya menyadari bahwa tim ingin menyimpan semua fungsionalitas yang disediakan oleh file project.json dan memperluas fitur format .csproj , tetapi mereka juga berbicara tentang menyimpan project.json sebagai file untuk menentukan paket NuGet Anda. Saya tidak melihat apa yang akan ditambahkan dibandingkan dengan situasi saat ini dengan packages.config mana hanya menambahkan entri ke dalamnya tidak cukup karena Anda masih perlu menambahkan referensi ke .dll di .csproj juga. Jika file .csproj menjadi masa depan, saya lebih suka melihat tim Inti pergi jauh-jauh dan menjatuhkan project.json atau nuget.json atau bagaimanapun itu akhirnya disebut _seluruhnya_ dan tambahkan cara yang lebih deklaratif untuk menambahkan referensi ke format .csproj . Saya bisa hidup baik-baik saja dengan harus mengedit file XML daripada file JSON (walaupun saya pasti lebih suka JSON) tetapi akan sangat memalukan untuk kehilangan sifat deklaratif project.json dan saya tidak perlu dua tempat yang berbeda di mana saya perlu menentukan dependensi saya.

Tolong beri umpan balik di https://www.surveymonkey.com/r/H6Q88PP

Untuk memperjelas, dalam membaca catatan Standup, disebutkan bahwa salah satu opsi adalah memiliki opsi nuget install --save sort (lihat https://blogs.msdn.microsoft.com/webdev/2016/05/11/ catatan-dari-asp-net-komunitas-standup-mei-10-2016/). Sementara saya pikir itu ide yang bagus, mengganti 'edit file .json dengan intellisense' dengan yang menurut saya adalah ide yang buruk. Saya pikir tinggal di editor adalah ide yang bagus untuk sebagian dari kita yang tidak ingin beralih ke shell untuk melakukan segalanya. Preferensi saya, secara pribadi, adalah memiliki kedua pengalaman tersebut. command-line + UI untuk menambahkan dependensi tidak cukup baik.

Saya seorang pembuat kode, saya tidak ingin meninggalkan editor.

Saya pikir ini adalah keputusan yang mengerikan. Kalian mengatakan bahwa Anda ingin membuat .NET Core benar-benar sederhana, tetapi kemudian Anda membuat perubahan ini. Saya tidak peduli berapa banyak lipstik yang Anda pakai di MSBuild, itu akan tetap menjadi MSBuild dan orang luar akan melihatnya dan segera dimatikan. Ini tidak akan pernah menjadi format sederhana yang dapat diedit dengan tangan. Mungkin ada beberapa masalah teknis yang sulit, tetapi sepertinya itu terkait dengan mencoba membuat sistem proyek menjadi lebih dari sekadar sistem proyek sederhana. Jika orang ingin melakukan hal-hal yang lebih kompleks dalam build mereka, maka mereka dapat menulis beberapa skrip atau menggunakan msbuild untuk melakukannya. project.json adalah hal yang sangat sederhana dan saya benar-benar kecewa sekarang.

Kutipan favorit saya pada file MSBUILD?

Saya baru-baru ini harus menghabiskan banyak waktu dengan file csproj. Mereka terlihat dan berperilaku sangat mirip dengan Ant/Maven. Ini bukan poin yang menguntungkan mereka.
Ant/Maven dicintai dan kemudian dibenci oleh banyak pengembang java. XML adalah sintaks yang sangat verbose yang harus dihadapi.
Tapi pembunuh sebenarnya adalah salah satu dari lockin. Ya, Anda dapat menggunakan msbuild untuk melakukan sesuatu dengannya tetapi sintaksnya benar-benar dirancang bukan untuk dibaca/diedit oleh pengembang tetapi untuk IDE untuk membuat serialisasi status. Hanya karena ada runner baris perintah tidak berarti formatnya ramah pengembang. Selama Anda tinggal di VS, Anda tidak akan benar-benar menyadarinya. Segera setelah Anda pergi meskipun tidak lagi nyaman. File csproj adalah satu hal yang saya harap .Net telah mengambil jalur yang berbeda dari Java.

Sumber

Saya pikir penting untuk membuat perbedaan antara MSBuild dan cara Visual Studio saat ini menggunakan MSBuild. Saya telah mengedit file MSBuild selama bertahun-tahun dan menggunakannya untuk semua proyek saya. Misalnya https://github.com/tavis-software/Tavis.home/blob/master/build/Build.proj

File csproj yang dibuat Visual Studio cukup buruk, tetapi menyalahkan itu pada MSBuild seperti mengatakan C# adalah omong kosong karena Anda melihat pembuat kode membuat kode jelek dengannya sekali.

@darrelmiller saya setuju.

Mari kita gerakkan waktu 6 bulan ke depan dan lihat apakah itu momen "sudah kubilang" atau lebih dari "menghindari peluru".

Mengikuti panggilan @shawnwildermuth di blognya, saya akan memberikan 2 sen saya sendiri:

Saya tidak mengerti mengapa ini adalah masalah besar. Saya senang untuk kembali ke csproj berbasis XML, karena:

• Mengedit JSON secara manual TIDAK lebih alami/lebih mudah daripada XML. Ini sebenarnya kebalikan dari IMHO. Setiap editor bodoh memberi saya penyelesaian tag XML, menemukan kesalahan format secara manual lebih mudah dan seterusnya. JSON tidak mudah jika saya harus menulisnya secara manual. Mengatakan itu membawa saya ke poin 2 ...
• Mengapa ada begitu banyak keributan tentang mengedit file proyek dengan editor di tempat pertama? Mengedit file proyek BUKAN tempat saya ingin menghabiskan waktu saya sebagai pengembang. Ini harus menjadi satu hal di awal proyek baru, tetapi setelah itu seharusnya tidak sering terjadi IMHO. Jika saya harus mengeditnya dengan JSON, XML, YAML, TOML atau apa pun yang diinginkan seseorang saat itu sama sekali tidak relevan bagi saya.
• Satu hal yang ingin saya hindari adalah memasangkan NuGet dengan ASP.NET . NuGet hebat, saya menyukainya dan saya ingin ASP.NET saya bekerja sangat baik dengannya, tetapi TIDAK diperlukan untuk menjalankan ASP.NET. Ya, saya mungkin perlu menarik binari dari umpan NuGet untuk mendapatkan fitur MVC, dll., tetapi apakah saya melakukan ini melalui umpan NuGet resmi, atau jika saya menarik sumbernya, kompilasi secara lokal dan salin tempel ke folder harus menjadi fleksibilitas yang tetap tersedia untuk saya. Saya tidak ingin ASP.NET, csproj atau apa pun digabungkan erat dengan sistem pihak ke-3 yang "mendukung". Saya ingin mereka mengizinkan integrasi yang hebat, tetapi tetap membuka pintu untuk penyesuaian ! Oleh karena itu saya berharap bahwa paket NuGet tidak akan dideklarasikan dalam file .csproj dan nuget.json tidak akan terintegrasi secara erat ke dalam MSBuild.
  Integrasi ketat di balik antarmuka yang terdefinisi dengan baik == HEBAT.
  Kopling ketat, dengan asumsi ini adalah standar untuk semua orang == BURUK.
• Terakhir, saya ingin mengatakan bahwa project.json tidak ada hubungannya dengan .NET Core dan ASP.NET Core. Core memiliki lebih banyak hal untuk ditawarkan daripada file project.json. Project.json bukanlah fitur baru, ini adalah upaya untuk mendesain ulang sesuatu yang sudah ada dalam format yang berbeda. Saya tidak terlalu mempedulikannya, karena sebagai pengembang saya lebih fokus pada fitur dan kemungkinan baru yang diberikan oleh .NET Core untuk mengembangkan aplikasi hebat di cloud daripada konfigurasi membosankan yang harus saya lakukan sesekali.

Saya pikir ini adalah langkah yang bagus untuk kembali ke MSBuild, karena sebagai pengembang saya lebih peduli tentang kompatibilitas dan saya pikir ini adalah kuncinya. MSBuild berfungsi, dan untuk bersikap adil itu bekerja dengan sangat baik untuk sebagian besar dan alih-alih menggantinya dengan sesuatu yang baru, yang membawa masalah baru dan menyebabkan masalah kompatibilitas, saya lebih suka seseorang memperbaiki hal-hal yang sudah berfungsi dan membuatnya lebih baik dari waktu ke waktu. Semua orang berpikir mereka dapat menulis ulang hal-hal dan membuatnya lebih baik, sampai Anda menyadari bahwa Anda hanya memecahkan ruang masalah kecil yang penting bagi Anda pada waktu itu dan kemudian ketika Anda ingin memperluas Anda menemukan diri Anda membangun kembali hal lama yang sama itu Anda mencoba untuk mengganti di awal. Lebih baik memperbaiki hal-hal yang sudah berjalan.

Ini juga mengapa saya mungkin lebih suka membuat Mono lebih baik dan menutup celah daripada menerapkan runtime lintas platform baru, tapi itu diskusi yang berbeda.

Hasil survei akhir: 100 tanggapan, untuk 9 juta populasi pengembang .NET yaitu ±10% dengan kepercayaan 95%.

Apakah Anda suka pindah ke project.json?
Ya, itu adalah salah satu fitur yang paling saya nantikan 19,19%
Ya 39,39%
Tidak 13,13%
Tidak, itu adalah arah yang buruk untuk mengambil 16,16%

Apakah Anda senang pindah kembali ke MSBuild?
Ya, sekarang saya bisa berpikir untuk mengadopsinya 9,09%
Ya 16,16%
Tidak 30,30%
Tidak, ini membuat saya mempertanyakan arah .NET Core mengambil 29,29%
Tidak Peduli 15,15%

Apakah Anda percaya bahwa MSBuild akan ditingkatkan?
ditingkatkan? Ini sudah sempurna. 1,01%
Ya 63.64%
Tidak 12,12%
Ini pada dasarnya rusak, bagaimana bisa diperbaiki? 20,20%
Tidak Peduli 3,03%

Apakah Anda pikir keputusan ini dibuat dengan benar?
Ya, tim menerima umpan balik dan mengubah arah ketika mereka harus 20,41%
Ya 6,12%
Tidak 24,49%
Tidak, tim membuat keputusan tertutup yang tidak dapat dipertanggungjawabkan, tanpa melibatkan masyarakat 39,80%
Tidak Peduli 9,18%

Bagaimana keputusan ini memengaruhi persepsi Anda tentang .NET Core?
Memperbaikinya, mereka akhirnya mencapai kewarasan 13,00%
Meningkatkannya 11,00%
Memburuknya 42,00%
Memburuknya, membuat saya mempertanyakan semuanya 18,00%
Tidak peduli 16%

100 orang melakukan survei. Aku bahkan tidak tahu tentang hal itu sampai sekarang. Mari kita lihat lagi ketika kita memiliki nomor perwakilan, karena paling banyak 100 orang adalah lelucon yang buruk.

Sebenarnya, seperti yang ditunjukkan 100 orang memberi Anda margin kesalahan ±10% dengan kepercayaan 95%. Tingkat kepercayaan apa yang Anda perlukan untuk melihat bahwa Anda melihat bayangan yang sebenarnya? Haruskah kita mensurvei semua 9 juta pengembang?

Apakah 800 suara di UserVoice untuk memperluas project.json ke VS lainnya tidak juga menunjukkan tren?

Dan jika kita akan melakukan sampel yang benar-benar representatif, maka mungkin Microsoft harus melakukannya. Karena mereka tidak pernah meminta masukan tentang keputusan ini, bahkan setelah keluhan berulang dari berbagai arah.

Mereka akan memiliki jangkauan yang jauh lebih baik daripada saya melakukan survei pribadi. Saya perlu memutakhirkan paket SurveyMonkey saya untuk mengakses lebih dari 100 hasil, dengan biaya yang saya tanggung, jadi saya dapat menjalankan survei yang seharusnya dilakukan sendiri oleh Microsoft!

Nah jika Anda ingin memiliki angka yang berarti maka Anda ingin membidik representasi yang adil dari 9 juta pengembang. Jika saya memiliki 100 pengikut Twitter, yang mengikuti saya karena kami memiliki minat yang sama dan saya meminta semua orang untuk mengikuti survei, maka Anda memiliki 100 orang dengan pandangan sepihak yang hanya mewakili satu kelompok pengembang tertentu.

Pembenaran yang diberikan dalam standup untuk menghidupkan kembali MSBUILD adalah untuk memungkinkan integrasi antara alat yang ada dan lebih mudah bagi proyek yang ada untuk menggunakan inti .NET. Namun, setelah memigrasikan proyek yang agak besar ke inti .NET, sejujurnya, sistem proyek adalah yang TERAKHIR dari tantangan saya. Jadi menggunakan itu sebagai satu-satunya pembenaran sepertinya bukan alasan yang bagus bagi saya. Saya juga telah bekerja selama bertahun-tahun dengan sistem csproj termasuk mengedit file secara manual. Itu selalu menyakitkan. Sistem berbasis project.json JAUH lebih sederhana dan lebih mudah didekati oleh semua (termasuk pemula). Saya akan berpikir ini tujuannya. Namun sekarang kami mengambil langkah mundur dengan menghidupkan kembali MSBUILD. Pendapat pribadi saya adalah bahwa ini adalah kesalahan besar. Saya memberikan suara saya untuk mempertahankan project.json.

Sebenarnya saya hampir tidak memiliki pengikut Twitter, mereka sebagian besar adalah pengikut .NET Core devs yang aliran Twitternya saya posting.

Dan sekali lagi, tentunya orang yang tepat untuk melakukan survei seperti itu adalah Microsoft? Mengapa diserahkan kepada saya untuk menjadi satu-satunya yang benar-benar bertanya kepada orang-orang apa yang mereka inginkan?

Mengapa MS tidak peduli dengan apa yang orang pikirkan?

TBH Saya tidak tahu bahwa ada survei hingga 30 menit yang lalu dan saya tidak tahu bahwa Anda melakukan survei secara pribadi. Saya setuju... jika Microsoft tertarik dengan reaksi pengembang terhadap perubahan ini, maka mereka harus menjalankan survei semacam itu. Tapi mungkin mereka sudah mengerjakan pekerjaan rumah mereka dan inilah mengapa mereka membuat perubahan ini. Saya tidak tahu, tetapi saya tidak akan selalu melihat hal-hal secara negatif, karena bagaimanapun juga orang-orang ini membangun barang-barang ini untuk kami, jadi saya yakin mereka hanya memiliki kepentingan terbaik untuk kami.

Jika mereka telah melakukan pekerjaan rumah mereka, mereka akan tahu bahwa 60% pengembang menentang langkah ini, dan akan berkomunikasi dan terlibat sesuai dengan itu. Mereka tidak, yang berarti mereka tidak tahu reaksinya, yang berarti mereka tidak terlibat.

Saya adalah pelanggan yang membayar pada lisensi perusahaan untuk VS. Saya tidak melihat apapun. Saya bekerja di empat perusahaan jasa keuangan blue chip, juga membayar pelanggan perusahaan. Mereka tidak melihat apa-apa. Jadi siapa sebenarnya yang mereka terlibat dengan? Saya sudah menanyakan pertanyaan itu sejak tadi malam dan belum menerima tanggapan apa pun.

Saya melihat hal-hal negatif karena ini adalah perubahan besar-besaran yang terlambat ke bagian mendasar dari cerita .NET Core, bagian yang dikomunikasikan kepada kami sebagai inti masa depan, dan kami (mungkin dengan bodohnya) membawanya word, dan telah membangun saluran CD/CI berdasarkan teknologi ini yang sekarang sama sekali tidak berharga. Saya juga melihatnya secara negatif karena dalam sehari penuh menanyakan detail pengambilan keputusan, ada keheningan radio total.

Kedengarannya, dari apa yang saya dengar, bahwa mereka telah melemparkan pengguna ke bawah bus untuk membantu pembuat alat. Jika demikian, tolong bisakah mereka mengumpulkan biaya lisensi VS saya dari pembuat alat, dan bukan dari saya.

@shederman Meskipun saya setuju dengan hasil survei Anda, pertanyaannya jelas condong ke arah yang lebih disukai untuk tetap dengan format json, dan itu tidak benar-benar menjadikannya survei yang bagus. Saya menganggapnya sebagai kesenangan, dan saya tidak akan menganggap serius hasilnya (maaf). Saya bertanya-tanya mengapa kita tidak dapat memiliki keduanya - menjadikannya opsional dengan satu atau lain cara, karena saya bukan penggemar msbuild atau hal-hal lain itu. Saya suka json, itu teman saya.

Saya setuju dengan Anda bahwa ini bukan survei yang ideal. Saya membuatnya dalam waktu 5 menit. intinya adalah: mengapa saya membuatnya?

Mengapa Microsoft tidak tertarik untuk mengetahui pendapat orang?

Saya hanya mengharapkan sekitar 30 tanggapan, dan saya berharap itu akan cukup untuk meyakinkan mereka untuk membuka kembali diskusi, berbagi pemikiran mereka secara terbuka dan terlibat dengan kami dengan benar daripada memaksakan pendapat secara kasar.

Sekarang ada 138 tanggapan, tetapi masih belum ada tanda-tanda dari Microsoft bahkan mempertimbangkan bahwa mungkin keputusan mereka adalah keputusan yang buruk. Hanya penjelasan lambaian tangan yang sangat samar yang tidak didukung oleh fakta.

Yang saya inginkan hanyalah keterlibatan yang tepat pada keputusan ini. Bukan keputusan besar yang dibuat di balik pintu tertutup berdasarkan informasi rahasia dan umpan balik. Ini harus dibuat secara terbuka dan transparan, sebuah kata yang selama ini hilang dalam proses ini.

Ayolah. Microsoft memiliki kerangka kerja dan memungkinkan dia untuk melakukan apa yang dia inginkan. Tapi pikirkan sejenak, orang-orang sedang mengerjakan ini sejak Maret-April 2014 dan tepat sebelum 1 bulan rilis membuat perubahan dramatis semacam ini konyol. Itu merusak kepercayaan pengembang. Itu membuang-buang waktu orang. Tidak perlu membuat kerangka kerja sumber terbuka jika Anda tidak dapat mempercayai komunitas. Pergi dan tutup sumbernya segera sehingga tidak ada yang akan mengganggu Anda saat Anda melakukan perubahan semacam ini di ruangan gelap.

Saya meminta maaf dan simpatik Microsoft (MVP atau Anggota Komunitas) harap realistis saat ini.

@shederman

Jika mereka menyelesaikan pekerjaan rumah mereka, mereka akan tahu bahwa 60% pengembang menentang langkah ini,

Akan mengejutkan saya jika lebih dari 20% pengembang di ekosistem .net mengetahui keberadaan project.json. Terkadang kita lupa bahwa kita hidup dalam sedikit gelembung pengembang, yang berada di garis depan perkembangan teknologi baru.

Saya percaya sebagian besar daya tarik project.json adalah kesederhanaannya. Namun, jika Anda telah mengikuti perkembangannya sejak pertama kali diperkenalkan pada hari ASP Net Insiders 3 tahun yang lalu, ia telah mulai mengumpulkan lebih banyak kerumitan karena mencoba mendukung lebih banyak kasus penggunaan. Untuk mendukung seluruh ekosistem .net, saya khawatir banyak dari kesederhanaan tercinta akan hilang.

Ini bukan berarti project.json tidak menghadirkan beberapa fitur baru yang mengagumkan, dan saya yakin membuat format proyek lebih mudah diakses manusia adalah hal yang baik. Namun, saya pikir membawa kebaikan itu ke MSBuild lebih dapat dicapai dan akan menguntungkan lebih banyak orang lebih cepat daripada mencoba membawa project.json ke mana-mana.

Akan mengejutkan saya jika lebih dari 20% pengembang di ekosistem .net mengetahui keberadaan project.json.

Saya berani bertaruh kurang dari 20% pengembang di .net eco tahu tentang MVC dan Web Api. Lebih dari 70 orang menggunakan WebForms, WCF, WebService. Sekali lagi saya meminta maaf dan simpatik Microsoft, harap realistis

@shederman Laporan Anda tentang kepercayaan apa pun dari hasil survei Anda mungkin salah untuk populasi pengembang .NET pada umumnya, dan bahkan mungkin bukan sampel perwakilan yang baik dari ... "mereka sebagian besar adalah pengikut .NET Core devs yang aliran Twitternya saya posting." Sampel Anda bukan sampel acak , yang mutlak diperlukan bagi Anda untuk menyatakan selang kepercayaan seperti yang Anda maksudkan untuk populasi secara keseluruhan. Bahkan jika itu adalah sampel acak pengembang .NET, Anda tidak dapat melaporkan kepercayaan 95% dalam setiap jawaban karena Anda gagal menyesuaikan inferensi simultan.

Tidak ada kesimpulan statistik yang berguna yang dapat ditarik berdasarkan survei Anda untuk populasi secara keseluruhan. Namun, saya senang Anda melakukan survei. Anda menyajikan banyak poin yang sangat baik. Saya pikir hasilnya memang menunjukkan bahwa banyak orang kecewa atau khawatir tentang perubahan itu. Namun, tolong jangan publikasikan kesimpulan statistik yang salah ... memberikan angka yang hampir tidak berarti dan membuat pernyataan keterlaluan seperti "mereka akan tahu bahwa 60% pengembang menentang langkah ini."

Lalu apa gunanya mengubah sesuatu jika kita akan mengganggu 70%+ dari basis pasar? Mari kita tetap di tempat kita dan terus melakukan evolusi inkremental. Jika tidak rusak tidak memperbaikinya, kan?

Saya tahu bahwa project.json telah mengumpulkan kompleksitas. Saya 100% setuju dengan poin itu. Apakah solusi untuk menggabungkan kembali ke csproj? Saya memberi tahu orang-orang sebelumnya, saya sepenuhnya mendukung Microsoft untuk membuat segalanya benar daripada mengirim dengan tergesa-gesa. Perpindahan ke csproj terlihat terburu-buru.

Mengapa melakukan ini setelah RC2? Dari mana ini berasal? Apakah akuisisi Xamarin ada hubungannya dengan ini? Apakah itu integrasi dotnet-cli ? Apakah itu klien besar? Siapa tahu...

Saya bisa menjelaskan kepada massa bahwa RC1 -> RC2 adalah yang terbaik. Disatukan dengan dotnet cli. Tetapi project.json berubah? Saya tidak punya apa-apa untuk dikatakan untuk menjelaskannya. Hanya saja saya tidak tahu. Orang-orang bingung dan saya tidak punya argumen yang meyakinkan untuk mereka.

Mengapa melakukan ini setelah RC2? Dari mana ini berasal? Apakah akuisisi Xamarin ada hubungannya dengan ini? Apakah itu integrasi dotnet-cli? Apakah itu klien besar? Siapa tahu...

Ini adalah titik pemikiran. Kami tidak tahu cerita lengkap di balik perpindahan ke csproj. Sekarang alih-alih bersandar, bersantai dan menonton dan memahami mengapa ini terjadi, semua orang mengutuk Microsoft dan mengasumsikan yang terburuk. Ini tidak masuk akal. Orang-orang ini sedang membangun barang-barang ini untuk kita dan kita saja. Mereka pasti tidak melakukan perubahan seperti itu karena 1 pelanggan besar, karena 1 pelanggan besar tidak ada artinya jika Anda berisiko kehilangan seluruh komunitas Anda. Sistem eko ​​Microsoft .NET adalah HUUUUUUGE dan membuat .NET Core cocok dengan itu jelas merupakan tugas yang kompleks, jadi saya akan menyarankan semua orang untuk sedikit bersantai dan berasumsi bahwa orang-orang ini memiliki beberapa orang pintar di belakangnya, membuat keputusan yang tepat sehingga kita bisa mendapatkan keuntungan paling banyak darinya - jangka panjang. Saya keluar dari sini, karena semua spekulasi prematur negatif ini membuat saya bosan.

@darrelmiller Maaf, ketika saya mengatakan 60%, maksud saya 60% dari mereka yang menanggapi survei.

@GuardRex Anda benar sekali. Satu-satunya organisasi yang bisa memberi kami hasil yang tepat adalah MS, dan mereka tampaknya tidak peduli.

Survei saya hanya dimaksudkan untuk mengukur tingkat dukungan yang tidak jelas, bukan untuk memberikan sampel yang signifikan secara statistik. Saya percaya saya telah menunjukkan bahwa ada cukup ketidakbahagiaan untuk membuka keputusan ini, tetapi tampaknya Microsoft tidak setuju, baik jika keheningan radio mereka adalah indikasi.

Inilah pertanyaannya: apa sebenarnya yang dibutuhkan MS untuk mengakui bahwa mereka mungkin melakukan kesalahan? Apa yang diperlukan untuk membuat mereka membuka kembali diskusi? Karena pada saat ini sepertinya jawabannya adalah "kami tidak peduli dengan sudut pandang Anda, keputusan kami tetap, dan kami tidak akan membagikan alasannya"

Saya menyarankan semua orang untuk sedikit bersantai dan berasumsi bahwa orang-orang ini memiliki beberapa orang pintar di baliknya, membuat keputusan yang tepat sehingga kita dapat memperoleh manfaat maksimal darinya - jangka panjang

Itulah yang saya katakan menjadikannya sumber dekat karena orang-orang pintar di belakangnya dan mereka selalu benar dan komunitas open source itu bodoh.

@shederman "tidak memberikan sampel yang signifikan secara statistik" ... tidak apa-apa, tapi saya berharap Anda membiarkan survei berdiri sendiri dan menghapus baris ini ...

Hasil survei akhir: 100 tanggapan, untuk 9 juta populasi pengembang .NET yaitu ±10% dengan kepercayaan 95%.

Itulah bagian yang menjadi sangat tidak pasti. Mungkin akurat bahwa 60% pengembang .NET membenci atau tidak menyukai perubahan ini; namun, Anda tidak dapat menunjukkannya dengan sampel itu. Anggap saja, ya, banyak pengembang memiliki perhatian besar tentang perubahan dan cara penanganannya. Itu jelas, dan survei benar-benar menyoroti hal itu dengan baik.

@abcplex : Open source tidak berarti Anda harus melompat setiap kali 16 orang membuka masalah di GitHub dan berteriak melompat.

@MaximRouiller Catatan Standup melakukan pekerjaan yang cukup baik untuk menjelaskan motivasi untuk perubahan. Dan kenyataannya, saat saya membacanya, xproj digantikan oleh csproj dan project.json kemungkinan akan diganti namanya menjadi nuget.json dan _some_ stuff akan dipindahkan dari project.json.

Dan dari komentar yang dibuat di standup, ini adalah keputusan yang cukup baru, komunitas telah diberitahu segera, project.json tidak akan kemana-mana sampai setelah RTM, sehingga perubahan bisa terjadi lagi.

Bagi saya, ini tampak seperti proses paling inklusif dan transparan yang mungkin bisa terjadi.

@darrelmiller Itu, saya harus setuju dengan Anda. Cukup transparan.

Jika mereka menginginkan umpan balik, saya pikir mereka mendapatkannya. Bagaimanapun, tidak ada yang melawannya. Orang-orang berbicara. Microsoft mendengarkan. Mari kita lihat apakah itu sesuatu yang bisa mereka lakukan atau tangan mereka terikat.

Hanya waktu yang akan memberitahu kita sekarang.

Saya tidak berpikir masalahnya ada pada transparansi mereka. Mereka telah melakukan pekerjaan yang luar biasa untuk menjadi transparan. Saya pikir masalahnya adalah mereka membuat keputusan besar tanpa mengetahui apa yang dipikirkan masyarakat tentang hal ini. Saya tahu tidak mungkin untuk merancang oleh komite, tetapi mungkin mereka harus mendokumentasikan daftar pro dan kontra yang mereka bahas dan mempresentasikannya kepada komunitas untuk sesuatu yang mendasar seperti perubahan ini. Mudah-mudahan mereka akan segera memposting info semacam itu, tetapi, meskipun demikian, sepertinya keputusan telah dibuat.

Ini mempengaruhi pengadopsi awal lebih dari siapa pun.

JSON terbaca bagus, tetapi hanya jika sederhana. </system> lebih mudah dipahami daripada ]} menurut saya.

Komentar paling masuk akal di sini menggemakan pemikiran saya sendiri tentang pembongkaran/pemuatan proyek dan manajemen ketergantungan yang tidak memerlukan verbositas yang melekat dalam XML.

Haruskah itu benar-benar menjadi diskusi tentang JSON vs. XML? Tidak terlalu penting IMHO
(tentu, secara pribadi saya lebih suka JSON daripada XML tetapi ini tidak penting)

Yang sangat saya sukai dari ASP.NET Core adalah, cukup terbuka dan independen dari Visual Studio dan IDE lainnya. Jika ini masih diberikan, saya tidak masalah dengan keputusan ini.

Ada cukup banyak diskusi beracun yang terjadi dalam masalah ini, yang menurut saya menyebabkan banyak orang kehilangan pandangan. Argumen umum tampaknya "MSBuild buruk!" tetapi tidak cukup pemahaman tentang apa yang baik / buruk tentang kedua pendekatan yang sedang dibuat.

Untuk semua orang yang menyatakan bahwa ini adalah "langkah mundur", ketahuilah bahwa meskipun itu akan kembali ke "csproj", itu tidak akan _sama_ dengan file csproj yang kami miliki selama bertahun-tahun. Pertama, mereka telah menyatakan dengan jelas bahwa Anda tidak akan melihat daftar file dalam format csproj "baru". Manfaat utama dan alasan utama kebanyakan orang menyukai format project.json adalah karena tidak memiliki daftar file ini.

Segera itu perbedaan langsung. Lihatlah xproj hari ini dan Anda akan memiliki gambaran tentang apa yang diharapkan dari csproj "baru". Ini akan menjadi sedikit lebih besar, tetapi hanya karena itu akan memiliki beberapa properti tambahan yang diambil dari project.json. Diskusi sebenarnya bukan dan tidak seharusnya tentang "seberapa buruk MSBuild" tetapi apa yang ingin Anda lihat di csproj baru dan apa yang ingin Anda tinggalkan di file .json.

@dustinmoris Anda tidak adil, saya pikir komunitas menyambut sebagian besar perubahan tetapi yang ini. Yang ini membawa kita ke belakang, dan mereka sudah berbicara tentang bagaimana mereka akan melakukannya tanpa pemahaman tentang alasannya. Mereka membuatnya terdengar seperti keputusan sudah final sehingga tidak ada tempat bagi komunitas untuk mengajukan proposal yang lebih baik.

Dan ya kami mengedit file proyek secara langsung dan kami melakukannya dengan susah payah sebelum project.json. Msbuild adalah tentang pengetahuan kesukuan dan membuatnya agak sulit untuk dikuasai.

Dan "ini akan memudahkan migrasi dari .net 4.5 ke .net core" tampaknya agak tidak jujur. Ini jelas bukan titik sakitnya...

itu tidak akan sama dengan file csproj yang kami miliki selama bertahun-tahun.

Apakah ini akan menjadi XML? Ya, saya pikir begitu.

Manfaat utama dan alasan utama kebanyakan orang menyukai format project.json adalah karena tidak memiliki daftar file ini.

Berdasarkan informasi apa Anda mengatakan ini? Maksud saya, tidak memiliki daftar file adalah nilai tambah utama, tetapi tidak berarti satu-satunya bagi saya.

Lihatlah xproj hari ini dan Anda akan memiliki gambaran tentang apa yang diharapkan dari csproj "baru"

Saya tidak punya xproj hari ini. Mengapa saya membutuhkan hal seperti itu?

Diskusi sebenarnya bukan dan tidak seharusnya tentang "seberapa buruk MSBuild"

Mengapa _tidak_ yang menjadi diskusi? Turfing MSBuild adalah poin plus utama untuk adopsi .NET Core saya. 20% responden di (tampaknya) tidak ilmiah, ruang gema, survei bias setuju bahwa itu pada dasarnya rusak.

@shederman tanggapan Anda persis seperti diskusi beracun yang saya maksud. Anda hanya membuat klaim umum (seperti "MSBuild buruk!") Tetapi Anda tidak mendukungnya dengan diskusi konstruktif apa pun.

Apakah ini akan menjadi XML? Ya, saya pikir begitu.

Ya. Dan? Jika masalah Anda adalah Anda tidak menyukai _XML_, maka cukup adil. Jika menurut Anda JSON lebih unggul daripada XML, lanjutkan dan jelaskan alasan Anda, tetapi itu tidak ada hubungannya dengan _project structure_ dan semua yang berkaitan dengan sintaksis. Sayangnya untuk Anda, XML dan JSON memiliki tempat masing-masing di dunia, ada pro dan kontra yang berbeda untuk keduanya dan tidak akan pernah ada jawaban "benar" yang pasti tentang mana yang lebih baik. Sekali lagi, jika saya jadi Anda, saya akan berkonsentrasi pada perbedaan dalam _struktur proyek_ dengan perpindahan tersebut.

Berdasarkan informasi apa Anda mengatakan ini? Maksud saya, tidak memiliki daftar file adalah nilai tambah utama, tetapi tidak berarti satu-satunya bagi saya.

Saya tidak pernah mengklaim itu adalah satu-satunya manfaat, saya hanya mengatakan bahwa itu adalah manfaat _main_. Lihatlah diskusi apa pun tentang format project.json sejak beberapa bulan yang lalu dan hal pertama yang dibicarakan orang adalah seberapa kecil dan sederhananya. Itu bukan karena JSON secara sintaksis lebih bersih, itu karena penghapusan daftar file proyek. Nilai tambah terbesar yang disebutkan orang adalah bahwa itu menyatu dengan baik dan menyatu dengan baik karena tidak mencantumkan banyak referensi file di dalamnya.

Saya tidak punya xproj hari ini. Mengapa saya membutuhkan hal seperti itu?

Seluruh diskusi ini adalah tentang format file proyek yang lebih baru, jika Anda tidak mau membandingkan lanskap saat ini, maka pendapat Anda akan menjadi kurang informasi.

Mengapa tidak seharusnya itu menjadi diskusi? Turfing MSBuild adalah poin plus utama untuk adopsi .NET Core saya. 20% responden di (tampaknya) tidak ilmiah, ruang gema, survei bias setuju bahwa itu pada dasarnya rusak.

Karena Anda tidak benar-benar membahas _MSBuild_, Anda mendiskusikan cara Visual Studio menangani proyek MSBuild secara historis - yang diakui Microsoft sendiri buruk. MSBuild sebenarnya sudah mendukung hampir semua yang diperlukan - termasuk tidak harus membuat daftar setiap file dalam sebuah proyek.

Lebih penting lagi, semua yang telah Anda lakukan sejauh ini dalam diskusi ini adalah berteriak dan berteriak bahwa Anda tidak menyukai XML, tapi saya belum melihat Anda membawa argumen nyata untuk atau menentang "Itu tidak bergabung sebagai baik", yang seperti yang telah saya nyatakan berkali-kali sekarang umumnya tergantung pada jumlah file yang terdaftar di csproj "lama". Jika Anda ingin melihat format xproj, Anda akan melihatnya cukup kecil dan Daniel mengatakan selama standup bahwa format csproj "baru" akan memiliki ukuran yang sama dengan file project.json saat ini - jadi sekali lagi, apa masalah? Anda membuat klaim yang berani, tetapi Anda tidak mendukungnya sama sekali.

@neoKushan Anda harus segera mendapatkan semacam penghargaan dari Microsoft dengan membela mereka tanpa alasan yang baik. Sampai pada titik nyata bahwa ini adalah keputusan terburuk yang dibuat di pintu belakang. Saya merekomendasikan untuk membuat asp net close source lagi dan mengizinkan Microsoft dan pendukung mereka seperti Anda untuk memutuskan apa yang kemudian diinginkan tanpa meminta anggota komunitas open source

@abcplex Apakah Anda akan berkontribusi apa pun untuk percakapan selain panggilan nama dan penunjuk jari?

Sejauh ini Anda tidak melakukan apa-apa selain mengeluh tentang perubahan itu tanpa mencantumkan satu alasan pun apa masalah Anda yang sebenarnya.

@neoKushan poin terbesarnya adalah ini bukan saatnya untuk jenis perubahan ini, hanya sebulan yang lalu ke RTM. Membuat perubahan ini kali ini tidak masuk akal.

@abcplex Perubahan tidak terjadi di RTM. Ini akan menjadi perubahan bertahap pasca-RTM . Semua yang terjadi di RTM adalah xproj Anda diganti namanya menjadi csproj - secara harfiah tidak ada perubahan lain dan perubahan akan dilakukan secara bertahap, dengan alat yang memigrasikan perubahan Anda untuk Anda.

Setuju bahwa JSON vs XML (vs XAML, seperti pada Standup Blog Post beberapa orang menanyakan hal itu) adalah gangguan dari apa yang seharusnya menjadi manfaat memiliki segala jenis kompatibilitas mundur dengan perkakas sebelumnya.

Dan saya berpendapat bahwa ini adalah cara berpikir yang sangat salah arah. Suka atau tidak suka, csproj dan MSBuild mengikuti tradisi semut, yaitu tentang menginstruksikan toolchain bagaimana membangun sebuah proyek, daripada mendefinisikannya. Ini adalah hal yang sangat berbeda, tetapi warisan ini tampaknya memberi kekuatan "definisi" proyek, karena sekarang kita dapat menerapkan logika padanya, dan seterusnya. Apa yang dilakukannya adalah membuat segalanya menjadi sangat rumit.

Dengan dunia lama, pada banyak kesempatan saya telah melihat file proyek rusak hanya karena baris yang "harus berada di bawah" dipindahkan ke atas, atau seseorang mengacaukan variabel lingkungan dan tiba-tiba kami menarik file .target yang salah. Gagasan bahwa elemen Tingkat Pertama (anak-dari-root) bergantung pada urutan dalam sintaksis deklaratif benar-benar rusak. Itu adalah tanah MSBuild dan csproj. Ini adalah warisan yang kami bawa kembali ke sini. Sekarang untuk memahami csproj, seseorang harus "menjalankannya", dan menjalankannya persis seperti yang dilakukan MSBuild. Ya, MSBuild adalah open-source, tetapi itu tidak benar-benar memperbaiki apa pun. Itu masih memperkenalkan ketergantungan tunggal yang dipaksakan. Itu masih bergantung pada file target ajaib yang ada... di suatu tempat.

File proyek harus memiliki beberapa kualitas yang membuatnya tidak sesuai dengan bentuk rantai alat yang diputuskan untuk digunakan oleh toko tertentu:

• Itu harus dapat diedit/dibaca oleh manusia
• Itu harus memungkinkan untuk komentar
• Itu harus deklaratif
• Itu harus mandiri
• Itu harus dirancang untuk mengurangi konflik penggabungan / menyederhanakan penggabungan, jika memungkinkan
• Itu harus sepenuhnya dapat didokumentasikan (dengan prinsip self-containment berlaku untuk dokumentasi)
• Itu harus tidak bergantung pada alat

Dan "ini akan memudahkan migrasi dari .net 4.5 ke .net core" tampaknya agak tidak jujur. Ini jelas bukan titik sakitnya...

Setuju 100%. Biar saya perjelas apa tantangan bagi kami: satu-satunya kesulitan sejauh ini dengan migrasi basis kode adalah hilangnya perpustakaan kelas .NET tertentu (melihat Anda System.Drawing), keengganan tim Microsoft dalam mendukung inti .NET (melihat Anda DocumentDB) dan perubahan standar yang dapat diharapkan antara versi utama.

Project.json tidak menjadi masalah. Bahkan, itu salah satu manfaatnya. Ditto mampu membuang MSBuild ke detail tak terlihat yang secara ajaib terjadi ketika Ctrl+Shift+B.

@neoKushan

1. Saya tidak suka XML. Ini adalah format yang buruk untuk file proyek dan konfigurasi. Itu adalah ide yang buruk ketika diperkenalkan selama fase "XML untuk semuanya", dan itu adalah ide yang buruk sekarang.
2. Saya menemukan bahwa file JSON bergabung jauh lebih baik daripada file XML. Saya menerima bahwa ini adalah pendapat, tetapi ini milik saya, dan berdasarkan pengalaman saya.
3. Saya menggunakan vscode yang tidak membutuhkan dan tidak menggunakan file xproj. _Itu_ adalah lanskap saya saat ini, dan saya tidak ingin atau membutuhkan file xproj yang tidak berarti apa-apa bagi saya.
4. Tidak, saya sedang mendiskusikan MSBuild. Saya telah melakukan banyak hal dengan MSBuild dan Team Build. Mereka tidak pernah menyenangkan, dan tidak pernah mudah, dan selalu terlibat gulat dengan babi di lumpur. Saya _hate_ MSBuild, dan saya pasti tidak sendirian.
5. MSBuild membuat tugas-tugas sederhana menjadi sulit. Saya sarankan Anda melihat alternatif, dan tidak perlu ditutup-tutupi oleh MSBuild. Terutama, lihat cara kerja gulp dan sbt.

@shederman

Saya tidak suka XML. Ini adalah format yang buruk untuk file proyek dan konfigurasi. Itu adalah ide yang buruk ketika diperkenalkan selama fase "XML untuk semuanya", dan itu adalah ide yang buruk sekarang.

Tak satu pun dari ini menjelaskan _why_ itu ide yang buruk.

Saya menemukan bahwa file JSON bergabung jauh lebih baik daripada file XML. Saya menerima bahwa ini adalah pendapat, tetapi ini milik saya, dan berdasarkan pengalaman saya.

Saya mengalami mimpi buruk penggabungan .json dan penggabungan mimpi buruk .xml, saya juga tidak terlalu disayangi dalam hal penggabungan. Dalam pengalaman saya, kemungkinan penggabungan yang bermasalah meningkat dengan _size_ file, apa pun formatnya.

Saya menggunakan vscode yang tidak membutuhkan dan tidak menggunakan file xproj. Itu adalah lanskap saya saat ini, dan saya tidak ingin atau membutuhkan file xproj yang tidak berarti apa-apa bagi saya.

Itu tidak berarti Anda tidak bisa pergi dan melihat file xproj saat ini untuk mendapatkan gambaran tentang apa itu. Dengan tidak melakukannya, Anda melakukan hal yang sama dengan menempelkan jari Anda di telinga, menutup mata dan mengatakan "La la la".
Dengan kata lain, Anda bisa kesal karena ada perubahan yang terjadi dan mengeluh tentang hal itu, tidak mencapai apa-apa, atau Anda dapat mengambil bagian dalam percakapan yang sebenarnya dan membantu mengarahkan hasil dari ini.

Misalnya, satu hal yang masih belum diputuskan adalah apakah dependensi nuget akan menjadi bagian dari csproj, atau apakah itu akan menjadi nuget.json - ada preferensi Anda di sana. Setelah Anda memiliki daftar dependensi dalam file .json, apa yang tersisa di csproj? Seberapa sering itu akan berubah? Seberapa sulitkah _that_ untuk digabungkan?

Saya pribadi lebih suka bahwa itu semua terkandung dalam satu file proyek, tetapi saya dapat melihat daya tarik dan manfaat memisahkan nuget dari proyek itu sendiri. Ada pro dan kontra untuk keduanya dan mungkin solusi terbaik adalah mengizinkan keduanya, memiliki csproj dengan daftar dependensi tetapi juga membiarkan Anda menunjuk ke file .json dengan dependensi Anda sebagai gantinya. Yang terbaik dari kedua dunia dan semua orang menang, dengan mengorbankan beberapa kompleksitas tambahan pada MSbuild itu sendiri.

Tidak, saya sedang mendiskusikan MSBuild. Saya telah melakukan banyak hal dengan MSBuild dan Team Build. Mereka tidak pernah menyenangkan, dan tidak pernah mudah, dan selalu terlibat gulat dengan babi di lumpur. Saya benci MSBuild, dan saya pasti tidak sendirian.

Karena harus berurusan dengan definisi build berbasis XAML TFS, saya setidaknya bisa setuju dengan Anda tentang (beberapa) yang satu ini.

MSBuild membuat tugas-tugas sederhana menjadi sulit. Saya sarankan Anda melihat alternatif, dan tidak perlu ditutup-tutupi oleh MSBuild. Terutama, lihat cara kerja gulp dan sbt.

Kemudian saya sarankan Anda berhenti membuang mainan Anda dari kereta bayi dan secara aktif mengambil bagian dalam diskusi tentang seperti apa struktur proyek "baru" itu _sebenarnya_. Bayangkan masa depan di mana Anda harus berurusan dengan file proyek berbasis XML, Anda ingin file proyek itu seperti apa?

Bayangkan masa depan di mana Anda harus berurusan dengan file proyek berbasis XML

Um. Oke, jadi saya harus membayangkan masa depan yang tidak saya inginkan dan menjelaskan kepada Anda bagaimana cara kerjanya? Um, tidak, saya tidak berpikir begitu. Bagaimana kalau kita lebih suka melihat beberapa sistem pembangunan yang modern dan lebih inovatif. Anda tahu, yang meninggalkan XML di masa lalu.

Bagaimana tentang:

var gulp = require('gulp')
, minifyCss = require("gulp-minify-css");

gulp.task('minify-css', function () {
    gulp.src('./Css/one.css') // path to your file
    .pipe(minifyCss())
    .pipe(gulp.dest('path/to/destination'));
});

Atau mungkin

organization := "com.devdaily"

name := "ScalatraTest1"

version := "0.1.0-SNAPSHOT"

scalaVersion := "2.9.1"

seq(webSettings :_*)

libraryDependencies ++= Seq(
  "org.scalatra" %% "scalatra" % "2.0.4",
  "org.scalatra" %% "scalatra-scalate" % "2.0.4",
  "org.scalatra" %% "scalatra-specs2" % "2.0.4" % "test",
  "ch.qos.logback" % "logback-classic" % "1.0.0" % "runtime",
  "org.eclipse.jetty" % "jetty-webapp" % "7.6.0.v20120127" % "container",
  "javax.servlet" % "servlet-api" % "2.5" % "provided",
  "com.mongodb.casbah" %% "casbah" % "2.1.5-1"
)

resolvers += "Sonatype OSS Snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"

Oh ya, itu xproj Anda terkait dengan jauh lebih baik. Bagus dan jelas dan ringkas. Dan ekspresif, jangan lupa ekspresif. Untuk apa ProjectGuid itu? Dan saya suka 90 karakter untuk mengatur versi alat. Dan DnxInvisibleContent? Itu berguna untuk diketahui oleh sistem build saya? File mana yang tidak ditampilkan di IDE yang tidak saya jalankan?

Saya sarankan Anda berhenti membuang mainan Anda dari kereta bayi

Gak mau :-)

Nah, saya sudah selesai. Sudah lama mengobrol dengan Immo, dan saya sudah selesai bertarung dalam pertempuran ini. Setiap orang memiliki pandangan parsial dan tidak ada yang mau mendengarkan konsep keterlaluan bahwa cara mereka mungkin tidak sempurna untuk semua orang.

[Diedit untuk menghilangkan kekesalan]

@shederman : Anda tampilkan di sini membangun file definisi; Saya ingin menjauh dari definisi build sebagai definisi proyek. Ada ruang untuk mendefinisikan detail statis tentang proyek/artefak yang akan dihasilkan terlepas dari instruksi cara membuatnya. Itu menggabungkan keduanya adalah salah satu masalah utama dalam menggunakan file MSBuild sebagai file proyek.

Saya ingin dapat menentukan hanya informasi yang diperlukan untuk menggambarkan artefak yang akan dibuat dan dependensi dan rantai alat yang akan digunakan, dan tata letak berbagai elemen yang membentuk proyek pada disk. Segala sesuatu yang lain harus terpisah. Jika Anda ingin menggunakan MSBuild di bawah tenda, silakan saja. Ditto jika Anda lebih suka tegukan, atau babel atau apa-apa-Anda. Bagi saya itulah tujuan project.json. (Namun, saya bukan penggemar kemampuan untuk mendefinisikan perintah di sana)

Ya, itu masuk akal. Itu adalah salah satu hal yang saya suka tentang project.json. Ini mendefinisikan "apa", bukan "bagaimana". Dengan meletakkan terlalu banyak hal dalam satu file, kita membuat file menjadi terlalu rumit, terutama jika IDE kita bodoh. Dan hal itu tidak diperlukan untuk editor dan IDE sederhana.

Dari UI upacara rendah seperti VS Code tidak banyak membutuhkan sistem proyek. Itu semua dibangun. Banyak yang bersifat deklaratif, mengatakan apa yang harus dibangun dan metadata. Beberapa mungkin penting, mengatakan langkah-langkah apa yang harus dilakukan.

Ya, masalah terbesar MSBuilds adalah mencoba melakukan semuanya dalam satu sistem.

Saya kira apa yang tidak saya pahami adalah ini: tunjukkan beberapa kasus penggunaan yang ditingkatkan dengan menggunakan MSBuild sebagai sistem proyek yang bertentangan dengan hanya membuat project.json berfungsi. Saya tidak melihatnya. Mungkin kasus penggunaan saya terlalu sederhana, jadi tunjukkan beberapa.

@shederman Catatan standup menyebutkan

Jadi...ini adalah proyek Sumber Terbuka, dan saya tahu bahwa Microsoft adalah "kekuatan yang ada" tetapi jika ini sangat penting bagi orang-orang, maka - dan saya mengerti bahwa saya mengajukan pertanyaan bodoh di sini - berapa lama /effort/energi perlu dikeluarkan untuk memungkinkan .NET Core terus menggunakan project.json sebagai alternatif untuk MSBuild? Jika cukup banyak orang yang berkontribusi, dan kodenya cukup bagus, lalu mengapa MS tidak menerimanya ke dalam proyek ini? Bagian dari keindahan (dan kejatuhan) Open Source adalah ancaman pemalsuan kode jika pengelola utama menolak terlalu banyak dari apa yang ditawarkan oleh orang lain. Bagian dari inti kode menjadi Open Source bukan hanya untuk dilihat, tetapi juga untuk dimodifikasi dan ditingkatkan.

Pendapat pribadi saya tentang perubahan itu adalah bahwa itu ada hubungannya dengan Xamarin, dalam hal ini tentang rencana masa depan. Juga, dalam stand-up baru-baru ini, saya yakin saya mendengar mereka mengatakan bahwa mereka ingin membangun aplikasi konsol menjadi warga negara kelas satu. Ingat bahwa awalnya, .NET baru (ASP.NET 5 + DNX) difokuskan pada pembuatan aplikasi web, sekarang lebih dari itu. Semua ini terjadi relatif baru-baru ini, tim .NET dan ASP.NET bergabung, dan juga pembelian Xamarin. Mereka sampai pada kesimpulan bahwa mereka membutuhkan sistem proyek yang lebih baik untuk mendukung beberapa skenario ini (dan skenario masa depan baru yang tidak akan saya spekulasikan di sini), dan mereka juga ingin segera mengirimkan .NET Core. Apa yang harus dilakukan? Abaikan MSBuild yang sudah ada sebelumnya yang sudah dapat menangani apa yang diperlukan dan mulai dari awal? Maaf, saya tahu jalan yang akan saya pilih.

Sedikit kekhawatiran tampaknya ada di sekitar penggabungan TETAPI jika file proyek tidak berisi nama file dalam proyek, dan jika dependensi didorong ke file konfigurasi terpisah, masalah penggabungan akan hilang karena file proyek kemudian harus berubah relatif jarang.

Hanya pendapat saya

Masalah penggabungan hanya satu masalah. Menjauh dari MSBuild adalah hal lain. Salah satu hasil gila dari skenario ini adalah mereka sekarang akan menghabiskan waktu dan tenaga untuk mem-porting MSBuild ke Linux dan OSX! Bayangkan itu.

Saya mendapatkan alasan mereka, tetapi alasan mereka tidak bekerja untuk saya sama sekali, dan tidak bekerja untuk banyak orang. Kami melakukan investasi berdasarkan jaminan yang kuat tentang arah yang mereka ambil, dan mereka kembali melakukannya tanpa akuntabilitas, dan tidak lebih dari indikasi bahwa mungkin mereka seharusnya _mengkomunikasikan_ keputusan dengan lebih baik. Mereka membuat keputusan pada project.json berdasarkan kasus tepi yang didukung MSBuild, dan seberapa sulit untuk mendukung kasus tepi tersebut. Itu berarti _tidak pernah_ berhenti digunakan, karena tidak ada orang waras yang akan mendukung semua kasus tepi tersebut. Tentu saja tidak ada yang melakukan proyek ASP.NET yang membutuhkan kasing tepi itu.

Forking adalah suatu kemungkinan, tetapi mengingat seberapa besar dan terintegrasi semuanya, itu adalah prospek yang menakutkan untuk mempertimbangkan bahkan mempelajari kode yang relevan. Kenyataannya adalah bahwa ini bukan Proyek Sumber Terbuka, ini adalah proyek Microsoft, dan mereka telah membuat keputusan perusahaan tanpa masukan kami, dan kami harus menyedotnya dan menerimanya. Sudah dijelaskan kepada saya bahwa pada dasarnya tidak ada kemungkinan bahwa mereka akan _selalu_ mempertimbangkan kembali, tidak peduli apa oposisi yang ada.

Jadi, apakah kita menghabiskan upaya dan membayar sistem pembangunan project.json, atau kita beralih ke sistem pembangunan lain (PALSU?), atau Anda menyedotnya, atau Anda menggunakan platform lain. Saya percaya saya telah menyebutkan semua pilihan di sana.

@shederman MSBuild telah menjadi open source sejak awal 2015, dan build meneruskan OSX/Ubuntu, jadi saya rasa ini tidak sebanyak yang Anda pikirkan untuk port (https://github.com/Microsoft/msbuild) , menelusuri repo sepertinya OSX sedang membangun OK kembali pada bulan Maret misalnya.

Aduh Buyung. Saya khawatir tentang apakah kita _harus_ melakukan ini, dan mereka telah pergi dan melakukannya...

Merasa sedikit seperti seseorang yang menonton Monster Frankenstein meluncur ke kejauhan. Tertarik, penasaran, prihatin, dan lebih dari sedikit jijik :-)

@darrelmiller Catatan standup menyebutkan

Betulkah? Orang masih melakukan itu? Maksud saya, saya biasa melakukannya untuk AssemblyInfo.cs, dan di Zaman Kegelapan, kami akan meletakkan kunci Strong Name kami di file sumber bersama.

Oke, itu adalah kasus penggunaan, tapi sekarang aku benar-benar ingin mendengar kasus penggunaan untuk kasus penggunaan. Tertarik.

@shederman

Um. Oke, jadi saya harus membayangkan masa depan yang tidak saya inginkan dan menjelaskan kepada Anda bagaimana cara kerjanya? Um, tidak, saya tidak berpikir begitu

Yang harus Anda lakukan adalah menerima XML alih-alih JSON, untuk melihat apa manfaatnya, tetapi Anda tidak mau memainkan permainan itu karena yang ingin Anda lakukan hanyalah berbicara tentang seberapa buruk XML tanpa benar-benar menyatakan alasannya .

Aduh Buyung. Saya khawatir tentang apakah kita harus melakukan ini, dan mereka telah pergi dan melakukannya...

Mereka telah "pergi dan melakukannya" selama _tahun_ sekarang. Mereka berbicara tentang open-source .net bertahun-tahun yang lalu, mereka memberikan peta jalan dan menjelaskan bahwa ini tentang berjalan pada platform apa pun pada akhirnya, untuk kasus penggunaan apa pun.

Anda cukup kecewa dengan perubahan ini dan saya menduga mayoritas orang yang kecewa dengan perubahan ini adalah semua pengembang web, tetapi itu hanya sebagian kecil dari ekosistem .net, ada ekosistem besar layanan, pengembang seluler, dan cloud yang memiliki perpustakaan kode yang mereka inginkan untuk dapat di-port ke .net core. Suka atau tidak, project.json saat ini tidak berfungsi untuk semua model tersebut. Anda mengatakan "buat itu berfungsi" tetapi Anda hanya akan berakhir dengan file proyek berantakan lainnya, kecuali yang tidak memiliki struktur yang jelas dan terdefinisi dengan jelas dan - lebih buruk lagi - tidak ada komentar. Poin terakhir itu adalah alasan yang cukup untuk memikirkan kembali project.json.

Oh ya, xproj yang Anda tautkan itu jauh lebih baik. Bagus dan jelas dan ringkas. Dan ekspresif, jangan lupa ekspresif.

Setidaknya Anda akhirnya melihatnya. Hanya butuh apa, 72 komentar dalam masalah ini bahkan sebelum Anda repot? Saya terus memberi tahu Anda ini, tetapi Anda tidak mengerti: Alih-alih mengeluh tentang betapa buruknya MSBuild, bicarakan mengapa itu mengerikan .

Masalah penggabungan hanya satu masalah. Menjauh dari MSBuild adalah hal lain.

Mengapa ini bahkan menjadi masalah? Anda membenci MSBuild, kami mengerti, tapi apa yang Anda benci tentang MSBuild selain fakta bahwa _berani_ menggunakan XML?

Salah satu hasil gila dari skenario ini adalah mereka sekarang akan menghabiskan waktu dan tenaga untuk mem-porting MSBuild ke Linux dan OSX! Bayangkan itu.

Kamu benar! Itu akan sangat buruk, karena dapat mengembangkan segala jenis aplikasi .net pada platform apa pun yang Anda inginkan, menggunakan IDE apa pun yang Anda inginkan. Pikirkan anak-anak!
Beraninya Microsoft menghabiskan waktu untuk membuka sumber pekerjaan mereka dan memindahkan alat mereka ke platform lain alih-alih berinvestasi dalam teknologi sumber tertutup mereka sendiri.

Saya mendapatkan alasan mereka, tetapi alasan mereka tidak bekerja untuk saya sama sekali, dan tidak bekerja untuk banyak orang.

Tapi mungkin mereka bekerja untuk lebih banyak orang daripada Anda?

Kami melakukan investasi berdasarkan jaminan yang kuat tentang arah yang mereka ambil, dan mereka kembali melakukannya tanpa akuntabilitas, dan tidak lebih dari indikasi bahwa mungkin mereka seharusnya mengomunikasikan keputusan dengan lebih baik.

_arah_ apa yang Anda maksud? Tujuannya selalu .net di mana-mana, "Pengembang apa pun, aplikasi apa pun, platform apa pun" adalah mantra hari ini dan sama sekali tidak ada perubahan yang memengaruhi itu. Mereka telah menyatakan dengan jelas bahwa tujuan mereka adalah untuk menjaga file proyek tetap kecil, sederhana, dapat dibaca manusia dan dapat diedit manusia tanpa IDE. Tidak ada yang diambil darimu. Anda mungkin harus berurusan dengan sedikit XML, teriakan besar, jika itu berarti .net adalah pengalaman kelas satu untuk seluler, cloud, dan web, maka itu sangat berharga.

Mereka membuat keputusan pada project.json berdasarkan kasus tepi yang didukung MSBuild

Ini jauh melampaui kasus _Edge_, menggelikan bahkan menyarankan bahwa project.json hampir sempurna.

Tentu saja tidak ada yang melakukan proyek ASP.NET yang membutuhkan kasing tepi itu.

Saya kira ini adalah inti masalahnya: Anda tidak peduli dengan siapa pun selain diri Anda sendiri, seorang pengembang asp.net. Cukup adil, tetapi sekali lagi saya akan mengatakan kepada Anda: Terimalah bahwa pengembang lain penting dan alih-alih hanya mengangkat tangan, bekerjalah untuk menjadikannya sistem terbaik. Itu tidak berarti membuat sintaks sewenang-wenang untuk markup yang sama sekali berbeda, itu berarti menerima bahwa gambarnya lebih besar dari hanya Anda dan bekerja dengan orang lain untuk membuatnya bagus untuk semua orang.
Seperti yang selalu saya katakan, jika nuget.json mencantumkan semua dependensi Anda, apa yang tersisa? Apa masalahnya dengan mendefinisikan beberapa bidang yang cukup statis dalam elemen bernama XML?

Kenyataannya adalah ini sebenarnya bukan Proyek Sumber Terbuka

Seperti yang dikatakan orang lain, menjadi open source tidak berarti membungkuk ke belakang ke beberapa pengeluh. Mereka menerima permintaan tarik, menulis sesuatu yang lebih baik.

mengingat seberapa besar dan terintegrasinya semuanya, merupakan prospek yang menakutkan untuk mempertimbangkan bahkan mempelajari kode yang relevan.

Oke, jadi pada dasarnya saya membaca ini sebagai "Saya tidak memahami gambaran yang lebih besar dan saya tidak ingin memahami gambaran yang lebih besar, namun saya masih akan mengeluh karena itu mempengaruhi gelembung kecil saya dengan mengabaikan implikasinya. gelembung saya ada di orang lain".

Jadi, apakah kita menghabiskan upaya dan membayar sistem pembangunan project.json, atau kita beralih ke sistem pembangunan lain (PALSU?), atau Anda menyedotnya, atau Anda menggunakan platform lain. Saya percaya saya telah menyebutkan semua pilihan di sana.

Atau... dan maksud saya ini hanya pemikiran yang gila dan out-of-the-box, tetapi Anda dapat mencoba untuk benar-benar berkontribusi sesuatu yang konstruktif untuk percakapan.

Kembali ke topik....

Saya telah lebih memikirkannya dan sekarang saya condong ke project.json menjadi nuget.json, menjaga manajemen ketergantungan seperti sekarang. Ini berfungsi dengan baik sekarang, intellisense sudah ada di sana dan konsisten dengan hal-hal seperti gulp dan npm.

Biarkan csproj hanya mendefinisikan bagian statis.

Namun, kelemahan dari pendekatan ini yang dapat saya lihat adalah bahwa saya tidak yakin seberapa baik itu akan bekerja ketika menargetkan beberapa kerangka kerja, saya tidak merasa masuk akal untuk memasukkannya ke dalam nuget.json tetapi nuget.json adalah masih harus tahu tentang hal itu.

project.json bukan hanya file json.
csproj bukan hanya file XML.

IMHO banyak orang, seperti saya, senang melihat Microsoft, lebih tepatnya tim Asp.Net,
membebaskan diri mereka dari kode/konsep/sistem/alat/penampilan/penampilan yang sangat lama.

Ini memberi kami 'harapan'!

Saya mengembangkan Asp.Net sejak bit pratinjau pertama. Saya kebanyakan suka bekerja dengannya. Namun setelah 15 tahun,
hal-hal 'lama', seperti XML, terasa sangat, sangat berat dan ketinggalan zaman. Persepsi itu penting.

Tanpa XML dan setidaknya menggunakan JSON sebagai gantinya, 'kebahagiaan pengembang' saya jauh lebih besar.
Saya dapat bekerja dengan hal-hal, seluruh dunia telah memutuskan untuk menggunakan. IDE saya lebih menyukai hal-hal itu daripada format lama.
Saya tidak lagi harus membayar 'Pajak Kurung Sudut'.

Menghapus project.json bukanlah masalah besar, tetapi melakukannya di balik pintu tertutup hampir pada saat terakhir membunuh 'harapan' itu secara instan.

Tiba-tiba ini tidak terasa seperti proyek open source lagi.

fyi: "Asp.Net Core" memiliki banyak fitur fantastis. Saya kebanyakan menyukainya.
Tim Asp.Net hebat dan saya sangat bangga menjadi pengembang Asp.Net.

Tapi aku terluka. Mungkin saya bukan satu-satunya.

Hanya 2 sen saya.

Saya pikir kita semua bisa setuju bahwa msbuild (terutama bagaimana VS menggunakannya) tidak sempurna, dan sementara saya senang dengan project.json itu lebih tentang MS memperbaiki banyak poin rasa sakit saya dan jujur ​​selama mereka melakukannya, saya mungkin tidak akan terlalu peduli tentang bagaimana mereka melakukannya.

• penggabungan csproj tidak berfungsi dengan baik, saya mendapati diri saya perlu memperbaiki penggabungan yang rusak secara manual setiap minggu. Menghapus daftar file dari csproj akan banyak membantu di sini.
• Referensi NuGet dan referensi Proyek tidak selalu sejalan, lagi-lagi bisa jadi karena penggabungan yang rusak. Either way itu menjengkelkan untuk mendiagnosa dan memperbaiki.
• Kadang-kadang saya perlu menyambungkan ke proses build (tidak yakin bagaimana itu dimaksudkan untuk bekerja di project.json) tetapi keseluruhan kebutuhan untuk membongkar/memuat membuat debugging skrip build menjadi proses yang menyakitkan.

Jika mereka menemukan cara untuk memperbaiki 3 item itu maka saya mungkin tidak akan terlalu banyak mengeluh tentang file csproj.

@neoKushan

yang ingin Anda lakukan hanyalah berbicara tentang seberapa buruk XML tanpa benar-benar menyatakan alasannya

Tidak sepenuhnya adil, saya juga ingin berbicara tentang bagaimana MSBuild buruk :-)

Saya yakin saya sebenarnya _have_ mengatakan mengapa saya tidak menyukai XML untuk membangun file, tetapi izinkan saya mencobanya lagi. XML bertele-tele, jelek, lebih baik untuk perkakas daripada untuk pengeditan tangan, dan saya tidak menikmati pengalaman menggabungkannya. Itu digunakan untuk MSBuild, karena saat itu industri berpikir XML dapat digunakan untuk semuanya. Kami telah pindah sejak saat itu. Nah, di beberapa tempat.

lebih buruk lagi - tidak ada komentar

Saya percaya beberapa orang telah menawarkan alternatif di sini. HJson hanyalah salah satu pilihan. Ya! Kita tidak perlu memikirkannya kembali ;-)

Anda cukup kesal dengan perubahan ini

Sejujurnya, saya sebagian besar kesal dengan bagaimana perubahan ini dilakukan di ruang tertutup tanpa mempertimbangkan atau terlibat dengan komunitas yang telah mengambil dukungan yang sangat kuat sebelumnya untuk project.json pada nilai nominal. Anak laki-laki, tidak akan membuat kesalahan itu lagi!

Jangan salah paham, tidak suka XML, tidak suka MSBuild. Tapi benci disuruh mengadopsi sesuatu yang sangat saya cintai dan kemudian diberitahu pada menit terakhir bahwa itu diambil. Jangan pindahkan keju saya!

Saya menduga mayoritas orang yang kecewa dengan perubahan ini adalah pengembang web

Umm, ya, itu karena mereka satu-satunya pengembang yang Anda tawarkan project.json. Dalam berita lain, pengembang Swift juga tidak kecewa dengan keputusan tersebut. Maksud saya, pikirkan apa yang Anda katakan di sini:

1. Hanya pengembang web yang mendapatkan fitur baru ini
2. Banyak dari mereka yang benar-benar kesal ketika kami mengambilnya
3. Tidak ada orang lain yang harus menggunakannya
4. Orang-orang yang tidak menggunakannya tidak marah karena itu diambil
   ergo semua pengembang lain tidak menginginkannya.

Saya pikir Anda perlu melihat kualitas pemikiran Anda, dan itulah yang saya coba interogasi selama beberapa waktu, dan tidak berhasil. Kurangnya informasi tentang pemikiran tersebut, dan fakta bahwa pihak-pihak terkait telah tutup mulut, menunjukkan kepada saya bahwa pemikiran itu mungkin patut dicurigai.

Dan apa yang Anda maksud dengan "pengembang web"? Anda sedang memikirkan beberapa situs web kecil untuk perusahaan kecil? Bagaimana dengan setumpuk layanan mikro, mendukung bisnis manajemen aset dengan puluhan miliar dolar yang dikelola. Tentu, ada situs web di sana juga. Tapi itu sekitar 10% dari sistem. Oh, dan ya, itu sebenarnya ditargetkan ke cloud juga, jadi mungkin kita sebenarnya berbicara "pengembang cloud".

Sepertinya Anda bahkan tidak mengerti bagaimana teknologi yang Anda buat dengan terburu-buru digunakan, atau oleh siapa.

apa yang Anda benci tentang MSBuild selain dari fakta bahwa ia berani menggunakan XML?

Ini terlalu rumit
Ini adalah ketidakcocokan impedansi, mendorong logika berbasis inferensi ke dalam situasi di mana orang terutama berurusan dengan logika imperatif atau deklaratif.
Astaga, apakah Anda benar-benar _melihat_ file MSBuild? Oke, maaf, Anda mengatakan selain menggunakan XML ;-)
Cara properti dan item dideklarasikan adalah kontra-intuitif bagi siapa saja yang tidak menggunakannya secara teratur
Ini digunakan sebagai alat satu ukuran yang cocok untuk semua alat yang mencoba melakukan tugas yang harus dilakukan dalam skrip. Palu, paku.
Dalam banyak kasus, semua yang dilakukannya dalam file besar dapat diekspresikan paling banyak dalam 3 baris skrip
Sampah VS yang dimuntahkan ke dalamnya. Saya dengar itu akan diperbaiki. Menunggu dengan sedikit gentar untuk melihat apakah itu akan dipotong juga. Seperti disebutkan di atas, saya agak ragu-ragu tentang janji sekarang.

Apa yang sangat kamu cintai ? Dan yang paling penting, apakah Anda bersedia menerima bahwa orang lain mungkin tidak sependapat dengan Anda? Jika demikian, dapatkah Anda mengakui bahwa "satu ukuran cocok untuk semua" mungkin bukan pendekatan yang tepat?

Arah apa yang Anda maksud

project.json adalah dasar dari pendekatan proyek baru kami adalah apa yang dikomunikasikan. Kami menginvestasikan uang dan waktu serta rasa sakit yang nyata atas dasar komitmen itu.

Tapi mungkin mereka bekerja untuk lebih banyak orang daripada Anda?

Mungkin mereka memang melakukannya. Tapi kalau begitu, mana buktinya? Saya sudah mencoba untuk menginterogasi pemikiran dan pengambilan keputusan dan bukti yang digunakan dalam hal ini, dan saya tidak mendapatkan apa-apa dari siapa pun. Untuk semua bukti yang telah diberikan, Anda bisa saja mengguncang bola ajaib 8 untuk semua yang kita tahu.

Tidak ada yang tahu berapa banyak yang berpikir dengan satu atau lain cara. Saya sebenarnya satu-satunya yang saya tahu yang benar-benar mencoba mencari tahu.

Anda tidak peduli dengan orang lain selain diri Anda sendiri, seorang pengembang asp.net

Tidak terlalu bagus. Apa yang sebenarnya saya katakan adalah bahwa pernyataannya adalah bahwa arah baru berfungsi untuk semua kasus penggunaan, dan saya mengangkat tangan dan mengatakan itu tidak berhasil untuk saya. Kaulah yang mengendarai sepatu kasar atas semua oposisi. Saya yang bertanya kepada orang-orang apa yang mereka pikirkan, MS tidak.

Saya tidak pernah mengatakan "singkirkan MSBuild sepenuhnya, dan terapkan proses pembangunan saya di semua pengembang lain". Andalah yang mengatakan "singkirkan project.json sepenuhnya, dan terapkan MSBuild pada semua pengembang". Kami memiliki dua sistem build di semua pratinjau, dan kami senang. Pengembang web senang dan pengembang non-web senang.

Kita bisa mendiskusikan seberapa layak itu, dan mungkin juga tidak, tapi kita tidak tahu , karena kita tidak pernah diajak berkonsultasi atau terlibat.

Anda benar-benar menyukai argumen Anda tentang bagian tengah yang dikecualikan.

Mereka menerima permintaan tarik

Betulkah? Jika kami mengeluarkan permintaan tarik yang meninggalkan alat pembangunan berbasis non MSBuild di fungsionalitas alat utama, yang hanya membaca project.json, Anda akan memasukkannya ke dalam kerangka kerja? Betulkah?

Oke, jadi pada dasarnya saya membaca ini sebagai...

Wow Anda banyak membaca tentang itu. Astaga, jika saya membaca seperti Anda, saya tidak akan pernah menyelesaikan satu buku pun. Dan itu akan sangat berbeda dengan apa yang penulis tulis.

Cobalah, "Saya tidak sepenuhnya memahami gambaran yang lebih besar dan saya sedang mempertimbangkan upaya dan waktu yang akan terlibat dalam melakukan hal ini. Akan jauh lebih baik jika kita memiliki bantuan dari para pengembang yang ada dalam memberikan bagian yang signifikan. keinginan komunitas mereka, tetapi saya kira jika mereka tidak peduli apa yang diinginkan pengguna mereka, kami mungkin harus menempuh rute itu."

Sialan! Saya membaca seperti Anda! Kecuali itu benar-benar cocok dengan teks asli sedikit lebih baik daripada interpretasi Anda yang agak histeris.

Anda dapat mencoba untuk benar-benar memberikan kontribusi sesuatu yang konstruktif untuk percakapan.

Yah saya pikir saya sedang konstruktif sebenarnya. Setelah saya mengatasi keterkejutan awal, saya mencoba mencari tahu apa dasar dari keputusan ini. Saya mencoba mencari tahu apa proses pengambilan keputusan itu. Saya mencoba menginterogasi kualitas pemikiran yang ada di baliknya. Ketika saya diberitahu bahwa sebagian besar pengembang menginginkan ini, tetapi tidak ada bukti yang diberikan untuk mendukung pernyataan ini, saya benar-benar bertanya kepada mereka, yang _tidak ada_ orang di tim yang telah melakukan BTW.

Apa yang saya dapatkan? Hambatan, hinaan, dan penghindaran. Jadi, beri tahu saya, mengapa menurut Anda tidak konstruktif untuk menanyakan apakah seseorang yang membuat keputusan besar yang memengaruhi jutaan orang mengerjakan pekerjaan rumahnya? Dan apakah Anda menganggapnya konstruktif atau mencurigakan ketika orang-orang tersebut menolak untuk menunjukkan buku pekerjaan rumah?

Maksud saya, secara realistis, ini adalah skenario yang mungkin terjadi:
1) Anda membuat keputusan berdasarkan umpan balik dan informasi lengkap, dan keputusan tersebut sejauh ini merupakan pilihan terbaik untuk maju. Jika demikian, saya akan tutup mulut, saya berjanji. Saya menemukan situasi ini sangat tidak mungkin karena tingkat oposisi yang Anda terima, dan fakta bahwa Anda menyembunyikan bukti dan pengambilan keputusan.
2) Anda membuat keputusan berdasarkan pandangan sebagian, tetapi yang terbaik yang Anda miliki saat itu. Saya akan mengatakan bahwa respons yang benar adalah membuka kembali keputusan dan meminta pandangan yang Anda tinggalkan. Saya menemukan ini situasi yang paling mungkin.
3) Anda membuat keputusan dengan buruk atau berdasarkan informasi yang buruk. Dalam hal ini, sekali lagi, Anda harus membuka kembali keputusan dan meminta komunitas. Saya benar-benar tidak berpikir ini adalah situasinya sama sekali, karena, meskipun Anda mungkin tidak mempercayai saya, saya sangat menghormati pengembang DotNetCore. Mereka semua.

Dan tahukah Anda, jika Anda membuka kembali keputusan itu, meminta pandangan, dan keputusan itu turun dengan cara yang sama, lalu apa salahnya? Dan jika, setelah meminta pandangan, Anda menyadari bahwa beberapa pengambilan keputusan Anda salah, dan Anda memperbaikinya, bukankah itu lebih baik ?

Wah, serius. Bisakah kita mengakhiri ini?

Pertanyaan sederhana: apakah Anda akan menerima oposisi dan meninjau kembali keputusan berdasarkan informasi baru?

Atau apakah Anda akan terus menyiratkan bahwa orang-orang yang tidak setuju dengan Anda adalah orang gila, bodoh, tidak terampil, _tidak tahu apa-apa_, atau tidak mampu memberikan opini yang valid dan terinformasi?

Saran: Microsoft fork untuk mendukung pelanggan lama msbuild csproj. #carryOnAsNormal

Saya juga sudah lama menjadi pengembang .Net, bekerja dengan pratinjau 1.0 bahkan sebelum pemasaran menemukan nama .Net. Tanpa terlalu tersesat di rumput liar, inilah dua sen saya.

Saya bisa menjalani sisa hidup saya tanpa pernah melihat file konfigurasi xml lain dan sangat bahagia.

Saya tidak ingin konfigurasi xml. Di mana saja. Pernah.

Saya tidak peduli jika tim memperbaiki setiap titik nyeri csproj; jika masih berupa file konfigurasi xml setelah Anda selesai, maka saya tidak tertarik. Anda sebaiknya tetap menggunakan sistem proyek .net 4.5.

Adapun MSBuild... MSBuild bisa mati dalam api.

Saya mengerti bahwa itu kuat, dan banyak alat ada di sekitarnya, tetapi di luar MS, hanya pakar MSBuild yang benar-benar tahu apa yang dilakukannya atau bagaimana cara kerjanya. Setiap kali saya harus memasukkan penyesuaian apa pun ke dalam proses pembuatan, saya akhirnya kehilangan 3 hingga 5 hari kehidupan profesional saya. Saya jarang bisa mendapatkan apa pun, bahkan hal-hal sepele seperti hanya memasukkan folder kosong di output, untuk bekerja dengan benar di VS, penerbitan VS, dan server CI saya secara bersamaan.

Saya mengerti... jika Anda tidak punya waktu untuk membuat pengganti MSBuild yang baik untuk kerangka waktu asp.net core 1.0, maka yakinlah... temukan cara untuk terus memanfaatkan MSBuild hingga asp.net core 2.0 siklus; tapi setidaknya tetap bekerja untuk menggantikan kotoran itu dengan sesuatu yang mungkin bisa dikerjakan oleh kita semua.

Sementara itu, cobalah untuk menyimpan sebanyak mungkin konfigurasi di json. Saya tidak peduli secara khusus apakah itu project.json, atau sesuatu yang baru dan lebih baik. Jika perlu, minta perkakas menghasilkan file MSBuild lama dengan cepat saat/jika diperlukan -- tempelkan di sub-folder di suatu tempat atau sesuatu.

Yang tidak saya inginkan adalah sistem file saya terlihat seperti ini:

• bower.json
• package.json
• nuget.json
• semuanya-lain.json
• microsoft-old-ass.xml.csproj

Juga, bisakah Anda memperbaiki batas panjang jalur 260 karakter ... tolong ... ya, saya tahu itu banyak hubungannya dengan windows, tapi serius ... ini 2016. .

PS. Jika Anda akan membawa pada mengabaikan oposisi, dapat Anda berikan berikut:

• Bagaimana kami mendapatkan akses ke saluran slack pengembang alat build
• Tampilan tingkat tinggi dari arsitektur dan kode saat ini, dan di mana perubahan untuk pindah ke MSBuild/xproj akan dibuat sehingga kami dapat merencanakan pendekatan kami untuk menjaga bit yang kami inginkan dan mengintegrasikan dengan baik.
• Jaminan bahwa permintaan penarikan memanggang di perkakas berbasis project.json akan diterima jika memenuhi kriteria kualitas
• Jaminan bahwa jika kriteria kualitas terpenuhi, kami dapat menyertakan dukungan "dotnet build" untuk project.json penuh, serta template ASP.NET Simple, dan kemungkinan beberapa template untuk jenis proyek yang lebih standar juga.

"Jadilah konstruktif", "jangan berkontribusi, jangan bersuara". Nah, Anda mendapatkan apa yang Anda minta ...

@Mike-EEE, ingin melakukan serialisasi Xaml untuk SimpleUseCaseBuild?

Setelah membaca semua ini saya sampai pada kesimpulan ini:

• project.json membawa banyak peningkatan. Semua ini tidak akan mungkin terjadi jika .net dan asp.net core akan dikaitkan dengan kode dan alat lama
• project.json (dan json) tidak sempurna
• xml vs json vs anyserializationbahasa yang steril. Diskusi tentang bagaimana memanfaatkannya untuk menjawab tantangan inti .net akan lebih menarik
• kembali ke msbuild membawa kembali warisan dan itu mungkin berarti bahwa kita tidak akan melihat peningkatan lagi pada sistem proyek, karena tim .net cenderung kehilangan sebagian kebebasannya

Saya harap tim .net akan mengambil napas dalam-dalam, menghentikan ini sedikit, mengumpulkan umpan balik (dan mempertimbangkan adopsi dan persepsi tumpukan baru ini), dan menantang pendekatan msbuild (yang mungkin tidak seburuk yang kita pikirkan) dengan beberapa alternatif. Saya pikir ada kebutuhan untuk terburu-buru.

LOL @shederman apa yang membuatmu menarikku sekarang?! :smile: Dan APA diskusinya! Sangat menakjubkan.

xml vs json vs anyserializationbahasa yang steril. Diskusi tentang bagaimana memanfaatkannya untuk menjawab tantangan inti .net akan lebih menarik

Ya bagi saya yang penting adalah model dukungan yang digunakan untuk menggambarkan proyek dan/atau apa yang mereka lakukan, dan beberapa percakapan ini telah menyentuh hal itu. Saya ingin melihat model/api proyek yang lebih baik yang lebih mudah untuk dijelaskan dan digunakan (tidak peduli formatnya dijelaskan - meskipun ya saya lakukan :heart: Xaml saya!). Saya memiliki diskusi terbuka tentang repo MSBuild di sini (https://github.com/Microsoft/msbuild/issues/613) sehubungan dengan ini dan juga pada sistem proyek Roslyn (https://github.com/dotnet/roslyn-project -system/issues/37) juga, jika tertarik.

Banyak poin yang sangat bagus di sini, dan saya pribadi sedang menggali energi, "tidak konstruktif" atau sebaliknya. Saya pikir semua orang di sini memiliki hati mereka dalam meningkatkan MSFT dan membuat yang terbaik dari apa yang sedang diproduksi. :+1:

2 sen saya:

Saya percaya bahwa ada dua jenis orang yang mendiskusikan perubahan ini:

• pengembang yang telah menggunakan VS & .NET untuk membangun _berbagai_ jenis proyek dan harus mendukung proyek tersebut untuk waktu yang lama
• pengembang yang tidak memiliki beban seperti itu dan menginginkan kerangka kerja ASP.NET Core lintas platform yang baru, bersih dan mewah

Secara pribadi, saya berada di kategori pertama jadi saya ingin ASP.NET Core baru agar kompatibel dengan jenis proyek VS lainnya, dan pindah ke solusi csproj/msbuild "lama" adalah kemenangan bagi saya (+ tim dan mungkin banyak pengembang lain). Dengan cara ini transisi akan jauh lebih halus dan jelas. Mungkin orang-orang dari kategori kedua tidak akan setuju dengan saya (atau mereka tidak peduli).

Satu-satunya masalah utama yang saya lihat sekarang adalah bagaimana paket NuGet didefinisikan dan dirujuk. Sangat sulit untuk mempertahankan file package.config dan csproj (seperti yang telah disebutkan @cwe1ss di https://github.com/aspnet/Home/issues/1433#issuecomment-218519705 ). Itu adalah salah satu komentar paling membangun dalam topik ini BTW...

Adapun perang suci XML/JSON ... IMHO, XML lebih baik untuk mengedit tangan daripada JSON. XML mendukung komentar dan memiliki lebih banyak informasi konteks saat Anda melihatnya. JSON lebih baik untuk data, bukan untuk file konfigurasi. Penggabungan sama-sama baik dan buruk untuk kedua format, itu semata-mata tergantung pada kontennya. Jika referensi proyek akan dipisahkan dari penggabungan file csproj saat ini akan menjadi lebih mudah juga...

@Funbit mencoba mengkategorikan orang tidak akan membantu. Dan saya tidak cocok dengan salah satu kategori Anda. Saya seorang pengembang asp.net sejak v1 betas. Saya hampir berhenti menjadi satu 2 tahun yang lalu tetapi .net core membawa saya kembali karena itu bersih dan terbaik dari .net dan dunia simpul.

Saya ingin .net core sukses, bukan tekno korporat lama tanpa adopsi dan komunitas.

Untuk bagian saya, saya tidak terlalu peduli dengan keputusan ini, saya tidak terlalu peduli dengan XML, dan untuk mencuri kutipan: "Kurung kurawal lebih baik daripada kurung sudut", tetapi itu tidak terlalu mengganggu saya untuk kembali ke csproj/msbuild - Saya fleksibel saya bisa mengatasinya.

Saya ingin mengulangi beberapa komentar @shederman :

Kenyataannya adalah bahwa ini bukan Proyek Sumber Terbuka, ini adalah proyek Microsoft, dan mereka telah membuat keputusan perusahaan tanpa masukan kami, dan kami harus menyedotnya dan menerimanya. Sudah dijelaskan kepada saya bahwa pada dasarnya tidak ada kemungkinan bahwa mereka akan pernah mempertimbangkan kembali, tidak peduli apa oposisi yang ada.

dan

Sejujurnya, saya sebagian besar kesal dengan bagaimana perubahan ini dilakukan di ruang tertutup tanpa mempertimbangkan atau terlibat dengan komunitas yang telah mengambil dukungan yang sangat kuat sebelumnya untuk project.json pada nilai nominal. Anak laki-laki, tidak akan membuat kesalahan itu lagi!

Ini _tidak_ mengganggu saya, Microsoft telah membuat banyak sumber terbuka .NET dan ingin benar-benar terlibat dan bekerja dengan komunitas, mendapatkan umpan balik mereka dan menjadi 'anggota' (mitra?) yang baik dari komunitas. Tetapi hal semacam ini benar-benar menghambat seluruh upaya itu dan memberikan ekosistem .NET yang secara keseluruhan "boros" merasa bahwa /. masyarakat melabelinya dengan selama bertahun-tahun.

Agar adil bagi Microsoft, mereka bukan satu-satunya yang melakukan hal semacam ini dengan proyek yang disponsori perusahaan; ingat perpecahan di komunitas nodejs (yang menyebabkan garpu io.js)? Tapi saya pikir ketika itu Microsoft, itu jauh lebih buruk.

Itu meledak jauh dari proporsi dari apa yang awalnya dimaksudkan.

Itu meledak jauh dari proporsi dari apa yang awalnya dimaksudkan

@MaximRouiller apakah Anda bahkan pengembang, bro??? :senyum:

@Mike-EEE saya lakukan. Saya mengharapkan beberapa argumen panas tetapi saya telah melihat terlalu banyak serangan pribadi. :kecewa:

harus dapat berbagi file sumber di seluruh proyek

@darrelmiller Ini terdengar menakutkan bagi saya, karena itu sepertinya menyiratkan bahwa daftar file di .csproj akan kembali.

@lokitoth Mungkin tidak ada alasan mengapa file yang ditautkan tidak dapat menggunakan gumpalan wildcard juga.

@MaximRouiller Saya juga bersalah karena terlalu mengutarakan pikiran saya. Saya pikir saya buruk tetapi @shederman tahu bagaimana cara melempar! Ha ha. Kebetulan, saya akan mengatakan bahwa @shederman mewakili hewan pengkodean batin saya, tetapi itu sebelum saya tahu ada @CodingGorilla. :tertawa:

Saya pikir kita perlu mengingatkan diri kita sendiri bahwa apa yang kita lakukan adalah benar- benar kerja keras, dan saat itulah berhasil! Mendapatkan di sana bahkan lebih sulit. Dalam pengalaman saya dengan Silverlight (ya, saya terbakar baaaaaaad dengan itu, jadi saya tahu dari mana @shederman berasal), itu membantu saya untuk melihat bahwa mungkin saya tidak tahu _semuanya_ (atau bahkan _apapun_ kadang-kadang, rasanya!) dan untuk tetap berpikiran terbuka tentang berbagai hal. saya masih gagal. Bahkan ketika saya melihat inisiatif project.json, saya melakukan yang terbaik untuk menunjukkan kesenjangan yang diciptakannya, tetapi mungkin sedikit terlalu kasar dengan orang-orang di sini di repo dalam melakukannya.

Bagaimanapun, itu selalu yang terbaik untuk mengambil napas dalam-dalam, (mencoba) memiliki semangat rendah hati, dan mengingatkan diri kita sendiri bahwa kita berada di tim yang sama, bahkan jika tim itu telah dibagi menjadi kubu "web" dan "pribumi" sekarang. Ini mungkin menyebalkan untuk beberapa saat, tetapi apa yang kita bicarakan di sini adalah sesuatu yang akan membantu kita untuk waktu yang lama -- bahkan satu dekade atau lebih. Mari fokus pada pendekatan jangka panjang sambil juga memiliki empati terhadap orang lain dan dari mana mereka berasal.

OK... cukup khotbah dan hura-hura untuk hari ini. :stuck_out_tongue: Kembali ke slugfest yang dijadwalkan secara rutin!

Ini terdengar menakutkan bagi saya, karena itu sepertinya menyiratkan bahwa daftar file di .csproj akan kembali.

Selain itu, apakah saya satu-satunya orang di planet ini yang menghargai fitur ini? :stuck_out_tongue:

Ini terdengar menakutkan bagi saya, karena itu sepertinya menyiratkan bahwa daftar file di .csproj akan kembali.

Selain itu, apakah saya pikir satu-satunya orang di planet ini yang menghargai fitur ini? :stuck_out_tongue:

@Mike-EEE Ya, saya pikir Anda. :mengedip:

Kasus penggunaan utama untuk file tertaut adalah untuk menargetkan beberapa platform. Itulah salah satu fitur project.json yang sangat ingin saya pertahankan. Saya tidak berpikir saya telah melihat komentar khusus tentang kemampuan ini, tetapi alangkah baiknya jika tim dapat menegaskan niat mereka untuk membuat ulang ini di msbuild.

@shederman tahu cara melempar!
😆

saya mencoba. Saya harap saya tidak menghina siapa pun. Saya berusaha sangat keras untuk hanya mengejar argumen.

Saya sangat kesal dengan penghinaan pribadi yang sinis, jadi siapa pun yang menentang saya, BUKAN cara untuk membungkam saya. Dan ada beberapa dari mereka.

Saya ingin tahu tentang kasus penggunaan untuk mengedit file csproj. Pengalaman saya adalah bahwa saya hanya perlu mengedit file csproj ketika nuget mengacaukan sesuatu, atau jalur petunjuk rusak. Untuk menambahkan langkah baru ke proses pembuatan, saya selalu menggunakan file build.proj tingkat tinggi yang dijalankan oleh sistem CI saya. Saya tidak pernah menggunakan file .sln dalam pengaturan CI saya.

Apakah tujuan utama orang ingin mengedit file csproj untuk menambahkan langkah BeforeBuild dan AfterBuild yang ingin mereka jalankan ketika mereka melakukan debug di Visual Studio?

@Mike-EEE Mungkin; Saya sebagian besar ingat itu menjadi masalah besar ketika berurusan dengan proyek dengan jumlah file yang sangat besar (mis. Ekspresi Blend, Visual Studio XAML Designer, dll.) Sampai-sampai kami menukarnya dengan pemilihan wildcard - yang dilakukan VS tidak tahu cara bekerja dengan benar, yang berarti bahwa setiap kali saya menambahkan file, saya harus memuat ulang proyek (atau mengalami kesalahan "file ini sudah ditambahkan" saat dibangun)

Apa yang sebenarnya Anda sukai dari "fitur" ini (bukan berbagi file di seluruh proyek, yang jelas berguna, tetapi tentang VS hanya berfungsi dengan baik ketika setiap file terdaftar satu per satu)?

Apa yang sebenarnya Anda sukai dari "fitur" ini (bukan berbagi file di seluruh proyek, yang jelas berguna, tetapi tentang VS hanya berfungsi dengan baik ketika setiap file terdaftar satu per satu)?

Memang ini adalah kebiasaan buruk, tetapi saya suka dapat menghapus file dari proyek saya ketika saya melakukan refactoring. Atau bahkan dari perspektif sejarah. Jika saya tahu saya sedang mengerjakan sesuatu yang mungkin saya inginkan di lain waktu, saya menyimpannya di disk tetapi menghapusnya dari proyek. Memang, ini mencemari kontrol repo/sumber (lihat: kebiasaan buruk), tetapi saya menikmati kontrol semacam itu. Karena sekarang, ketika saya menginginkan file itu, saya tidak perlu pusing-pusing dengan riwayat repo (bagaimana menemukan riwayat file yang dihapus ini??? terlalu banyak pekerjaan!), saya cukup "tampilkan semua file" dan tambahkan kembali ke solusi saya. Sejarah instan. :senyum:

Saya ingin tahu tentang kasus penggunaan untuk mengedit file csproj

Untuk .csproj (semua ini telah saya lakukan, dan sebagian besar, beberapa kali)

• Jika Anda perlu merujuk jenis UWP dari aplikasi desktop
• Jika Anda perlu memperbaiki kerusakan VS dengan NuGet (terutama seputar menambahkan file a.targets dan .proj/.props termasuk)
• Jika Anda perlu mengubah tata letak output yang dihasilkan
• Jika Anda memfaktorkan ulang proyek dan mengganti nama rakitan
• Jika Anda melakukan refactoring besar yang berdampak pada banyak file
• Jika Anda mengalami konflik penggabungan karena beberapa orang bekerja dalam proyek yang sama dan Anda tidak menggunakan wildcard
• Jika Anda perlu memahami mengapa build tiba-tiba tidak berfungsi (Sunting: Saya seharusnya menentukan - ini lebih merupakan "mengapa saya membutuhkannya untuk dapat dibaca, dan 'mandiri'")
• Jika Anda perlu men-debug konflik versi Majelis karena ketergantungan yang mengganggu
• Jika Anda mencoba menambahkan file "tertaut" (dibagikan)

Untuk project.json

• Membuat file dari awal dengan tangan (sangat penting)
• Menambah/menghapus paket NuGet
• Mengubah kerangka target
• Mengubah versi paket keluaran

@shederman Saya menyadari bahwa Anda frustrasi, tetapi ketika Anda merespons dengan

Betulkah? Orang masih melakukan itu? Maksud saya, saya dulu melakukannya untuk AssemblyInfo.cs, dan kembali ke Abad Kegelapan

Anda sedang mengatur nada. Tidak apa-apa untuk melakukan percakapan tatap muka, tetapi dalam lingkungan seperti ini, cenderung membuka pintu ke berbagai macam komentar berbasis emosi yang cenderung mempolarisasi percakapan dan membuat sulit untuk fokus pada poin-poin penting. Saya tahu sulit untuk menghilangkan emosi dari diskusi ini (lidah saya penuh dengan bekas gigitan ;-)) tetapi kami benar-benar harus berusaha agar diskusi tetap bermanfaat.

@Mike-EEE Tidak bisakah Anda mencapai hal yang sama (tanpa mencantumkan setiap file) menggunakan Exclude atribut/pola ? Sebagai catatan, saya sering melakukan hal yang sama, ini sangat berguna ketika Anda hanya ingin menghilangkan sesuatu dengan cepat tanpa harus melakukan siklus commit/rollback.

Sebagai catatan, saya sebenarnya menyukai proposal @ Mike-EEE yang menggunakan Roslyn dan membuat file proyek menjadi AST serial. Tetapi hanya jika kita dapat membuatnya sama mudahnya untuk bekerja dengan hanya menggunakan notepad. (Ya, maksud saya notepad, bukan notepad ++ atau apa pun yang lebih canggih: itulah "tes asap" untuk kegunaan format file yang dapat diedit manusia)

@CodingGorilla saya terbuka untuk itu. Saya lebih suka melihat perkakas membantu saya dengan ini (menentukan pola untuk saya daripada mencari tahu bagaimana melakukannya -- jika saya merasa seperti saya bekerja dengan DOS lagi, SEMUA ORANG KEHILANGAN!!). Saya harus dapat memiliki pengalaman yang sama persis seperti yang saya lakukan sekarang.

Jadi pada dasarnya, melihat model "opt-out" daripada "opt-in".

Bagi mereka yang ingin mengedit file proyek tanpa membongkar.... https://twitter.com/migueldeicaza/status/730978470734401536

Bagi mereka yang ingin mengedit file proyek tanpa membongkar ....

@darrelmiller apa yang saya lihat di sini ... menyarankan menggunakan Xamarin Studio saja? Ya, bisnis/alur kerja/pengalaman bongkar/muat itu adalah yang TERBURUK! Sudah ada sejak tahun 2003, hehe.

Saya mendukung gagasan bahwa file akhirnya harus mudah diedit dan dibaca dengan editor teks standar (yaitu notepad), apa pun formatnya.

Saya juga berpikir perkakas yang lebih baik akan menghilangkan banyak masalah di balik csproj saat ini. VS bukan contoh terbaik dan saya pikir pengalaman yang diberikan VS kepada Anda adalah apa yang sebenarnya dibenci banyak orang tentang sistem proyek MSBuild.

@Mike-EEE Balasan untuk komentar Miguel berasal dari David Kean yang bekerja pada sistem proyek baru. Tim tahu VS harus bisa melakukan ini juga.

@Mike-EEE Saya kira hal saya adalah, saya dapat menangani apa pun yang mereka buat. Sistem proyek MSBuild cukup kuat untuk melakukan apa saja (kecuali seperti yang dikatakan @shederman , itu hanya _tidak_ bisa XML). Saya pikir beberapa orang hanya mengintai "itu pasti cara saya atau itu GAGAL", dan seperti yang dikatakan orang lain (maaf lupa siapa, utas ini adalah YUUUUUUGE!) "Saya mencoba untuk tetap berpikiran terbuka ..." dan beradaptasi saja.

Selain itu, Anda mungkin belajar sesuatu yang baru, dan itu selalu merupakan hal yang baik. :nyengir:

@neoKushan Saya dulu menulis skrip msbuild dari awal, itu memang jauh lebih kuat daripada vs msbuild yang dibumbui. Tapi itu juga tidak bagus, dan saya cukup senang saya tidak melakukannya lagi. Saya pikir kita bisa mengerjakan sesuatu yang jauh lebih baik dari ini.

@CodingGorilla Sebenarnya daging sapi utama saya adalah dengan MSBuild. XML adalah masalah, tetapi tidak seburuk MSBuild.

Saya telah menawarkan untuk melakukan pekerjaan sendiri untuk menjaga dukungan project.json berjalan berdampingan dengan xproj. Dia yang paling peduli, yang bekerja, kan?

Dan ini sebenarnya adalah intinya. Akankah tim mengizinkan saya untuk memberikan kontribusi ini? Dan jika tidak, mengapa tidak? Bagaimanapun, ini adalah OSS, bukan?

Kemudian, jika Anda menyukai MSBuild dan menginginkan kekuatannya, Anda menggunakan xproj.

Dan jika Anda menyukai perkakas yang dibuat untuk inti ASP.NET, Anda terus menggunakannya.

Mereka menggunakan kompiler dasar yang sama.

Dan itu seharusnya tidak terlalu banyak bekerja dalam hal apa pun. Yang harus saya lakukan adalah memfaktorkan ulang kode yang tidak digunakan lagi menjadi perintah lain.

Idealnya saya ingin dapat menggunakan "dotnet build" dan melihat dir dan memutuskan mana yang akan digunakan berdasarkan file apa yang ada. Tetapi flag opsi pada build atau bahkan perintah baru akan baik-baik saja.

@sandorfr Saya setuju menulis file MSBuild lengkap yang mendefinisikan _seluruh_ proses pembuatan Anda tidak lain adalah rasa sakit yang luar biasa, tetapi jika saya tidak salah bukan itu yang sebenarnya kita bicarakan di sini - kita sedang berbicara tentang _just_ proyek struktur.

Dengan kata lain, MSBuild adalah sistem yang sangat besar dan kuat dan dengan itu muncul banyak kerumitan - tetapi hanya jika Anda menggunakannya. VS secara default membuang banyak omong kosong di sana yang tidak Anda butuhkan dan melihat xproj, jelas MSBuild juga tidak benar-benar membutuhkannya. Jika tim donet fokus pada meminimalkan apa yang diperlukan dalam csproj, itu harus relatif minimal dan bersih untuk kebanyakan orang. Satu-satunya yang harus menderita "gabungan neraka" adalah orang-orang yang menginginkan fungsionalitas tambahan itu (Yang saya curigai adalah orang-orang yang mendorong perubahan ini, di kepala mereka).

Masih tidak ada yang menghentikan Anda menggunakan sistem build pilihan Anda, baik itu CAKE atau TFS Team Services atau apa pun.

Sekali lagi, ini menetapkan bahwa tim melakukannya "Benar".

VS bukan contoh terbaik dan saya pikir pengalaman yang diberikan VS kepada Anda adalah apa yang sebenarnya dibenci banyak orang tentang sistem proyek MSBuild.

@neoKushan Itulah yang saya rasakan tentang TFS Build dan Xaml. Xaml sangat luar biasa (dan masih akan senang melihatnya digunakan sebagai format yang memungkinkan untuk "skrip" MSBuild), tetapi penggunaannya di TFS Build telah memberinya nama yang buruk.

Saya rasa tidak produktif untuk menggunakan masalah github ini sebagai jendela obrolan. Saya ingin menyimpan pemberitahuan email untuk utas ini jika seseorang dari MS membalas tetapi jumlah email menjadi terlalu mengganggu.

Sistem proyek MSBuild cukup kuat untuk melakukan apa saja

Itulah bagian dari masalah dan apa yang membuatnya sangat sulit untuk memahami apa yang terjadi dalam file csproj saat membacanya, yang menjadikannya pilihan yang buruk untuk format file proyek (jangan dikacaukan dengan format file definisi build)

(Sunting: ditambahkan)

Masih tidak ada yang menghentikan Anda menggunakan sistem build pilihan Anda, baik itu CAKE atau TFS Team Services atau apa pun.

Sayangnya itu berarti bahwa kita terjebak mencoba untuk memasang sistem build kita ke MSBuild jika kita ingin VS dapat berbicara dengannya (dan berfungsi dengan baik ketika ada kode terkelola dan asli dan kita ingin men-debug). Inilah sebabnya, sebenarnya, saya percaya ini adalah _fitur_ untuk memisahkan file proyek dari file build.

Haha yeah @cwe1ss (berbicara tentang peningkatan perkakas!) Saya hanya berpikir bahwa GitHub sangat buruk ketika ada hal-hal yang pecah dalam percakapan. Kami punya seperti 3 utas di sini. Dan saya baru saja memulai yang lain. :kecewa:

Bolehkah saya menyarankan kita semua melompat pada standup komunitas berikutnya pada hari Rabu? Saya menduga itu sebagian besar akan berbicara tentang rilis RC2 satu atau dua hari sebelumnya (seseorang bisa berharap!) tetapi itu akan memberi kita semua kesempatan untuk melakukan ping kepada mereka dengan pertanyaan yang diperlukan dan melakukan diskusi jujur ​​​​yang baik dengan audiens langsung yang benar-benar dapat memberikan jawaban.

Bolehkah saya menyarankan kita semua melompat pada standup komunitas berikutnya pada hari Rabu?

Hanya jika @shederman mewakili. Saya ingin melihatnya menghancurkan pengembang dan ide-ide mereka secara real time. Seperti acara PPV WWE!

Saya pikir keuntungan dari project.json dibandingkan [projectName].csproj bukan tentang formatnya. Ini tentang tidak perlu kompatibel dengan semua barang lama. Itu memungkinkannya menjadi sangat sederhana. Dengan asumsi Damian Edward dan tim dapat memenuhi semua tujuan yang ditentukan, saya tidak terlalu peduli tentang XML versus JSON versus YML versus... Yang penting bagi saya adalah kesederhanaan dan tidak harus melihat hal-hal yang ada untuk Windows ketika saya menggunakan Linux .

@glennsills Saya tidak berpikir ada banyak hal dalam file proyek MSBuild yang khusus untuk _windows_, itu lebih khusus untuk MS Build itu sendiri, atau jenis proyek lain yang tidak Anda pedulikan. Benar-benar tidak perlu memiliki banyak elemen kosong hanya untuk membuat MSBuild senang. Saya berharap tim berencana untuk memangkas sebanyak mungkin, tapi kita lihat saja nanti.

@Mike-EEE Hanya jika @shederman mewakili. Saya ingin melihatnya menghancurkan pengembang dan ide-ide mereka secara real time. Seperti acara PPV WWE!

Saya akan mencoba membuatnya. Saya memperingatkan Anda bahwa saya berbicara lebih lambat daripada saya mengetik, jadi jangan terlalu berharap

Jadi, dengan risiko membuka sekaleng worm, mengingat https://github.com/dotnet/roslyn-project-system/issues/40 bagaimana perasaan orang tentang file csproj yang benar-benar dipotong yang hanya berisi (Secara default ) hal-hal penting untuk proyek tersebut?

(Tolong jangan ubah ini menjadi omelan "Saya benci XML!").

Bagaimana dengan "Saya benci omelan MSBuild"?

@shederman

Bagaimana jika kita membuat MSBuild menerima file JSON? :tertawa: (Tidak tahan)

@shederman sulit untuk menanggapi omelan apa pun dengan serius dan saya lebih suka Microsoft menanggapi _diskusi_ ini dengan serius.

Dalam 5 tahun, Anda akan memprogram Swift, Java(!!), Node.JS atau Elixir. ;)

Ada dua teknologi jelek saat ini di .NET proyek/Solusi/apa pun. File Nuget dan .csproj. Jika Anda bekerja di 5+ tim menggunakan Git (dan misalnya GitFlow) itu adalah mimpi buruk total. "Oh sial jika lupa memasukkan file dalam .csproj" semakin melelahkan. Perkakas harus memperbaikinya, perkakas juga harus memperingatkan saya bahwa saya memiliki versi DLL yang bertentangan, perkakas akan membantu saya menggabungkan.

Potong omong kosong. Project.json tampak bagus pada awalnya, tetapi kemudian politik dan perasaan terjadi.

Tim MS harus menyebutnya beta, bukan RC.
Sepertinya saya tidak bisa percaya bahkan ketika RTM akan dirilis, 'jika mungkin Tim MS memutuskan untuk mengirimkan RTM2 yang merusak segalanya lagi.
Saya bukan pesimis tetapi pergerakan di sekitar .NET Core ini sangat aneh.

@neoKushan Saya akan mencoba dan bersikap

Saya tidak setuju dengan syarat diskusi di mana saya harus melepaskan posisi yang saya pegang untuk memasuki diskusi. Saya terus mendengar bagaimana kita yang untuk project.json pada dasarnya harus menerima apa yang telah diputuskan MS, dengan mungkin satu atau dua modifikasi kecil.

Saya tidak melihat bagaimana hal itu terjadi. Saya hanya ingin membangun sistem yang dijanjikan, dan berkomitmen. Jika MS tidak mau mempertahankan dan melanjutkannya, saya sudah menawarkan.

Jadi di mana masalahnya? Saya tidak meminta MS untuk mundur dari rencana mereka, saya tidak meminta mereka untuk menambah pekerjaan. Saya hanya meminta mereka untuk mengizinkan saya memenuhi janji yang mereka ingkari secara sepihak.

Bukan permintaan yang revolusioner.

2 sen saya:

Saya percaya bahwa ada dua jenis orang yang mendiskusikan perubahan ini:

pengembang yang telah menggunakan VS & .NET untuk membangun berbagai jenis proyek dan harus mendukung proyek tersebut untuk waktu yang lama
pengembang yang tidak memiliki beban seperti itu dan menginginkan kerangka kerja ASP.NET Core lintas platform yang baru, bersih dan mewah
Secara pribadi, saya berada di kategori pertama jadi saya ingin ASP.NET Core baru agar kompatibel dengan jenis proyek VS lainnya, dan pindah ke solusi csproj/msbuild "lama" adalah kemenangan bagi saya (+ tim dan mungkin banyak pengembang lain). Dengan cara ini transisi akan jauh lebih halus dan jelas. Mungkin orang-orang dari kategori kedua tidak akan setuju dengan saya (atau mereka tidak peduli).

Satu-satunya masalah utama yang saya lihat sekarang adalah bagaimana paket NuGet didefinisikan dan dirujuk. Sangat sulit untuk mempertahankan file package.config dan csproj (seperti yang telah disebutkan oleh @cwe1ss di #1433 (komentar) ). Itu adalah salah satu komentar paling membangun dalam topik ini BTW...

Adapun perang suci XML/JSON ... IMHO, XML lebih baik untuk mengedit tangan daripada JSON. XML mendukung komentar dan memiliki lebih banyak informasi konteks saat Anda melihatnya. JSON lebih baik untuk data, bukan untuk file konfigurasi. Penggabungan sama-sama baik dan buruk untuk kedua format, itu semata-mata tergantung pada kontennya. Jika referensi proyek akan dipisahkan dari penggabungan file csproj saat ini akan menjadi lebih mudah juga...

Saya juga masuk dalam kategori satu (pengembang yang telah mengembangkan banyak proyek/jenis dan perlu mendukungnya untuk waktu yang lama). Majikan saya memiliki jutaan baris kode proyek dalam format csproj dan kami juga memiliki produk baru yang berjalan di cabang pengembang ASP.NET RC1 dan RC2. Peringatan yang adil, kami juga membuat penggunaan lanjutan MSBuild dengan rakitan tugas MSBuild khusus, dll.

Integrasi dunia nyata antara keduanya telah menjadi kecelakaan (karena berbagai alasan), terutama mengingat hal-hal seperti menghasilkan wraps, membuat ulang wraps ketika dependensi yang dibungkus berubah, seperti apa ini dalam kontrol sumber (kami secara internal mendukung dan menggunakan Git dan TFVC ), bagaimana proyek saling mereferensikan dalam solusi pada waktu desain di VS versus bagaimana proyek tersebut ditarik pada waktu pembuatan/penerapan. Sistem tidak pernah merasa _benar_. Tidak masuk akal bahwa saya dapat memiliki dua proyek terpisah, masing-masing hanya dengan file .cs, tetapi kedua jenis proyek ini tidak dapat berbaur dengan baik.

Pada akhirnya, saya sangat mengerti mengapa penting untuk mendukung aplikasi dan kode yang telah ditulis hingga saat ini. Saya tidak berpikir bahwa ini adalah waktu yang tepat untuk memperkenalkan jenis perubahan ini, dengan semua perubahan lain yang terjadi - rasanya terlalu banyak yang terjadi sekaligus.

Mungkin solusi masa depan yang mungkin adalah bahwa kita mengambil isyarat dari beberapa orang lain dan berpikir tentang rilis LTS atau yang serupa? Ini adalah percakapan yang jauh lebih besar, tetapi kemudian beberapa fitur seperti penggantian sistem proyek dapat diperkenalkan dan memberi orang waktu untuk menyerapnya.

Solusi lain yang mungkin adalah sistem build yang lebih mudah dipasang, tetapi ini adalah solusi jangka panjang dan tidak membantu percakapan saat ini. Pada dasarnya, izinkan salah satu/atau/3 pihak.

Tentang dependensi proyek, kami sudah memiliki banyak sekali file package.config yang beredar, mem-portingnya ke package.json/nuget.json bukanlah masalah besar. Saya memiliki lebih banyak masalah dengan pengalihan pengikatan Majelis yang tidak konsisten daripada yang saya lakukan dengan format penyimpanan untuk dependensi.

@shederman Anda telah membuat pendapat Anda tentang MSBuild sangat terkenal, tetapi yang belum Anda jelaskan adalah _issue_ Anda yang sebenarnya dengan MSBuild. Inilah yang menurut saya sangat membuat frustrasi, saya hanya ingin tahu masalah sebenarnya yang Anda temui dengan MSBuild karena saya benar-benar merasa bahwa masalah itu dapat diatasi.

Oke jadi Anda tidak suka XML, oke - perdebatan antara JSON dan XML bukanlah hal baru dan kami tidak akan pernah menyelesaikannya di sini. Namun, itu tidak bisa menjadi _only_ alasan Anda sangat membenci MSBuild. Apa masalah sebenarnya yang Anda temui?

Alasan saya bertanya - dan alasan saya terus bertanya, adalah karena ini adalah masalah persis yang ingin diperbaiki Microsoft dan kecuali kami menjelaskan masalahnya, masalah tersebut tidak akan diperbaiki. Banyak hal yang kami benci tentang MSBuild sudah diperbaiki yang kami ketahui:

1. Daftar setiap file dalam proyek - sedang dihapus/diperbaiki (Sebenarnya masalah VS)
2. Gabungkan neraka - Diperbaiki oleh 1. dalam banyak kasus
3. Kompleksitas / Verbositas yang tidak perlu - Semoga diselesaikan oleh https://github.com/dotnet/roslyn-project-system/issues/40
4. Tidak mudah diedit dengan tangan - Sekali lagi, diperbaiki oleh 1. dan 3.

Apa yang tersisa? Mari kita benar-benar membahas masalah dengan MSBuild dan melihat apakah ada solusi yang tidak melibatkan forking segalanya atau meninggalkan puluhan ribu proyek bisnis-penting yang rumit. Itulah diskusi yang saya _ingin_ lakukan.

2 sen saya untuk ini:
Mengapa perubahan semacam ini terjadi sekarang? Menurut roadmap hanya tersisa 1 bulan sampai rilis final.
Ketika saya pertama kali melihat ini, saya pikir ini adalah lelucon. Tapi sayangnya tidak.
Ini adalah tamparan besar tepat di wajah komunitas. Keputusan seperti itu harus memiliki utas percakapan yang panjang SEBELUM diadopsi, bukan setelahnya.

@laskoviymishka (dan beberapa lainnya) seperti yang telah dicatat oleh @neoKushan di sini, perubahan ini _tidak_ terjadi sekarang, ini akan menjadi perubahan pasca RTM (bahkan RTM akan secara bertahap). Jadi semua pembicaraan tentang "mengapa perubahan menit terakhir" adalah sedikit argumen yang salah, ada _is_ waktu untuk melihat bagaimana segala sesuatunya akan berkembang.

@laskoviymishka Perubahan tidak terjadi sebelum RTM.

RTM masih akan menggunakan project.json seperti yang digunakan hari ini (saya percaya skema berubah untuk RC2 tapi itu tetap terjadi). Perpindahan ke csproj "baru" dijadwalkan terjadi setelah RTM dan akan dilakukan secara bertahap. Tidak ada yang berubah di RTM (Kecuali xproj diganti namanya).

@CodingGorilla ini adalah RC2, yang ditransfer ke versi 1.0 dalam sebulan. Di dunia nyata ini berarti Anda berhenti mengembangkan segalanya dan berkonsentrasi pada stabilisasi. Perubahan ini sebenarnya tidak menstabilkan apapun.

@neoKushan jika itu akan terjadi setelah RTM, mengapa tidak meminta komunitas tentang hal itu? Mulai utas diskusi di github. Mulai menunjuk pada argumen dll. Mengapa harus dipaksakan tanpa percakapan dengan pengembang?

IMHO perpindahan ini dari project.json ke project.csproj harus didiskusikan sebelum diadopsi. Saat ini itu bukan keputusan yang baik, setidaknya bagi saya.

@laskoviymishka Dari komunitas berdiri catatan : (penekanan ditambahkan)

Di RC2 / Preview 1, tidak akan ada perubahan . Di RTM / Pratinjau 2, _satu-satunya perubahan Anda akan melihat apakah file xproj akan diganti namanya oleh Visual Studio menjadi csproj_. Sejak saat itu, project.json akan berada di sebelah csproj. Tim kemudian akan mulai memigrasikan fitur dari project.json ke file csproj. Kemungkinan file project.json tetap ada, dan berisi semua referensi paket untuk NuGet dan diganti namanya menjadi nuget.json. Tim telah menguji beberapa pekerjaan yang menunjukkan bahwa Anda tidak perlu membuat daftar semua file dalam file proyek Anda, salah satu manfaat utama dari model project.json.

Jadi ini sebagian besar merupakan perubahan perkakas, dan dalam jangka pendek (yaitu RTM+) file project.json akan tetap ada dan masih berfungsi sama seperti sekarang. Kabar baiknya tentang ini, saya pikir, masih ada waktu bagi masyarakat untuk berdampak pada ini, jika kita bisa menjaga hal-hal yang sipil dan konstruktif.

@laskoviymishka Yah, saya tidak benar-benar ingin berbicara untuk Microsoft, saya tidak tahu apa rencana akhir mereka, tetapi saya pikir mereka juga tidak benar-benar tahu. Banyak orang mengatakan bahwa permadani ditarik keluar dari bawah mereka dan Microsoft seharusnya berkonsultasi dengan kami sebelum memutuskan ini, tetapi secara realistis tidak ada yang berubah dan tidak ada yang akan berubah selama berbulan-bulan - ditambah ketika perubahan itu terjadi, itu akan terjadi. perubahan bertahap dan mudah-mudahan salah satu yang sedikit banyak akan dilakukan untuk Anda.

Microsoft, atau setidaknya tim asp.net, telah meminta umpan balik tentang ini dan tidak diragukan lagi mereka membaca utas ini, tetapi mungkin yang kami lewatkan adalah buletin atau posting definitif dari Microsoft yang mengatakan "Jika Anda ingin mendiskusikannya, lakukan _di sini_". Namun, saya pikir transisi jauh lebih awal daripada yang dipikirkan orang. Sejauh ini satu-satunya hal yang mereka tahu pasti mereka lakukan adalah mengganti nama xproj menjadi csproj.

Saya pribadi merasa bahwa meskipun sedikit perubahan omong kosong yang harus dilakukan, saya mengerti alasan mereka untuk melakukannya. Saya tidak punya jawaban yang lebih baik, jadi pendapat saya adalah jika kita harus berurusan dengan proyek gaya csproj, maka sebaiknya kita memanfaatkan periode ini untuk menyajikan _jenis_ csproj terbaik yang kita bisa. Itu tidak akan menjadi project.json, tetapi jika kita bisa mendapatkan yang terbaik dari kedua dunia maka dalam jangka panjang, kita semua akan menjadi lebih baik. Tidak semua orang setuju dan tidak apa-apa.

@neoKushan ini poin yang bagus, semoga MS akan melihatnya. Akan sangat menyenangkan untuk melihat umpan balik dari tim inti.

@CodingGorilla yah masih ada perubahan di versi final, yaitu melanggar. Masalah utama dari perubahan tersebut adalah bahwa tim inti harus menghabiskan banyak waktu tanpa hasil. Kemungkinan besar ini adalah masalah manajer. Mari kita habiskan banyak waktu dev hanya untuk mengubah satu hal yang berfungsi ke hal lain yang mungkin berfungsi. Tanpa alasan yang benar-benar bagus.

@neoKushan

Mari kita benar-benar membahas masalah dengan MSBuild

Saya mengalami kesulitan menemukan info yang cukup untuk membentuk opini. Ada banyak perubahan yang _tampaknya_ diaktifkan oleh project.json dan penghapusan file .csproj. Saya tidak ingin peningkatan ini hilang, tetapi saya tidak tahu bagaimana pindah ke msbuild "baru dan lebih baik" akan mengubah alur kerja saya:

• Saat ini, kami menggunakan gulp untuk setiap tugas build. Apakah itu berubah? Gulpfile saya hanya mengeksekusi ke dnu atau dotnet-cli untuk benar-benar mengubah kumpulan file .cs menjadi rakitan. Aku bisa menyimpannya, kan?
• Akankah VS terus mendukung penjelajah tugas, dan pemicu afterbuild/prebuild/etc untuk tugas tegukan saya, sehingga pengguna VS dapat menjalankan F5? Atau apakah saya harus memiliki msbuild kick off gulp yang berarti bahwa semua tugas gulp saya memerlukan tugas wrapper msbuild yang ditentukan? (Aduh)
• Apakah msbuild di instal terpisah? Apakah akan diversi secara terpisah dari dotnet cli atau runtime? Bagaimana ini mengubah minimum yang harus tersedia di server pembuatan CI saya? Minimum untuk menginstal pada lingkungan dev?
• Jika saya menggunakan editor teks untuk menambahkan dependensi nuget atau file .cs, langkah tambahan apa yang sekarang harus saya tambahkan, jika ada?
• Ketika saya meninjau perubahan di mana pengguna VS menambahkan ketergantungan nuget dan file .cs, apakah perubahan csproj akan sederhana dan dapat dibaca manusia? (Sebagai perbandingan, dengan .net 4.6 dan VS2015, menurut saya perubahan pada csproj _tidak_ mudah dibaca manusia.)

Saya ingin melihat orang-orang yang membuat perubahan ini menjangkau skenario yang perlu mereka pertimbangkan (seperti saya!), dan diskusi seputar ini terjadi. Saya harap "hei, kami memindahkan keju Anda tanpa diskusi" hal semacam itu tidak menjadi SOP .net core.

perkakas itu kurang lebih akan melakukannya untuk Anda

Dan itulah inti utamanya. Semakin sedikit perkakas _diperlukan_, semakin baik. Saat ini saya dapat menggunakan editor teks dan baris perintah tanpa merasa seperti sedang berenang ke hulu. Saya harap itu tidak berubah. Di tanah .net46 saya harus mengedit file xml raksasa dan verbose jika saya tidak ingin menggunakan VS, dan mencampur pengguna VS dengan pengguna non-VS pada proyek yang sama adalah mimpi buruk.

"Selamat datang di RTM. Ini adalah pengingat bahwa file proyek Anda akan berubah dalam waktu dekat. Kami telah memutuskan ini. Alasan, tetapi sebagian besar karena kami lebih menyukai sudut daripada curlies oh dan membangun alat, ya, membangun Kami belum menentukan skema akhir (tetapi akan berbasis xml, lihat di atas), dan nama file pasti akan diakhiri dengan .csproj untuk membuang kebingungan maksimum ke perkakas lawas mana pun. Agile. (ps jika Anda seorang vendor alat: :o)"

@Oceanswave contoh indah bagaimana Anda seharusnya tidak mengelola pengembangan perangkat lunak Anda

@neoKushan

tetapi yang belum Anda jelaskan adalah masalah Anda yang sebenarnya dengan MSBuild

Mungkin Anda harus membaca jawaban saya sebelumnya untuk pertanyaan yang sama persis ini dari Anda? https://github.com/aspnet/Home/issues/1433#issuecomment -218993559

Saya telah menghabiskan ratusan jam selama bertahun-tahun untuk memperbaiki, mengembangkan, dan men-debug file MSBuild. Saya telah melakukan Pembangunan Tim, saya telah melakukan pembangunan dan penyebaran jaringan pipa yang besar. Saya telah menghabiskan berjam-jam meneliti log verbose mencoba mencari tahu mengapa beberapa situasi aneh terjadi. Saya telah membayar iuran saya selama bertahun-tahun untuk teknologi ini, dan saya pribadi tidak ingin ada hubungannya dengan itu. project.json adalah angin segar. Setelah bertahun-tahun menderita dengan MSBuild, kami akhirnya mendapat kesan bahwa MS mendapatkannya, bahwa perubahan diperlukan dan sedang diterapkan.

Dan itu sangat mulia. Pembuatan sederhana, pengeditan sederhana, keluaran cepat dan mudah dipahami. Itu menghapus memori dari jam-jam bersumpah pada skrip MSBuild. Rasanya seperti kami akhirnya melepaskan diri dari mayat masa lalu. Tapi tidak, sekarang kita dibelenggu kembali ke mayat yang sangat kita benci, meskipun janji itu tidak akan terjadi.

Tanpa diskusi, tanpa ulasan, tanpa keterlibatan apa pun.

Fakta bahwa Anda bahkan tidak menyadari seberapa banyak MSBuild dibenci di beberapa tempat hanya membuktikan bahwa Anda tidak melakukan ketekunan pada keputusan ini.

Saya tidak percaya MSBuild memiliki batasan fungsional yang signifikan sebagai sistem build. Ini sangat kuat, dan dalam arti itulah kelemahan utamanya. Ini rumit karena harus menangani begitu banyak skenario. Untuk skenario sederhana "pulihkan, bangun, uji, bungkus" itu benar-benar berlebihan.

Di tim saya, kami berurusan dengan pengembang C#. Mereka berada di bawah tekanan, tenggat waktu yang ketat, stres yang tinggi. Mereka tidak menginginkan apa pun yang menghalangi atau menunda mereka.

MSBuild adalah cara berpikir yang berbeda, konteks utama beralih dari pengkodean imperatif. Para dev hanya membencinya. Mereka menganggapnya tumpul dan kontra intuitif. Mereka menghindarinya. Satu-satunya MSBuild yang dibuat di salah satu tim yang saya awasi hari ini adalah alat yang dibuat.

Saya belum pernah bertemu pengembang C# dalam 5 tahun terakhir atau lebih yang tertarik, atau senang bekerja dengan MSBuild. Lihatlah beberapa komentar dalam beberapa hari terakhir di Github. Saya tidak sendirian dalam ketidaksukaan saya terhadap MSBuild. MSBuild telah dianggap sebagai batu kilangan di sekitar leher pengembang .NET selama satu dekade. Apakah banyak dari persepsi itu tidak adil? Ya, sangat mungkin.

Tapi jadi apa? Dari sudut pandang saya sebagai Kepala Rekayasa Perangkat Lunak, saya membutuhkan alat yang menghasilkan hasil yang saya inginkan. Saya tidak mendapatkan hasil tersebut dengan MSBuild. Saya mendapatkan hasil tersebut dari project.json + gulp.js + powershell.

_Can_ MSBuild memberi saya hasil itu? Tentu bisa, tetapi hanya jika pengembang melakukan pekerjaan di MSBuild untuk mendapatkan hasil tersebut. Dan mereka tidak melakukannya. Ketika kita memaksa mereka, mereka melakukannya, dan kemudian tidak mempertahankannya.

Saya tidak bisa mengandalkan alat yang dibenci para pengembang. Itulah kenyataan sederhana. Dan mengingat betapa saya sangat suka tidak menggunakannya sendiri, saya sebenarnya tidak bisa menyalahkan mereka.

Mari kita benar-benar membahas masalah dengan MSBuild dan melihat apakah ada solusi yang tidak melibatkan forking segalanya atau meninggalkan puluhan ribu proyek bisnis-penting yang rumit.

Oke, jadi, apa yang bisa dilakukan?

Sekitar 5 tahun yang lalu, jika beberapa perubahan yang sedang dibahas sekarang telah diperkenalkan, saya pikir persepsinya akan lebih baik. Tapi mereka tidak dan sekarang memiliki mindshare negatif utama di antara sejumlah besar pengembang. Seingat saya beberapa masalah yang sama diangkat dengan MSBuild saat itu, dan ditolak. Sama seperti isu-isu saat ini sedang diangkat, dan ditolak.

Saya tidak tahu bagaimana itu bisa memulihkan itu, saya benar-benar tidak. Saya pikir harus ada beberapa istirahat bersih besar. Bagaimana Anda membuatnya tanpa merusak apa yang ada di sana? Ini terlalu sedikit, sudah terlambat. Jadi saya tidak melihat jalan ke depan dengan MSBuild, bukan untuk saya, bukan untuk para pengembang yang bekerja untuk saya, tidak dengan mitra saya, atau tim yang bekerja untuk _them_, bukan di klien tempat kami berkonsultasi. Tak satu pun dari audiens tersebut ingin menggunakan MSBuild, mereka menggunakannya dalam perkakas karena mereka harus, dan mereka bersumpah berulang kali. Memang biasanya sekitar waktu penggabungan.

Jadi _now_ Anda ingin membuat penggabungan lebih baik? 10 tahun berlalu. Setelah alat adalah kata umpatan di banyak tempat?

Pada dasarnya Anda menggunakan alat yang dirancang untuk Build Masters di akhir tahun 90-an yang sebenarnya digunakan oleh pengembang setelah tahun 2010. Alat yang menggunakan inferensi untuk logikanya digunakan oleh pengembang yang digunakan untuk pekerjaan imperatif, dan alat imperatif. Alat yang menggunakan cara yang sangat fleksibel, tetapi tidak jelas untuk menyetel properti yang digunakan oleh pengembang yang menganggap set properti adalah operator penugasan sederhana dan tidak mengerti mengapa Anda bahkan ingin melakukan PropertyGroup dan don tidak peduli untuk mencari tahu.

Itulah diskusi yang ingin saya lakukan.

Tentu, saya mengerti. Diskusi yang ingin saya lakukan berbeda, itu adalah "beri kami apa yang Anda janjikan kepada kami, atau biarkan kami memberikannya kepada diri kami sendiri, karena kami tidak menyukai ide lama Anda yang baru, dan kami melakukan seperti yang dijanjikan".

Bolehkah saya berbagi sesuatu yang menyedihkan? Dari mitra bisnis saya, yang memiliki pengalaman yang sama dengan saya (lebih tepatnya), saya adalah yang paling pro-MSBuild saat itu. Saya sebenarnya _menggunakannya. Saya mempelajarinya. Saya membangun jaringan pipa besar. Tapi itu lebih dari 5 tahun yang lalu, dan banyak air telah mengalir ke bawah jembatan sejak saat itu.

Astaga, saya menemukan diri saya mengangguk deras saat membaca komentar dan riwayat @shederman karena sangat mirip dengan saya. Saya telah menghabiskan begitu banyak waktu di MSBuild dan DSL-nya dan benar-benar telah digigit beberapa kali (belum lagi jumlah waktu yang dihabiskan karena harus mempelajarinya). Sintaks dan pendekatannya tidak seperti apa pun di .NET dan itu adalah bagian dari masalah (itulah sebabnya saya mengatakan reboot/redo/perbaiki model objeknya dan coba lagi). Itu akan menjadi perhatian utama saya: itu adalah warisan sehingga cara pendekatannya terhadap masalah tidak seperti apa pun yang harus dikerjakan oleh pengembang (.NET), dan ini mengasingkan produk, daripada mempromosikan minat/adopsi.

Pikirkan: Ekstensi Visual Studio (.vsix). Tidak ada yang ingin menyentuhnya karena betapa warisan/tua/berbedanya mereka dibandingkan dengan segala sesuatu yang ada di luar sana akhir-akhir ini. Nah, Anda memiliki BEBERAPA pengembang yang ingin, karena mereka telah membayar iuran mereka dalam mempelajari sistem rahasianya -- seperti MSBuild.

Saya juga mungkin yang paling berpengalaman di antara siapa pun yang saya kenal secara profesional yang pernah berurusan dengan MSBuild. Sebagian besar pengembang tidak ingin menghabiskan banyak waktu untuk mempelajarinya (karena Anda pasti melakukannya). Ini hampir seolah-olah itu adalah bahasanya sendiri.

Jika "lebih mirip .NET" (dan memiliki integrasi yang lebih baik dengan VS) maka saya pikir kita semua akan setuju bahwa itu akan menjadi produk yang lebih baik untuk dikerjakan dan proposisi yang menarik untuk dipertimbangkan.

@Mike-EEE & @shederman Untuk poin Mike, yang lama, kuno dan "tidak seperti apa pun (.NET) pengembang harus bekerja dengan...". Tapi apakah itu tidak bisa diperbaiki? Mereka telah mengakui bahwa ada masalah yang ingin mereka perbaiki, jadi pertanyaannya adalah: Apakah itu bisa diperbaiki? Saya pikir saya tahu tanggapan @shederman , saya bahkan sebagian besar setuju dengan alasannya (saya setuju dengan tema yang membangun dan sistem proyek adalah campuran kekhawatiran yang aneh).

Sekali lagi, saya tidak punya kuda dalam perlombaan ini, saya tidak keberatan jalan mana pun yang mereka pilih. Saya sangat suka mendapatkan reaksi jempol dan mendengar diri saya berbicara (dengan sisi minat intelektual yang sebenarnya dalam percakapan :laughing: )

Saya sangat suka mendapatkan reaksi jempol dan mendengar diri saya berbicara (dengan sisi minat intelektual yang sebenarnya dalam percakapan :laughing: )

Saya senang bisa membantu! :senyum:

Tapi apakah itu tidak bisa diperbaiki? Bisakah itu diperbaiki?

Tergantung pada siapa Anda bertanya, sebenarnya. Mengangkat masalah pada repo mereka seperti yang disarankan @shederman itu sulit dan menantang (dan ya, saya menyensor kata-kata saya di sana :stuck_out_tongue: ). Tampaknya mereka diatur dengan cara mereka. Tapi, seperti yang Anda ketahui dengan sifat perangkat lunak, segala sesuatu mungkin terjadi dengan waktu dan usaha yang cukup. :mengedip:

@PhilipRieck Anda mengajukan beberapa pertanyaan yang sangat bagus! Sayangnya saya tidak memiliki jawaban pasti untuk semuanya, tetapi mari kita lihat:

Saat ini, kami menggunakan gulp untuk setiap tugas build. Apakah itu berubah? Gulpfile saya hanya mengeksekusi ke dnu atau dotnet-cli untuk benar-benar mengubah kumpulan file .cs menjadi rakitan. Aku bisa menyimpannya, kan?

Saya tidak _berpikir_ ini akan berubah, saya 95% yakin bahwa apa yang kita bicarakan di sini hanya mempengaruhi _definition_ proyek, bukan bagaimana proyek itu sebenarnya dibangun (Setidaknya di luar memanggil dotnet build). CLI dotnet mungkin memanggil MSbuild di beberapa titik tetapi pada saat itu itu adalah hal yang tersembunyi.

Apakah msbuild di instal terpisah? Apakah akan diversi secara terpisah dari dotnet cli atau runtime? Bagaimana ini mengubah minimum yang harus tersedia di server pembuatan CI saya? Minimum untuk menginstal pada lingkungan dev?

Saya tidak memiliki jawaban pasti untuk ini, tetapi saya akan _membayangkan_ bahwa MSBuild hadir sebagai bagian dari dotnet CLI sebagai instalasi yang sepenuhnya terpisah, bahkan jika Anda sudah menginstal MSBuild (Katakanlah dengan VS). Spekulasi murni di pihak saya. Saya tahu bahwa tujuan besar dari keseluruhan proyek ".net di mana-mana" ini adalah untuk meminimalkan keributan agar orang-orang berkembang. Harus benar-benar apt-get dotnet-cli (atau apa pun), dotnet baru, dotnet build. Anda seharusnya tidak perlu menelepon ke MSBuild untuk membangun proyek, itu tugas dotnet-cli.

Jika saya menggunakan editor teks untuk menambahkan dependensi nuget atau file .cs, langkah tambahan apa yang sekarang harus saya tambahkan, jika ada?

Untuk file .cs, jelas tidak ada yang lain, sama seperti hari ini - satu hal yang sangat jelas adalah bahwa hari-hari untuk menentukan setiap file .cs dalam proyek Anda sudah terlewati (walaupun mungkin Anda masih bisa melakukannya jika Anda mau , melihatmu @Mike-EEE). Adapun dependensi, tentu dalam jangka pendek (jangka pendek menjadi bulan), mereka akan tinggal di project.json dan bekerja persis seperti sebelumnya. Ada kemungkinan project.json akan menjadi nuget.json dan selain dari perubahan nama, tidak ada perubahan lain, tetapi ada kemungkinan lain untuk ini dan ini tampaknya menjadi salah satu hal utama yang Microsoft sangat tidak yakin - biarkan suara Anda didengar pada preferensi Anda untuk ini.
(Preferensi pribadi saya adalah mampu melakukan sesuatu seperti.nuget.json tapi itu hanya saya spitballing).

Ketika saya meninjau perubahan di mana pengguna VS menambahkan ketergantungan nuget dan file .cs, apakah perubahan csproj akan sederhana dan dapat dibaca manusia? (Sebagai perbandingan, dengan .net 4.6 dan VS2015, menurut saya perubahan pada csproj tidak mudah dibaca manusia.)

Untuk file .cs, csproj seharusnya tidak berubah sama sekali. Untuk dependensi nuget - pertanyaan bagus, sekali lagi ini agak mengudara. Seharusnya tidak menyebabkan csproj berubah tetapi penentu besar saat ini adalah apakah nuget harus hidup di nuget.json atau jika csproj harus memiliki barang itu - dan jika mereka terpisah, seberapa sulitkah untuk kandang dua?

Dan itulah inti utamanya. Semakin sedikit peralatan yang dibutuhkan, semakin baik. Saat ini saya dapat menggunakan editor teks dan baris perintah tanpa merasa seperti sedang berenang ke hulu. Saya harap itu tidak berubah. Di tanah .net46 saya harus mengedit file xml raksasa dan verbose jika saya tidak ingin menggunakan VS, dan mencampur pengguna VS dengan pengguna non-VS pada proyek yang sama adalah mimpi buruk.

Saya sepenuhnya dan sepenuhnya setuju dengan ini, tetapi Microsoft telah menginvestasikan terlalu banyak ke dalam upaya lintas platform mereka untuk tiba-tiba menjadikannya mimpi buruk untuk dilakukan. Dengan "perkakas", saya menduga itu akan turun ke .net CLI daripada VS atau semacamnya. Jangan lupa, "Permainan Akhir" pamungkas untuk .net core adalah menjadi platform yang sangat gesit dan bergerak sangat cepat, tetapi platform yang tidak memaksa Anda untuk menghabiskan waktu meningkatkan versi setiap beberapa minggu. Saya _cukup yakin_ bahwa jika Anda menulis aplikasi dotnet 1.0 pada bulan Juni, itu masih akan dibangun dan dijalankan bertahun-tahun dari sekarang, tetapi versi yang lebih baru akan menjadi kasus menjalankan "upgrade dotnet" atau sesuatu seperti itu ketika Anda siap . Bahkan ketika RTM mencapai, proyek RC2 masih akan membangun dan menjalankan bit RC2 sampai Anda benar-benar masuk dan mengubah target menjadi RTM (saya pikir di global.json atau di suatu tempat?).

:tertawa: Ketika saya membaca utas seperti ini, saya harus bertanya-tanya apakah Microsoft memiliki momen penyesalan. Saya sangat menghormati dan merasakan orang-orang yang telah melakukan dan melakukan yang terbaik untuk mengubah Microsoft secara menyeluruh, dengan tujuan membuat surga yang transparan, open-source, dan berpikiran komunitas bagi para pengembang. Orang-orang di balik transformasi ini memang peduli. Mereka adalah orang-orang baik. Mereka harus berada di antara batu dan tempat yang sulit sekarang; sentimen komunitas yang kurang konstruktif yang beredar (sambil menghibur saya) tidak membantu kasus mereka.

Saya ingin menunjukkan bahwa mengganti sekelompok fungsionalitas pembuatan proyek ajaib yang saat ini ada di IDE dengan aplikasi baris perintah yang melakukan banyak manipulasi csproj ajaib adalah ide yang buruk. Membuat file definisi proyek sesederhana mungkin adalah suatu keharusan. Bagian terbaik dari project.json adalah saya dapat membaca dan memahaminya.

@shederman Masalah Anda dengan MSBuild adalah bahwa dalam sistem yang besar dan kompleks itu besar dan kompleks....

Saya juga pernah bekerja dengan Team Builds dan saya juga sangat membencinya (Ping ke @Mike-EEE karena kami berdua membicarakan betapa buruknya pengalaman ini), saya mengerti , tetapi apa yang Anda gambarkan benar-benar berbeda skenario. MSbuild _can_ menjadi besar dan kompleks dan secara default VS _membuatnya besar dan kompleks - tetapi itulah yang berubah .

File csproj yang lebih baru seharusnya jauh lebih kecil, yang berarti "Debugging" harus sangat disederhanakan. Tidak ada (atau sedikit) cruft. Anda masih dapat menggunakan _build system_ apa pun yang Anda inginkan, Anda dapat memanggil file .bat yang hanya memanggil "dotnet build" di *.csproj dan Anda akan mendapatkan output yang Anda inginkan, seperti hari ini. Biarkan dotnet cli berurusan dengan MSbuild dan Anda bahkan tidak perlu menyentuhnya.

@neoKushan tidak, terima kasih.

Saya ingin apa yang dijanjikan, bukan lipstik pada apa yang kami diberitahu bahwa kami akan pindah.

Dan jika Anda tidak ingin memberi kami apa yang dijanjikan, biarkan kami memberikannya kepada diri kami sendiri. Itu semua sudah ada. Seharusnya hanya kasus menjaga refactoring. Saya akan melakukan pekerjaan, seperti yang saya katakan sebelumnya.

Saya menduga alasan nomor 1 mengapa tidak ada keinginan untuk meninggalkannya adalah kesadaran bahwa ini akan menjadi awal dari migrasi besar-besaran dari proyek MSBuild. Maaf, tetapi mempertahankan teknologi yang ketinggalan zaman pada dukungan kehidupan bukanlah salah satu tujuan desain .NET Core. Apakah itu?

Masalah terbesar dengan ms build in siapa yang akan memperbaikinya, dan berapa banyak waktu yang dibutuhkan. Saat ini seluruh proyek ASPnet mendapat lebih dari 1000 masalah terbuka, beberapa di antaranya sangat kritis. Lihat SignalR.
Ada satu bulan lagi sebelum rilis, dan bug ini hampir mendekati final state.

Dan sekarang mereka mengatakan bahwa ms build dapat ditingkatkan. Apakah MS memiliki sumber daya yang cukup untuk mengelola semua warisan ini ? Apakah masyarakat bisa mengatasinya? Saya tidak benar-benar percaya akan hal itu.

@shederman

Dan jika Anda tidak ingin memberi kami apa yang dijanjikan, biarkan kami memberikannya kepada diri kami sendiri.

Mereka tidak mencegah Anda melakukan APA SAJA. Silakan dan garpu itu, tidak ada yang menghentikan Anda. Jika Anda menunggu izin Microsoft, maka Anda sudah mendapatkannya, Anda mendapatkannya begitu mereka membuka kode sumbernya.

Itu semua sudah ada. Seharusnya hanya kasus menjaga refactoring. Saya akan melakukan pekerjaan, seperti yang saya katakan sebelumnya.

Maka lakukanlah? Sekali lagi, tidak ada yang menghentikan Anda.

Saya menduga alasan nomor 1 mengapa tidak ada keinginan untuk meninggalkannya adalah kesadaran bahwa ini akan menjadi awal dari migrasi besar-besaran dari proyek MSBuild.

Mengapa mereka peduli? Apa bedanya dengan Microsoft jika Anda menggunakan MSbuild atau yang lainnya?

Alasan nomor 1 sebenarnya adalah bahwa struktur proyek inti ASp.net hanya sangat bagus untuk inti asp.net. Ada ratusan jenis proyek lain di luar sana yang tidak cocok untuk project.json. Tidak peduli fakta bahwa project.json memiliki masalah sendiri, yang tampaknya telah kita semua lupakan - kurangnya komentar yang mengesalkan saya (dan tidak, menyarankan beberapa format lain-selama-selama-tidak-tidak- XML tidak membantu).

Maaf, tetapi mempertahankan teknologi yang ketinggalan zaman pada alat bantu hidup bukanlah salah satu tujuan desain .NET Core. Apakah itu?

Tidak, tetapi membantu orang memindahkan proyek lama mereka yang sudah ada ke .net core adalah tujuannya. Selain itu, kita berbicara tentang versi inti .net dari MSBuild, bukan versi desktop yang lengkap, ada perbedaan .

Satu-satunya masalah Anda adalah mereka berani menyebutnya MSBuild. Seandainya mereka datang dengan gaya proyek baru yang kebetulan XML tetapi disebut "CoreBuild" atau sesuatu, Anda tidak akan menjadi lebih bijaksana dan yang harus Anda lakukan hanyalah "Saya benci XML!".

Anda sedang menunggu izin Microsoft, maka Anda sudah mendapatkannya

Tidak sepenuhnya benar. Saya tidak ingin membayarnya , saya ingin mempertahankannya di repo utama. Ada perbedaan. Jadi tidak ada yang harus mengunduh .NET SDK yang sama sekali baru. Saya menginginkannya dalam perkakas, dan untuk itu, ya saya membutuhkan persetujuan mereka.

Satu-satunya masalah Anda adalah mereka berani menyebutnya MSBuild

Tidak, mereka ingin _menggunakan_ MSBuild. Sedikit, tapi perbedaan penting. Ganti nama sistem pembangunan project.json baru dan beri nama MSBuild dan saya akan menggunakannya dengan senang hati.

Anda tidak akan menjadi lebih bijak dan yang harus Anda lakukan hanyalah "Saya benci XML!"

Mungkin

Pokoknya, berputar-putar.

Pergi tidur.

Saya katakan biarkan saja untuk standup. Tidak ada yang meyakinkan siapa pun. Saya cukup yakin saya memahami sisi pro-MSBuild, tetapi saya tidak setuju dengan itu. Dan saya cukup yakin pihak pro-MSBuild memahami sisi tanpa-MSBuild, tetapi tidak setuju dengan itu.

Yang saya katakan adalah kita dapat memiliki keduanya. Tanpa (atau sangat sedikit) usaha ekstra dari tim MS. Kemudian biarkan pilihan tenggelam atau tenggelam dalam sorotan penggunaan produksi yang sebenarnya.

Per pertanyaan @neoKushan :

Apa yang tersisa?

Saya sebenarnya ingin membingkai respons saya, jika saya boleh, di sekitar "prinsip" yang saya uraikan di atas dengan apa yang saya yakini membuat file proyek yang baik dan dapat digunakan:

• Itu harus dapat diedit/dibaca oleh manusia

Mengambil pernyataan @neoKushan di atas berarti bahwa itu akan ditangani - Saya berasumsi seseorang di MSFT mengatakan/menulis ini. Dengan itu, saya ingin melihat proposal berbasis MSBuild di mana ini sebenarnya ditangani terlebih dahulu, sebelum "berkomitmen" (sebagai Komunitas/Kerangka) ke MSBuild.

Saya berasumsi menyingkirkan Guid ProjectType adalah salah satu item teratas yang harus ditangani?

Tapi saya mendukung tambahan saya di atas: Ini adalah persyaratan yang sulit (tidak dapat dinegosiasikan) bahwa untuk proyek sederhana (misalnya ASP.Net Hello World in Angular), saya dapat membuat keseluruhannya dengan tangan, di notepad. Jika saya perlu menggunakan Yeoman/VS/serupa, kami telah gagal mengusulkan file proyek yang dapat diedit manusia.

• Itu harus memungkinkan untuk komentar

Sudah bekerja, di MSBuild

• Itu harus deklaratif

Mengubah urutan First-Level (anak langsung dari) dapat mengubah seluruh arti proyek, seringkali dengan cara yang sulit di-debug. Tidak ada yang lebih menonjol daripada jika Anda membawa impor .targets ke atas secara tidak sengaja.

• Itu harus mandiri

Ini adalah masalah terbesar saya dengan MSBuild. Membaca file, secara statis, tidak memberi Anda cukup informasi untuk benar-benar mengetahui apa yang terjadi di sana. Dari file .targets yang berasal dari jalur yang ditentukan _variabel lingkungan_, dan fakta bahwa variabel lingkungan didukung oleh peristiwa, hingga persyaratan dan impor, bersama-sama Anda mendapatkan apa yang secara efektif merupakan lingkungan Turing Complete, dengan biaya tingkat kerumitan yang sangat tinggi , dan kemampuan alat yang buruk. Saya berpendapat bahwa integrasi luar biasa VS dari MSBuild adalah konsekuensi dari kesulitan membangun alat di sekitar itu.

Ini mirip dengan masalah keterbacaan/kemampuan edit manusia.

• Itu harus dirancang untuk mengurangi konflik penggabungan / menyederhanakan penggabungan, jika memungkinkan

MSBuild secara teknis mendukung ini dalam bentuk wildcard. Dukungan VS untuk wildcard lebih buruk daripada buruk. Ini secara aktif membuat lebih sulit untuk bekerja. Per di atas, saya bersedia menerima bahwa ini akan diperbaiki - tetapi itu harus menjadi item pada _proposal_ ke _migrate_ (dan ini adalah migrasi ke, karena semua pesan sejauh ini tentang project.json) ke MSBuild -berbasis file proyek.

• Itu harus sepenuhnya dapat didokumentasikan (dengan prinsip self-containment berlaku untuk dokumentasi)

Saya percaya MSBuild memiliki dokumentasi. Dokumentasi itu, terutama untuk _flavor_ VS dari MSBuild meninggalkan sedikit yang diinginkan. Saya sering bingung mengapa hal-hal yang berbeda ada dalam kelompok mereka, dan VS "membantu" memindahkan mereka tidak terlalu membantu.

Contoh sempurna adalah paket Bond NuGet. Berapa banyak orang yang tahu bahwa jika Anda tidak memiliki folder BondInclude pada disk (jika dirujuk di csproj), build secara misterius akan gagal untuk benar-benar menghasilkan salah satu jenis Bond ke dalam perakitan yang dihasilkan? (Tanpa kesalahan memuntahkan juga). Kemudian membuat folder kosong dengan nama itu dan memuat ulang proyek memperbaikinya.

(Ya, saya tahu, saya akan mengajukan bug di atasnya)

• Itu harus tidak bergantung pada alat

Katakanlah saya tidak ingin ada hubungannya dengan MSBuild (katakanlah karena saya merasa pelawan, tanpa membahasnya lebih jauh); Saya hanya ingin mendefinisikan proyek saya, dan menarik paket melalui nugget. Mengapa saya dipaksa menggunakan sistem build khusus ini? Terutama jika yang saya inginkan hanyalah mendefinisikan sebuah proyek?

File definisi build bukan format file proyek. Bahwa VS berhasil membuatnya berfungsi (agak) bukanlah alasan yang baik untuk terus menggunakannya. Saya ingin file nyata yang hanya mewakili proyek itu sendiri, dan informasi tentang artefak yang dihasilkannya (bukan instruksi cara membuatnya). Dalam hal ini, bahkan project.json gagal karena memungkinkan kita untuk mendefinisikan "perintah". Mengapa itu ada? Cukup tentukan jenis keluarannya, dan di mana ia dapat ditemukan.

Saya membaca seluruh utas ini, dan satu hal yang menarik bagi saya dalam diskusi tentang project.json vs project.csproj ini adalah bahwa hanya satu dari nama file tersebut yang memiliki seluruh bahasa pemrograman yang dimasukkan ke dalamnya. Saya lebih suka melakukan pengembangan ASP.NET di F#. Apakah itu mungkin di ASP.NET Core? Pada titik ini saya tidak memiliki ide sama sekali, tetapi saya merasa tidak demikian. Saya bahkan tidak yakin apakah orang menggunakan csproj sebagai singkatan untuk csproj, fsproj, vbproj atau apakah yang mereka maksud adalah csproj saja.

Pembaruan: orang-orang F# sedang mengerjakan dukungan CoreCLR, tetapi belum ada ETA nyata. Maksud saya adalah bahwa sistem proyek apa pun yang diputuskan sekarang akan memengaruhi bahasa pemrograman yang tampaknya bahkan tidak ada di radar orang saat ini. Sebanyak saya lebih suka JSON daripada XML, jika project.json akan mengunci saya ke C# (dan urutan file dalam kompilasi sangat penting dalam F#) maka saya tidak menyukainya.

Untuk saat ini sepertinya kembali ke FAKE dan Paket buat saya...

Saya bekerja dengan .NET sejak awal dan saya tidak pernah memiliki masalah penting dengan MSBuild. Alasan utama untuk itu adalah, saya tidak pernah menggunakannya untuk hal lain selain kompilasi solusi out-of-the-box.

Dan itulah yang saya tidak mengerti tentang ketidaksukaan ini terhadap MSBuild. Tidak ada yang memaksa siapa pun untuk menggunakan MSBuild untuk apa pun selain kompilasi solusi. Dan saya pikir, dapat mengkompilasi solusi adalah fitur yang cukup berguna - yang BTW bahkan belum ada di "dotnet cli" (Anda harus mengulang proyek secara manual sekarang - perbaiki saya jika saya salah).

Sistem build Anda yang sebenarnya tidak perlu diubah. Jika Anda menggunakan Nant, tetap gunakan Nant. Jika Anda menggunakan psake, tetap gunakan psake. Jika Anda menggunakan skrip PowerShell, tetap gunakan itu. Dll! Kemungkinan besar, hanya bagian "dotnet build" yang harus diganti dengan panggilan ke MSBuild. (Mungkin itu bahkan tidak diperlukan jika dotnet membangun panggilan ke MSBuild)

Saya berpendapat bahwa ini membuat MSBuild menjadi detail implementasi yang tidak terlalu penting. Begitulah cara saya melihatnya selama dekade terakhir dan itulah bagaimana saya akan terus melihatnya.

Tapi tentu saja, seperti yang sudah saya katakan di awal utas ini, yang pasti kita butuhkan adalah beberapa _fitur_ dari project.json dan Visual Studio untuk memperlakukan csproj dengan lebih baik - dan saya tidak mengerti mengapa mereka tidak melakukannya. dapat menyampaikan itu.

@jtmueller Sama sekali tidak ada alasan _technical_ mengapa Anda tidak dapat menggunakan F# (atau VB.net jika Anda ingin). Saya tidak akan terkejut jika bagian dari peralihan ke file proyek MSBuild adalah untuk membantu memfasilitasi itu. DNX tidak pernah benar-benar senang dengan itu, tetapi CoreCLR pasti mendukung F#. Saya tidak tahu apakah Anda akan dapat menggunakan F# come RTM tetapi itu pasti sedang dalam proses.

@jtmueller project.json cukup banyak definisi proyek dengan manifes ketergantungan, ditambah perintah kustom. Tidak ada yang terikat dengan bahasa tertentu sama sekali.

Sistem build impian saya (untuk menggantikan MSBuild seluruhnya) akan menggunakan Roslyn untuk mengetahui tugas dan target, memungkinkan Anda menggunakan F# untuk menentukan proses build Anda (atau C#, atau VB.NET, apa pun yang didukung Roslyn).

Tentu saja, belum ada yang mengusulkan itu. Tetapi mengunci kita kembali ke MSBuild hampir pasti akan menutup pintu itu untuk waktu yang sangat lama.

Istirahat yang menyenangkan, dan meskipun sedikit tentang tantangan apa yang perlu dilakukan untuk "menyelamatkan" MSBuild. Saya tidak percaya kita dapat atau harus mengubah MSBuild menjadi sistem build yang sangat berbeda. Ini adalah sistem build yang ditentukan XML berbasis inferensi, dan itu berfungsi untuk itu, dan cukup banyak skenario orang, terutama beberapa skenario yang lebih kompleks.

Tetapi tidak semua dari kita memiliki Build Masters yang berdedikasi yang dapat berdebat dengan MSBuild. Tidak semua dari kita membutuhkan kekuatan yang dibawa oleh kompleksitas MSBuild. Beberapa dari mereka yang melakukan kebutuhan yang kompleks tidak ingin menggunakan MSBuild. Di salah satu tim saya misalnya, semua logika build kustom dilakukan dalam langkah-langkah sebelum dan sesudah build, Exec pada dasarnya melakukan shelling ke Powershell. Bukan karena itu tidak bisa dilakukan di MSBuild, itu bisa, dan dalam hal ini mungkin _harus_. Tetapi karena mereka tidak ingin melakukannya di MSBuild.

Langkah pertama jelas bahwa kita perlu memisahkan definisi proyek dari sistem build. Bagi saya itu sangat masuk akal. Kita dapat mendiskusikan pemisahan dependensi dari definisi proyek, tetapi saya tidak yakin itu diperlukan.

Langkah kedua adalah kita memang membutuhkan sistem build. Kita perlu menangani kasus penggunaan yang sangat sederhana, serta yang sangat rumit. Tetapi tidak ada aturan yang mengatakan bahwa satu sistem build harus menangani _both_. Menurut saya, yang paling masuk akal adalah memiliki sistem build yang sederhana dan ringan yang pada dasarnya hanya membangun definisi proyek. Itu restore , build , test , dan pack .

Saya pikir kita juga harus mencari cara agar dapat bekerja _tanpa_ definisi proyek sama sekali, menggunakan struktur direktori sebagai definisi. Jelas situasi seperti itu berarti akan menggunakan kerangka kerja default dan dependensi default. Mungkin mungkin, mungkin tidak. Tetapi kita dapat melihat setiap elemen dalam definisi dan bertanya "dapatkah kita menyimpulkan default cerdas untuk ini"?

Tapi sementara itu mungkin cukup untuk 80% kasus penggunaan, itu tidak cukup untuk 20% lainnya. Mereka membutuhkan sesuatu yang lebih. (peringatan: pendapat tentang rasio kasus penggunaan dapat bervariasi).

Langkah ketiga adalah kami mengizinkan bentuk ekstensibilitas yang sangat sederhana ke sistem build itu. Tapi kita berbicara sangat sederhana. Pada dasarnya, ia dapat menjalankan build dasarnya, atau dapat menjalankan sistem build eksternal. Sistem build eksternal tersebut dapat berupa MSBuild, atau skrip, atau sistem build lainnya.

Saya senang bahwa proses pembangunan baru harus dapat keluar ke MSBuild, tetapi saya tidak percaya bahwa sesuatu seperti (IMO) lama, keras kepala, dan membengkak seperti MSBuild harus menjadi dasar untuk semua pembangunan di masa depan.

Dengan hal-hal seperti kerangka kerja Web, kami melihat tim MS melakukan iterasi dengan panik. Karena mereka punya persaingan. Mereka harus khawatir tentang Nancy yang bernapas di leher mereka misalnya. Ini _mudah_ untuk beralih ke sesuatu yang lain. Dan itu membuat MVC/WebAPI lebih baik untuk itu.

Dengan MSBuild dimasukkan ke dalam seluruh perkakas .NET, menjadi sulit untuk menggunakan yang lain. Dimana kompetisinya? Dan Anda dapat melihat efeknya di papan MSBuild Github. Cukup tinjau semua proposal Tertutup. Satu- satunya alasan mengapa mereka berbicara tentang membuat perubahan "pelangsingan" ini sekarang adalah karena mereka ingin orang-orang berpindah dari project.json ke MSBuild.

Jika MSBuild telah dimasukkan ke dalam .NET Core sejak awal, saya yakin kita akan melihat _tidak ada_ gerakan yang kita lihat sekarang dari tim MSBuild. Tapi apa yang terjadi setelah kita terkunci kembali? Setelah kompetisi pada dasarnya dikecualikan? Apa yang akan terjadi? Apa yang selalu terjadi dalam skenario tanpa persaingan, dan apa yang telah terjadi selama bertahun-tahun hingga sekarang: peningkatan yang cukup untuk menghentikan pembelotan massal, tetapi tidak ada yang menarik.

Orang-orang bertanya kepada saya bagaimana menurut saya kita dapat "menyelamatkan" MSBuild. Saya percaya membukanya untuk kompetisi nyata dan pilihan adalah satu -

Itu bukan resep untuk kesuksesan kerangka kerja apa pun.

Harap semua, perlu diingat, kita semua ingin .NET berhasil. Saya _love_ .NET, menurut saya C# adalah salah satu bahasa pemrograman terbaik di luar sana, dan telah menikmati transisinya yang lambat ke Scala - The Good Parts™ .
Saya tidak percaya kita memulai dari awal dengan .NET Core, dan melakukannya dengan membelenggu diri kita sendiri ke salah satu (IMO) bagian terburuk dari .NET gaya lama. Ya, MSBuild, tapi tidak, tidak dibelenggu.

Dengan segala cara, pertahankan, tetapi jangan di bagian depan dan tengah yang dibangun ke dalam inti sistem.

Sistem build impian saya (untuk menggantikan MSBuild seluruhnya) akan menggunakan Roslyn untuk mengetahui tugas dan target, memungkinkan Anda menggunakan F# untuk menentukan proses build Anda (atau C#, atau VB.NET, apa pun yang didukung Roslyn).

YAAAAAAAAAA!!! Omong-omong... apakah ini tempat yang tepat untuk melakukan percakapan ini? Kami juga memiliki repo Roslyn dan MSBuild dan sepertinya mereka juga harus dilibatkan. Saya kira kami mencoba repo MSBuild, tetapi mereka (seperti yang Anda sebutkan) sangat kaku dan tidak fleksibel. Saya pikir memiliki lebih banyak orang di sini seperti minat yang dihasilkan oleh utas ini mungkin akan sangat membantu reformasi.

Langkah ketiga adalah kami mengizinkan bentuk ekstensibilitas yang sangat sederhana ke sistem build itu.

Sistem/model build berbasis penyedia?! GENIUS! Saya menyetujui pesan ini.

Btw, jika Anda mendapatkan keinginan Anda dan memiliki akses ke sistem build Anda sendiri, saya sarankan kita menyebutnya ... BERSERKER BUILD! Dinamakan setelah "Berzerker @shederman"... nama panggilan baruku untukmu. :senyum:

@Mike-EEE Jangan terlalu bersemangat. Tidak berarti saya mengusulkan sesuatu yang sedrastis semua _yet_ itu.

Untuk saat ini saya pikir itu hanya Langkah satu dan dua, dengan dukungan MSBuild untuk Langkah tiga.

Tapi kemungkinan semacam ini adalah apa yang saya pikir sedang kami tuju ketika kami mendapatkan project.json, memisahkan proyek dari build sehingga akan lebih mudah untuk menukar penyedia build. Menurut saya, membawa MSBuild kembali ke root menutup kemungkinan ini. Atau setidaknya membuat mereka jauh lebih kecil kemungkinannya untuk mendapatkan daya tarik.

Saat ini custom build tidak mendapatkan adopsi karena sistem root _is_ sangat kuat. Ini adalah percakapan yang sulit untuk meyakinkan orang bahwa Anda ingin menggunakan sistem build non-MS ketika sistem build MS benar-benar dapat melakukan semua yang diperlukan (mengabaikan rasa sakit).

apakah ini tempat yang tepat untuk melakukan percakapan ini?

Saya tidak berpikir begitu, tidak. Juga, tidak berpikir tahu bahwa ini adalah waktu yang tepat. Kita perlu menutup masalah ini sebelum melihat arah mana yang mungkin.

MEMBANGUN BERSERKER! Dinamakan setelah "Berzerker @shederman"... nama panggilan baruku untukmu. :senyum:

Tidak yakin bagaimana perasaan tentang itu

Tidak berusaha menjadi seorang yang mengamuk. Saya hanya tidak ingin mundur ketika kita _bergerak_ maju.

Hai teman-teman, mungkin daripada menemukan kembali roda ( nuget.json atau apa pun namanya) mari kita gunakan solusi berbasis komunitas yang ada yang memecahkan sebagian besar masalah manajemen ketergantungan - Paket .

1. Ini memiliki konsep dependensi transitif
2. Ini terintegrasi dengan baik dengan MsBuild
3. Ini memiliki format file yang dapat dibaca manusia untuk mendefinisikan dependensi
4. Ini memiliki jalur migrasi yang sangat baik dari packages.config
5. Dan banyak fitur lainnya (tetapi tampaknya 4 itu adalah hal terpenting bagi semua orang, jadi saya tidak akan menyebutkan hal-hal seperti dependensi Git atau strategi resolusi paket yang lebih baik)

@Krzysztof-Cieslak ingat bahwa alasan terbesar Microsoft mendorong definisi proyek MSbuild adalah untuk membantu memudahkan migrasi mereka yang telah banyak berinvestasi ke MSBuild. Dalam hal ini, Paket tidak lebih baik dari project.json (atau project.yaml atau project.cs atau apa pun).

Karena itu, saya masih tidak melihat alasan mengapa Anda tidak dapat menggunakan sistem build apa pun yang Anda inginkan. Pada akhirnya, "dotnet build" tidak akan berubah, terlepas dari format apa definisi proyek Anda akhirnya, dotnet build akan tetap menghasilkan output Anda.

@neoKushan Ya, tetapi apakah "dotnet build" memerlukan file MSBuild meskipun kita tidak menggunakan MSBuild? Apakah akan dibangun jika tidak ada file MSBuild sama sekali? Atau akan keluar ke MSBuild yang kemudian akan keluar ke sistem build lain apa pun yang digunakan?

@shederman Tidak diragukan lagi "dotnet build" akan menggunakan MSBuild di latar belakang untuk benar-benar membangun proyek, tetapi apakah kita benar-benar melihat semua itu masih belum jelas. Saat ini, hari ini, Anda memerlukan project.json untuk membangun proyek Anda dengan benar, jika bukan untuk referensi maka untuk data penting lainnya (seperti kerangka kerja target). Akhirnya beberapa (atau bahkan semua) dari itu akan bermigrasi ke file csproj sehingga orang menganggap bahwa Anda memerlukan .csproj agar dotnet build berfungsi, tidak peduli apa yang akhirnya digunakan di latar belakang. Namun, seberapa besar dampak ini bagi Anda masih harus dilihat.

Seperti yang saya katakan, seperti selama aku diizinkan untuk melakukan pekerjaan tetap membangun ringan di tempat, yang tidak memerlukan MSBuild sama sekali, saya senang. Kalian dapat membangun pipa "MSBuild di mana-mana" referensial Anda sendiri di jalan buntu apa pun yang Anda inginkan.

Tetapi jika itu akan berhasil, maka csproj perlu menyertakan project.json seperti yang disarankan RichiCoder .

Dengan begitu "core build" dan "MSBuild" dapat bekerja berdampingan, atau core build dapat bekerja tanpa MSBuild. Dan, tentu saja, jika Anda tidak mengimpor project.json, Anda juga dapat menentukan properti proyek Anda di csproj.

Perubahan yang cukup mudah sebenarnya. Dari atas kepala saya, kita perlu:

• Simpan kode dotnet-build yang ada dan jalankan dalam keadaan tertentu (akan ditentukan).
• Di tempat lain, jalankan MSBuild, sesuai rencana tim inti DotNet
• Apakah VS dapat membaca project.json atau MSBuild untuk properti proyek
• Tambahkan kemampuan untuk Mengimpor project.json ke MSBuild

Cukup sedikit pekerjaan, dan memungkinkan Microsoft untuk melanjutkan jalur "MSBuild selamanya", dan itu menepati janji yang dibuat untuk komunitas .NET Core, dan memungkinkan kita yang ingin memilih keluar dari MSBuild untuk melakukannya.

Perlu dicatat bahwa tidak ada seorang pun dari keanggotaan asp.net yang mengatakan apa pun di sini.

Sementara itu, saya membaca kembali beberapa Catatan dari Standup Komunitas ASP.NET – 10 Mei 2016 , dan mereka berbicara tentang sistem MSBuild "baru", tetapi tidak mengatakan apa itu, kecuali bahwa itu tidak memerlukan Visual Studio untuk diedit. Menyebalkan bahwa itu tidak dirancang ke asp.net dan harus ditambahkan (sekarang) begitu terlambat dalam permainan ... ketika desain tidak memasukkan itu untuk memulai. Sungguh, project.json seharusnya hanya menyertakan item { "BuildSystem" : "MSBuild" } jika Anda ingin/harus menempuh rute itu. Saya juga bertanya-tanya mengapa MS tidak dapat (kata-kata terakhir yang terkenal) "hanya" mengizinkan komentar dalam file json melalui perkakas.

@rhires Dari pemahaman saya, sistem MSBuild "baru" adalah beberapa penyesuaian untuk membuat XML sedikit lebih ringan, seperti memasukkan semua file cs ke dalam build, dan membongkar dependensi ke file nuget.json. Tidak ada perubahan signifikan dalam desain, arsitektur, atau penggunaan MSBuild.

Saya suka ide project.json Anda. Baru saja melalui perubahan RC2, dan mereka memasukkan "testrunner", jadi tidak ada alasan yang tidak bisa dilakukan. _BUT_, tampaknya hati mereka benar-benar ingin menghapus project.json sepenuhnya, dan kembali ke dunia pertama MSBuild.

mengapa MS tidak bisa (kata-kata terakhir yang terkenal) "hanya" mengizinkan komentar dalam file json melalui perkakas

Tidak ada alasan mengapa mereka tidak bisa. JSON.Net, perpustakaan yang mereka gunakan, mendukung komentar.

Sungguh, project.json seharusnya hanya menyertakan item { "BuildSystem" : "MSBuild" } jika Anda ingin/harus menempuh rute itu.

Mengapa saya ingin proyek saya mendikte sistem build-nya sendiri? Tentunya sistem build membangun proyek dan bukan sebaliknya?

@neoKushan :

ingat bahwa alasan terbesar Microsoft mendorong definisi proyek MSbuild adalah untuk membantu memudahkan migrasi mereka yang telah banyak berinvestasi ke MSBuild. Dalam hal ini, Paket tidak lebih baik dari project.json (atau project.yaml atau project.cs atau apa pun).

Paket bukanlah sistem build baru, ini adalah dependency manager yang 100% kompatibel dengan MsBuild. Itu hanya memecahkan masalah packages.config .

@Krzysztof-Cieslak Saya tidak pernah mengklaim itu adalah sistem build dan manajemen ketergantungan sebenarnya bukan masalah besar dengan .net core (Setidaknya sejauh yang saya ketahui). .net core tidak menggunakan packages.config ia menggunakan project.json .

Jika .Net Core masih direncanakan untuk menggunakan project.json kami tidak akan melakukan diskusi 100 posting ini. ;) Yang saya katakan adalah bahwa solusi yang disarankan di banyak tempat menggunakan "nuget.json" untuk menangani dependensi adalah menemukan kembali roda karena kami memiliki produk yang melakukan hal yang persis sama.

@shederman

"Hasil survei akhir: 100 tanggapan, untuk 9 juta populasi pengembang .NET yang ±10% dengan kepercayaan 95%."

Ya dan bertanya di konferensi tentang mainan kucing yang merupakan hewan peliharaan yang disukai anjing atau kucing mungkin memberi Anda hasil yang serupa.

@darrelmiller

"Saya pikir penting untuk membuat perbedaan antara MSBuild dan cara Visual Studio saat ini menggunakan MSBuild. Saya telah mengedit file MSBuild secara manual selama bertahun-tahun dan menggunakannya untuk semua proyek saya. Misalnya https://github.com/tavis- software/Tavis.home/blob/master/build/Build.proj "

Haruskah kita membahas file build khusus VS di atas file proyek di mana msbuild tidak berfungsi dari baris perintah?

@gregoryyoung Kita harus. Saya telah melakukan pembuatan file yang bergantung pada devenv sebelumnya, tetapi belum melihat file yang tidak dapat dijalankan dari baris perintah. Ada contoh?

@gregoryyoung

Ya dan bertanya di konferensi tentang mainan kucing yang merupakan hewan peliharaan yang disukai anjing atau kucing mungkin memberi Anda hasil yang serupa.

Itu analogi yang menarik. Kecuali...

Saya memposting tautan di umpan Twitter dari orang-orang yang _mendukung_ perpindahan ke MSBuild. Jadi, sebenarnya sama sekali tidak seperti analogi Anda.

Dan saya suka cercaan lanjutan bahwa survei itu bias, di forum yang salah, atau tidak ilmiah. Tapi, pertanyaannya tidak mengarah, jawabannya memiliki rentang tanggapan yang luas, dan survei, ya adalah audiens yang dipilih sendiri, tetapi audiens yang luas, setidaknya secara teori, harus membiaskan _menjauh_ dari sudut pandang saya.

Saya juga mendapat kesan, dan dalam beberapa kasus konfirmasi, bahwa orang-orang yang membuat tuduhan ini baru saja mencari di Google sedikit tentang survei. Saya pribadi telah merancang protokol penelitian tingkat master untuk studi kesehatan, dan sementara saya tidak akan mengklaim survei itu sempurna, tentu saja tidak cacat seperti yang dibuat oleh karyawan Microsoft.

Ini pasti _is_ signifikan secara statistik, dan memberi Anda indikasi yang baik tentang di mana letak opini. GitHub, dan gitter, dan Twitter, dan blog semuanya mendukungnya hingga tingkat tertentu.

Berbagai sumber bukti mengatakan hal yang sama. Jika Anda ingin mengabaikan pendapat signifikan dari pengguna Anda, katakan saja. Berhentilah mencoba untuk mengabaikan oposisi mereka seolah-olah Anda kehilangan hak untuk menyuarakan pendapat Anda jika Anda memegang pendapat yang "salah".

Atau lebih baik lagi, seperti yang telah saya katakan berkali-kali, buat survei Anda sendiri yang memperbaiki hal-hal yang menurut Anda salah dengan survei saya.

Alasan saya melakukan survei adalah karena sangat jelas bahwa Microsoft tidak tahu apa yang dipikirkan orang. Apa yang menjadi sangat jelas sekarang adalah bahwa mereka tidak memiliki _ketertarikan_ pada apa yang dipikirkan orang.

Berhentilah bersikap tidak jujur ​​dengan diri Anda sendiri dan dengan komunitas Anda dan terlibatlah dengan oposisi alih-alih mengabaikannya.

Berhentilah mencoba mengubah fakta, dan mulailah mengubah pikiran Anda berdasarkan fakta.

@shederman Saya tidak memiliki kesan bahwa tim Microsoft benar-benar menjawab utas ini (termasuk survei Anda). Ya, salah satu anggota tim mengatakan bahwa dia tidak menganggapnya dapat dipercaya seperti Anda, tetapi hanya itu. Saya pikir masih ada harapan mereka saat ini berbicara tentang oposisi besar-besaran terhadap jalan yang mereka ambil dan mereka mendiskusikan tentang jalan yang benar untuk diambil dan akan menanggapi kami ketika mereka tahu lebih banyak.

Saya pikir kami dapat memberikan penghargaan kepada tim ini ;).

@gregoryyoung Maaf, dari analogi yang Anda berikan, saya berasumsi Anda adalah karyawan MS, karena mereka telah menelusuri garis perkiraan yang sama selama 2 hari sekarang.

@sandorfr

Saya pikir kami dapat memberikan penghargaan kepada tim ini

Saya pikir kami bisa, tetapi pengalaman saya dalam beberapa hari terakhir tidak memperkuat harapan itu.

Saya harus berpikir itu bukan kesalahan "tim", tetapi seseorang yang lebih tinggi dalam organisasi yang membuat keputusan ini dan menjatuhkannya ... dan kemudian "tim" harus menyedotnya dan membuatnya terlihat cantik. BTDT. Tidak menyenangkan.

Anda semua menyadari bahwa project.json telah mengalami perubahan besar baru-baru ini untuk membuatnya sedikit lebih kompatibel dengan aplikasi non ASP.NET Core? Jika Anda hanya melihat contoh di posting pengumuman itu, itu sudah menjadi sangat membengkak dengan semua konfigurasi build itu.

Beralih dari itu ke file csproj "klasik" sebenarnya tampaknya tidak terlalu jauh bagi saya. Dan jika csproj itu sendiri juga berkembang sedikit ke arah yang lebih fleksibel yang telah kita pelajari dari project.json, saya sebenarnya dapat melihat csproj "baru dan lebih baik" bekerja dengan sangat baik. Dan saya pikir kita dapat dengan aman berasumsi bahwa perubahan terbaru pada project.json tidak akan menjadi yang terakhir dalam kursus untuk membuatnya dapat digunakan untuk _all_ jenis proyek .NET—Saya pikir penting bahwa kita tidak lupa bahwa ada banyak target lain selain ASP.NET (Core).

Dan sebenarnya tidak terlalu menjadi masalah apakah format file JSON, XML, atau apa pun. Ya, satu mungkin lebih baik daripada yang lain karena berbagai alasan yang valid, tetapi pada akhirnya Anda harus memikirkan berapa banyak waktu yang sebenarnya ingin Anda habiskan dalam file proyek . Ya, dengan masalah yang kami alami dengan format saat ini, kami menghabiskan lebih banyak waktu daripada yang kami inginkan, tetapi idealnya, dengan asumsi kami memperbaiki penyebabnya, kami harus menghabiskan sebagian kecil waktu kami di file tersebut. Dan pada saat itu, Anda tidak perlu terlalu peduli dengan formatnya. Terutama jika pada akhirnya semua bantuan alat (termasuk penyelesaian penuh di editor).

Saya merasa bahwa ketika orang berpikir tentang project.json, mereka kebanyakan berpikir tentang tahap awal yang banyak tentang konvensi daripada konfigurasi. Ya, itu sangat bagus, tetapi juga sangat spesifik untuk ASP.NET Core dan karena itu sangat terbatas. Ini tidak akan benar-benar berfungsi dengan baik untuk target lain, jadi masuk akal untuk menggunakan sesuatu yang telah bekerja dengan baik selama bertahun-tahun dan mengembangkannya serta meningkatkannya dengan segala cara yang mungkin sambil mempertahankan kompatibilitas.

Jadi, tl;dr: Ya, saya sangat suka project.json dan berharap ada cara untuk menyimpannya untuk ASP.NET Core (misalnya menggunakan tugas MSBuild khusus). Tetapi pada saat yang sama, saya benar-benar mengerti mengapa ini terjadi sekarang, dan saya pikir itu sebenarnya bukan hal buruk yang mereka lakukan. Tentu saja waktunya agak aneh, tetapi mengingat bahwa perubahan tidak akan terjadi paralel dengan rilis ASP.NET Core dan .NET Core, saya tidak berpikir waktunya adalah masalah aktual (dengan asumsi bahwa transisi nanti akan lancar ).

harus dapat berbagi file sumber di seluruh proyek

@darrelmiller Ini terdengar menakutkan bagi saya, karena itu sepertinya menyiratkan bahwa daftar file di .csproj akan kembali.

@lokitoth Dengan asumsi csproj akan bekerja sama untuk referensi file sebagai project.json yang lebih baru, tidak ada yang mencegah Anda menggunakan gumpalan secara umum dan memiliki referensi file individual bersama mereka.

@shederman Saya bukan karyawan MS hanya orang yang rasional. Jika Anda google saya, saya yakin Anda dapat menemukan bahwa saya memiliki minat jangka panjang pada platform.

Ada banyak pro/kontra terkait dengan perubahan tersebut, tetapi apa yang Anda berikan tidak berguna untuk diskusi yang waras.

Ini adalah perubahan yang mengecewakan untuk didengar. project.json, inklusi/globbing file otomatis, dan pemulihan transitif adalah hal pertama tentang ASP.NET Core yang membuat saya menjadi "oh, bagus!" pada awalnya.

Saya menyadari tidak semua itu akan hilang (saya harap?). Tetapi kembali ke file proyek XML terasa buruk, karena secara historis itu berarti sakit kepala bagi manusia. Saya benci membuka file csproj untuk memperbaiki masalah karena ini adalah dinding teks yang sulit diurai.

Hanya dua sen saya.

Melihat perubahan dalam posting @poke , sepertinya mereka pada dasarnya menerjemahkan csproj ke json, yang sejujurnya juga cukup menjijikkan.

Berdasarkan fakta bahwa mereka ingin mendukung opsi Compile, Embed, CopyToOutput, Exclude, Shared Files dll, maka format json sebenarnya tidak akan berfungsi lebih baik daripada XML. Saya juga menduga bahwa json tidak akan berfungsi dengan baik untuk penyesuaian skrip build yang berat.

Saya hanya berharap bahwa ini adalah tim yang mencoba untuk tidak menambahkan solusi setengah matang lagi ke dalam produksi sampai mereka dapat memiliki waktu untuk mencari cara untuk melakukannya dengan baik.

@gregoryyoung apa yang Anda berikan tidak berguna untuk diskusi yang waras

Besar. Oke langsung saja kita lihat apa saja yang sudah saya sediakan :

• Saya telah mengeluh tentang perpindahan ke XML, seperti halnya sejumlah besar lainnya
• Saya telah mengeluh tentang perpindahan ke MSBuild, seperti halnya sejumlah besar lainnya
• Saya telah mencoba untuk mendapatkan pemahaman tentang alasan dan bukti di balik keputusan tersebut, yang belum benar-benar diberikan selain beberapa hal yang sangat bergelombang.
• Saya telah mencoba untuk mendapatkan _pemikiran_ yang mendasari di balik keputusan tersebut, yang _juga_ belum benar-benar diberikan
• Saya telah meminta pendapat komunitas, yang tidak mau dilakukan MS sama sekali
• Saya telah mencoba menemukan alternatif yang memungkinkan hasil yang dinyatakan oleh orang-orang yang memberikan alasannya, tetapi juga memungkinkan komunitas untuk mempertahankan proses pembangunan sederhana yang mereka nikmati
• Saya telah menawarkan untuk melakukan pekerjaan yang diperlukan untuk mendukung alternatif tersebut

Bisakah saya bertanya, karena tertarik, apa bagian gilanya? Menginterogasi pemikiran seseorang tidak rasional akhir-akhir ini? Atau apakah saya meninggalkan sesuatu di luar sana?

Maksudku, aku marah , jangan salah paham. Saya telah menyia-nyiakan banyak pekerjaan, waktu, dan uang untuk membangun janji inti dari kerangka kerja yang telah ditarik pada menit terakhir dalam apa yang tampaknya merupakan langkah yang terburu-buru dan dipikirkan dengan buruk. Apakah saya tidak punya _hak_ untuk marah?

PS. Ah, Anda _that_ Greg Young. Menghormati. Cintai pekerjaanmu. Saya benar-benar.

@bzbetty Saya setuju dengan Anda sepenuhnya. Hal terakhir yang ingin saya lihat adalah konsep ulang MSBuild menjadi project.json. Salah satu masalah terbesar dengan MSBuild dalam bentuknya saat ini adalah ia menggabungkan _project definition_ dengan _build process_.

Jadi pergi dan menambahkan proses build ke project.json akan membuat kesalahan yang sama persis yang dibuat MSBuild/VS.

Definisi proyek harus berdiri secara terpisah dari proses pembangunan dan dimasukkan ke dalam proses pembangunan.

Dan kemudian kita harus bertanya: jika proyek Anda sederhana dan hanya perlu membangun langsung definisi proyek, apakah Anda benar-benar membutuhkan sistem pembangunan kelas berat, dapat diperluas, dapat disesuaikan, fleksibel, dan kontra intuitif hanya untuk melakukan pembangunan sederhana?

Dengan cara lain. Jika Anda _memiliki_ definisi proyek yang begitu sederhana, dan alat pembuatan yang sangat sederhana yang tidak dapat melakukan apa pun selain membangun definisi proyek, apakah Anda akan memilih untuk menginstal dan menggunakan MSBuild atau NAnt atau sejenisnya?

Tidak, mungkin tidak, kan? Maksud saya mengapa menambahkan kompleksitas yang tidak perlu. Bagian inti dari praktik rekayasa perangkat lunak yang efektif adalah menjaga semuanya tetap sederhana.

Tetapi, begitu Anda menemukan skenario yang tidak dapat ditangani oleh alat "build the definition" sederhana? Tentu, _kemudian_ Anda akan melakukannya.

Saya katakan, instal kedua alat secara berdampingan, sehingga kita dapat memilih mana yang terbaik untuk kebutuhan kita. MS mengatakan: tidak, Anda hanya membutuhkan alat yang kompleks dan kontra-intuitif, tetapi kami akan menghapus fitur yang paling buruk.

kotak sabun

Saya hanya ingin berbagi sedikit riset yang telah saya lakukan. Saya telah melihat Twitter, Slack, Github, Gitter, dan Jabbr.

Saya telah melihat sangat sedikit dukungan untuk pergerakan di luar tim inti. Maksudku, ada beberapa, tapi tidak banyak. Kebanyakan orang cukup kecewa dengan langkah tersebut.

Saya juga sangat kecewa dengan kecenderungan banyak orang di kubu pro-MSBuild untuk menyimpulkan bahwa lawan mereka salah informasi, atau, lebih umum, tidak memenuhi syarat. Ini telah dicocokkan dengan kecenderungan di kubu pro-project.json untuk menyimpulkan motif yang buruk (termasuk saya sendiri, mea culpa).

Saya ingin bertanya sebagai berikut:

• Orang-orang yang berasumsi bahwa orang-orang yang memiliki pendapat berbeda dari mereka sendiri memegangnya untuk alasan yang baik. Mereka tidak tertipu, tidak kompeten, terlibat, atau gila
• Orang untuk menyerang argumen dan bukti dan bukan orang
• Bukti apa pun yang diberikan tidak boleh diabaikan begitu saja tanpa alasan yang kuat

Argumen untuk
Alasan utama yang saya lihat untuk pindah ke MSBuild adalah:

• Dukungan perkakas - Untuk memungkinkan bolak-balik antara alat yang berbeda, misalnya VS, VSCode, Xamarin, dll.
• Investasi yang ada - Klien besar memiliki bangunan yang sudah ada yang tidak dapat dibuang
• "Memori otot" - Orang terbiasa dengan MSBuild

Argumen menentang

• Investasi yang ada - investasi yang dilakukan di .NET Core tooling: post RC. RC _should_ berarti tidak ada perubahan besar yang melanggar
• CSProj/MSBuild buruk - pengalaman negatif masa lalu dalam berurusan dengan csproj dan MSBuild
• Mundur - Pindah ke project.json dipindahkan ke cara kerja baru, sebagian untuk menarik generasi pengembang baru. Ini sedang dibatalkan

Pendapat
Saya telah membayar langganan SurveyMonkey penuh sehingga saya dapat mengakses hasil lengkap (bukan seratus pertama). Ini 321 tanggapan, yang biasanya diterjemahkan menjadi ± 5,5% margin kesalahan, kepercayaan 95% untuk 9 juta penduduk.

Argumen umum yang saya dengar terhadap survei ini adalah:

• Pertanyaan/jawabannya bias: Saya tidak percaya itu, dan bahkan jika ya, itu tidak banyak. Ada berbagai jawaban yang luas.
• Survei telah diposting ke audiens yang bias: Twitter? Untuk pengikut dari berbagai garis waktu anggota tim. Tidak yakin bagaimana itu adalah audiens yang bias.
• Tidak relevan secara ilmiah: Oke, buat saya yang ini. Saya tidak melakukan protokol penelitian lengkap, sehingga tidak lulus peer review. Apakah itu tingkat kepastian yang diperlukan untuk mengukur dukungan untuk sebuah proposal?

Di sini mereka:

Seruan saya kepada siapa pun yang menyukai kerangka kerja .NET adalah untuk tidak meremehkan tingkat kecemasan tentang perubahan ini, dan untuk menerima umpan balik dan terlibat dengan komunitas tentang hal itu atas dasar bahwa kekhawatiran mereka valid, dan berasal dari pengalaman yang terinformasi. .

Dan jika keputusannya akan terus berlanjut, serangkaian alasan dan bukti yang lebih baik harus diberikan daripada sejauh ini.

Man @shederman mengingatkan saya pada saya (dan banyak lainnya) ketika Silverlight memakannya , kecuali x10 dan lebih fokus/berpengalaman. Mungkin itu sebabnya saya mendukungnya :100:%! ha ha.

Salah satu masalah terbesar dengan MSBuild dalam bentuknya saat ini adalah ia menggabungkan definisi proyek dengan proses pembangunan.

Jadi pergi dan menambahkan proses build ke project.json akan membuat kesalahan yang sama persis yang dibuat MSBuild/VS.

Definisi proyek harus berdiri secara terpisah dari proses pembangunan dan dimasukkan ke dalam proses pembangunan.

:+1: :+1: :+1: ... Cara yang bagus untuk membingkai masalah!!! Anda tahu, saya sudah lama memikirkan hal ini, sehingga ini tidak pernah benar-benar terpikir oleh saya. Tetapi Anda (sekali lagi) 100% tepat sasaran.

Saya benci membuka file csproj untuk memperbaiki masalah karena ini adalah dinding teks yang sulit diurai.

Ini perlu dibingkai di suatu tempat, @nbarbettini! Sempurna menangkap sentimen saya juga.

Dan sebenarnya tidak terlalu menjadi masalah apakah format file JSON, XML, atau apa pun.

Ya, saya benci mencoba mengingatkan orang tentang ini, tetapi tampaknya beberapa pengembang terjebak pada gagasan tentang format, dan itu menyesatkan. Paradigma proyek "JSON" sebenarnya bukan "hal JSON" tetapi menggunakan JSON sebagai pilihan serialisasi untuk menggambarkan "model"-nya. Fakta bahwa JSON singkat dan kurang cerewet daripada XML membuatnya lebih menarik (bagi sebagian besar).

Sejalan dengan itu, MSBuild tidak di-root dalam XML, tetapi cara desainnya adalah dengan "model" yang dijelaskan dalam format ini. Saya katakan "model" karena kedua sistem ini menderita cacat desain (apa yang saya anggap a) menempatkan model dokumen di depan model/API aktual yang pada akhirnya dideserialisasi ke dalam memori. Itu berarti harus mengelola lebih banyak artefak dan konsep daripada yang benar-benar diperlukan, dan pada akhirnya memperumit sistem. Hardcoding untuk hanya menerima format tertentu (XML atau JSON) hanya memperburuknya, dan sekali lagi kita harus mencari cara untuk mengurangi kendala ini.

Bagaimanapun, PSA Minggu pagi yang lumpuh untuk semua orang. :stuck_out_tongue:

Saya tidak bisa melihat ini diposting di mana pun di utas ini, jadi begini... https://youtu.be/N9MteJH-HsQ. Mudah-mudahan ini menjelaskan sedikit lebih banyak tentang mengapa perubahan itu dilakukan.

@shederman

"Bolehkah aku bertanya, karena penasaran, apa bagian gilanya? Menginterogasi pemikiran seseorang tidak rasional akhir-akhir ini? Atau apakah aku meninggalkan sesuatu di luar sana?"

Saya mengacu pada hasil survei dan mencoba memperkirakan populasi pengembang umum. Seperti yang saya sebutkan itu kira-kira setara dengan menjalankan jajak pendapat yang lebih baik anjing vs kucing di konvensi mainan kucing dan dengan asumsi itu berlaku untuk keseluruhan populasi, ada bias sampel yang besar dan jelas.

GitHub di ponsel saya tidak mengizinkan saya memberi +1 @gregoryyoung , tapi +1.

Tim telah menjelaskan bahwa bagian dari alasan perubahan adalah akuisisi Xamarin, yang merupakan masalah besar. Potensi untuk berbagi perpustakaan antara proyek .NET, ASP.NET dan Xamarin mobile/x-plat sangat besar, dan jika itu berarti mengorbankan format file proyek/build, itu adalah perdagangan IMHO yang berharga.

Saya akan menunggu dan melihat seperti apa perkakas dan pengaturan file akhir sebelum saya membentuk pendapat akhir.

@gregoryyoung Saya mengacu pada hasil survei dan mencoba memperkirakan populasi pengembang umum...ada bias sampel yang besar dan jelas.

Bias sampel yang mana? Yang diposkan terutama di umpan Twitter dari orang-orang yang _menyukai_ perubahan? Yang di saluran slack yang digunakan tim pengembang?

Bias sampel utama yang saya lihat adalah bahwa responden mungkin terlibat, terinformasi, dan bersemangat. Tentu, itu mungkin bukan sampel yang representatif, tetapi saya berpendapat bahwa ini adalah sampel yang penting. Dan bahkan dengan bias sampel, apakah itu berarti bahwa hasilnya harus dibuang? Bahwa sudut pandang responden tidak penting?

322 pengembang .NET profesional telah menyatakan pendapatnya. Apakah Anda akan mengabaikan masukan mereka sepenuhnya karena Anda yakin (tanpa bukti untuk mendukung Anda) bahwa itu tidak representatif?

Rupanya, posting blog akan datang minggu depan, kita akan memiliki hal-hal yang lebih spesifik untuk didiskusikan.

Astaga, orang-orang perlu menenangkan diri :)

Saya setuju perubahan ini tampak besar tetapi saya pikir itu akan mempengaruhi orang jauh lebih sedikit daripada yang terlihat. Ingat bahwa ketika tim berbicara tentang "perkakas" itu juga termasuk cli. Konversi apa pun yang perlu terjadi juga akan dilakukan oleh cli, "perkakas" untuk menambahkan referensi, yang menurut saya bahkan lebih baik daripada mengetikkannya ke json atau xml, akan ada di cli. Globbing sudah didukung di msbuild. Msbuild jelas akan dimasukkan dalam don't sdk sehingga tidak akan ada instalasi tambahan, cerita proyek baru juga akan sama, perintah dotnet hanya akan melakukan hal-hal lain di bawah tenda. (Saya bukan seorang microsoftie, tetapi ini tampaknya sangat mungkin)

Tim ini tidak bodoh, mereka tidak membuat perubahan ini dengan mudah. Mereka _memiliki_ alasan, terutama kompatibilitas dan koherensi dengan platform lainnya di seluruh bahasa, referensi asli dan jenis proyek, granularitas paket nuget, dan sebagainya. Ini baru seminggu dan mereka mengatakan akan merinci perubahan dan alasan mereka segera.

Saya berharap orang-orang setidaknya akan menunggu untuk itu dan apa rencana mereka yang sebenarnya sebelum mengutuk langkah itu sepenuhnya.

Dan ya, saya telah men-debug file csproj/tfproj dan berjuang melawan aturan bersyarat untuk penyertaan file dan semua itu. Heck, saya bahkan menulis tugas pembuatan kustom. Tetapi pada akhirnya, jauh lebih mudah untuk mengabstraksi sistem yang kompleks dengan perkakas sederhana (termasuk cli), daripada membuat sistem project.json yang relatif sederhana mendukung semua skenario kompleks yang perlu didukungnya.

Dengan kata lain, kesederhanaan yang disukai orang-orang di project.json sudah hilang, dibutuhkan untuk mendukung realitas kompleks lingkungan dotnet umum dengan semua jenis atau proyek dan skenario. Seandainya mereka menerapkan semua itu ke project.json, pada dasarnya Anda akan memiliki msbuild lagi. Saya lebih suka mereka mengambil langkah mundur dan melihat sistem pembangunan secara keseluruhan daripada menempelkan fitur demi fitur ke project.json sampai menjadi bola besar spagetti

Mari kita lihat apa yang mereka sarankan dan kemudian angkat masalah spesifik jika kita menemukan kesalahan dengan itu :)

@aL3891

Jika tim dengan jelas menjelaskan alasan mereka dan alternatif yang dipertimbangkan, dan mengapa mereka ditolak, dan juga mempertimbangkan dan terlibat dengan proposal yang telah disarankan di sini, maka saya setuju dengan itu, dan akan mendukung solusi yang masuk akal. keluar dari proses seperti itu.

Bahkan, ini adalah apa yang saya telah meminta, selama tiga hari sekarang. Wawasan tentang proses pengambilan keputusan dan bukti yang mendukungnya. Informasi yang sejauh ini diberikan dalam hal ini sangat mengecewakan.

Jika kita mendapatkannya, +10 dari saya.

@aL3891 Pertanyaan cepat. Beberapa orang mengatakan kita harus menghadiri stand up hari Rabu untuk mengatasi masalah ini. Apakah Anda mengatakan kita lebih baik menunggu posting blog?

Setiap orang juga harus ingat bahwa ini semua open source. Jika Anda merasa sangat yakin bahwa non-msbuild lebih baik, garpu saja perkakas yang ada dan lanjutkan. Seperti semua pilihan desain perangkat lunak yang menarik, ada pro dan kontra untuk semua sisi argumen. Microsoft harus responsif terhadap pelanggan besar mereka yang membayar tetapi untuk kredit mereka, mereka telah membuat semua hal ini open-source. Jika sesuatu yang lain berhasil untuk Anda, lakukanlah.

Saya menonton video youtube yang diposting @khellang - perubahan ASP.NET adalah _revolutionary_, tetapi sepertinya, pada akhirnya, itu terlalu revolusioner, dan sekarang dengan Xamarin dalam campuran, _revolutionary_ tidak akan memotongnya.

Selain itu, gagasan untuk menciptakan kembali roda tampaknya tidak menarik, padahal tampaknya itu adalah hal yang benar untuk dilakukan...tetapi warisan lagi.

Saya memiliki kritik baru tentang penggunaan MSBuild, berdasarkan standup .NET - sedangkan kami memiliki pemisahan masalah yang baik di sejumlah tempat, MSBuild tidak. Kira-kira, menurut standup, entah bagaimana harus mengetahui segalanya agar efektif, dan hanya mengatur bagian yang berbeda tidak cukup baik.

Sementara itu, dan saya pikir ini harus masuk ke utas lain - sepertinya ada "keputusan rekayasa internal" yang nantinya dibagikan dengan komunitas. Ini membuat saya berpikir bahwa MS tidak sepenuhnya mendapatkan sumber terbuka - seandainya mereka melakukan diskusi ini secara terbuka (dan membuat orang sadar bahwa hal itu sedang terjadi), itu tidak akan terlalu mengejutkan dan kita mungkin sudah memiliki jawaban, dan banyak pemangku kepentingan (dan maksud saya pelanggan yang akan terkena dampak negatif oleh perpindahan dari MSBuild) dapat membuat posisi mereka diketahui dengan jelas sebelumnya, dan komunitas dapat bereaksi lebih tepat waktu pada masalah/kekhawatiran dan bahkan solusi untuk masalah yang disajikan...Sebaliknya, "itu adalah satu-satunya pilihan kami," itulah sebabnya Anda membuka sumber tidak hanya perangkat lunak, tetapi juga proses pengembangan. Ini bagaimana pepatah "diberikan cukup bola mata, semua bug dangkal" seharusnya bekerja. Saya tidak tahu seberapa besar tim teknik di MS, tetapi lebih kecil dari komunitas secara keseluruhan, dan ada beberapa bakat yang sangat bagus di komunitas yang mungkin menghadapi tantangan seperti yang diputuskan tim teknik tidak dapat dijalankan ...dan mungkin itu untuk mereka, tapi tidak untuk masyarakat luas. Open source adalah tentang menggunakan sumber daya dan bakat yang belum dimanfaatkan yang ada di luar sana.

Di sisi lain, mungkin saya melewatkan sesuatu di suatu tempat?

@shederman Saya akan menyarankan mereka yang memiliki kepentingan untuk menghadiri standup dan mengawasi posting blog (yang hampir pasti akan ditautkan di sini).

Bagi mereka yang tidak mengetahui standup, buka di sini: https://live.asp.net/

Anda dapat menambahkannya ke kalender Anda dan ini adalah jam tangan yang berharga bahkan jika Anda tidak peduli dengan perubahan definisi proyek.

@shederman Saya tidak merasa saya benar-benar memiliki wewenang untuk memberi tahu siapa pun apa yang harus dilakukan, tetapi saya dapat memberi tahu Anda apa yang akan saya lakukan. Heck, saya hanya orang luar sama seperti yang lain, saya tidak _tahu_ apa pun :) Saya pikir standup dan acara on.net adalah sumber informasi yang bagus, terutama petunjuk awal tentang apa yang akan datang, jadi saya pasti akan menonton itu. jika mereka mengatakan saya posting blog akan datang saya akan setidaknya memberi mereka manfaat dari keraguan dan melihat apa yang mereka katakan. Tapi saya mungkin akan meninggalkan komentar/mengajukan pertanyaan pada keduanya.

Episode on.net terbaru, yang ditautkan di atas memberikan beberapa wawasan yang bagus

Ada juga repo sistem proyek roslyn yang kemungkinan besar akan melihat banyak tindakan dalam beberapa bulan mendatang

Apakah ada yang punya TL;DR di episode on.net?

Saya rasa saya sangat tidak biasa dalam _membenci_ menonton video tentang pemrograman. Beri saya teks kapan saja

Api neraka! Saya bahkan non-IDE dalam metode pembelajaran saya

Saya pikir saya sangat tidak biasa dalam membenci menonton video tentang pemrograman. Beri saya teks kapan saja :senyum:

Apa masalahnya? Ini _hanya_ satu jam dari waktu Anda. :menyeringai:

@rhires

Bung. Itu sangat mungkin salah satu posting terbaik yang pernah saya lihat tentang masalah ini dalam 3 hari terakhir!

Harga kecil yang harus dibayar untuk tetap berada di ujung tombak, tetapi untuk masing-masing milik mereka;)

Dasar tl; dr:
Tim mulai mendapatkan umpan balik baik dari pelanggan internal seperti xamarin dan eksternal bahwa migrasi untuk proyek yang ada ke project.json sulit dan membuat project.json bekerja sama dengan proyek yang sudah ada serta rantai alat lain seperti yang asli dan yang untuk lainnya platform seperti Android berarti membawa sejumlah besar kode (atau konsep) dari msbuild. Ini akan memakan banyak waktu dan usaha dan menyelipkan rilis dengan jumlah waktu yang tidak dapat diterima serta memperlambat pekerjaan di masa depan (termasuk untuk produk lain seperti xamarin studio dan mono develop, serta pengembang plugin visual studio).

Jadi alih-alih mereka memilih untuk mendasarkan sistem pembangunan pada msbuild tetapi membawa hal-hal yang disukai orang dari sistem baru. Adapun waktunya, akuisisi xamarin tidak diketahui bahkan ketika RC1 dibuat tetapi sekarang setelah selesai, banyak hal berubah.

Mereka juga menyadari bahwa orang-orang sangat menyukai project.json dan mereka juga menyukainya, dan bahwa mereka ingin mempertahankan sebanyak mungkin kebaikan dari itu, bahkan mungkin memungkinkan msbuild untuk membaca file project.json juga melalui target. Skenario tanpa cli dan VS juga merupakan sesuatu yang mereka lihat sebagai skenario inti. Mereka juga berbicara sedikit tentang sistem build lain dan tujuannya adalah untuk memungkinkan orang menggunakan hal lain selain msbuild jika mereka mau

Kemudian mereka berbicara sedikit tentang RC2 dan apa yang dikirim di sana dan juga mereka merenungkan apa yang bisa mereka lakukan secara berbeda mengenai migrasi sistem proyek, menjadi lebih terbuka lebih awal dan memiliki lebih banyak percakapan di GitHub dan seterusnya.

Saya merekomendasikan menontonnya, saya mungkin kehilangan beberapa poin yang lebih baik di sini.

@aL3891 - terima kasih atas ringkasan yang bagus. Itu adalah kerja keras untuk pergi melalui video. Saya setuju bahwa mereka harus menulis ringkasan teks. Saya perhatikan bahwa mereka sedang "belajar", dan masih tidak nyaman dengan membuka proses mereka, bahkan ketika mereka mengatakan itu hal yang baik. Jadi mudah-mudahan ini akan menjadi pengalaman belajar yang baik bagi mereka dan kita akan melihat perubahannya dan menjadi penerima manfaat darinya.

@aL3891 Terima kasih atas ringkasannya!

Harga kecil yang harus dibayar untuk tetap berada di ujung tombak, tetapi untuk masing-masing milik mereka;)

Ah, tapi saya tidak di tepi pendarahan , saya tinggal sedikit kembali dari sana. Cukup jauh ke belakang untuk tidak melukai diri saya sendiri, atau setidaknya begitulah pikir saya ketika saya mengadopsi .NET Core post-RC1

@shederman mengingat bahwa "pasca-RC1" pada dasarnya adalah nightlies atau sumber, bagaimana tepatnya Anda seperti steak Anda?

@neoKushan Maksud saya bahwa kami hanya "mengadopsi* .NET Core _after_ RC1 dirilis. Kami masih menggunakan vanilla RC1.

Jadi, kami menyukai steak medium rare kami. Tapi kami hanya memotong sedikit yang benar-benar mentah dan berteriak memanggil pelayan.

Tapi tidak apa-apa, saya sudah berhenti memanggil pelayan, dan sekarang telah memanggil maitre'd (perwakilan mitra Grup Microsoft kami) untuk datang dan menemui saya dan kita dapat mendiskusikan pengambilan keputusan, penyebaran informasi, dan arah platform.

Kami Tidak Tahu Apa-apa!

Kami belum diberi informasi yang cukup, terlalu banyak teori dan dugaan dalam masalah ini. Ringkasan cepat untuk yang malas yang tidak ingin membaca utas ini:

Apa yang Kami Ketahui

1. xproj akan dikonversi ke csproj.
2. Kami 'mungkin' memiliki file nuget.json.
3. Kami menggunakan msbuild .
4. Ini semua akan terjadi secara bertahap.
5. Perpustakaan tidak akan berubah.
6. Anda tidak perlu menentukan setiap file di csproj.

Yang Belum Kita Ketahui

1. Apakah csproj akan dikompilasi ke .nupkg?
2. Akankah csproj dikompilasi ke beberapa arsitektur dan target sekaligus x86/x64 dotnet/dotnetcore?
3. Apakah akan ada file nuget.config terpisah.
4. Bagaimana perintah ditangani untuk mengeksekusi npm/gulp/bower/etc.?
5. Apakah kita dapat menggunakan dotnet build serta msbuild ? Saya benar-benar siap untuk 'satu .net' yang dicita- citakan oleh
6. Akankah intellisense untuk referensi proyek tetap ada atau hilang?
7. Akankah perkakas VS atau baris perintah cukup baik sehingga kita tidak perlu mengedit file csproj.
8. Apakah kita akan mendapatkan perkakas dotnet add reference MyAssembly ?

Saya pikir masalah ini harus ditutup sampai kami memiliki informasi lebih lanjut.

Saya benar-benar siap untuk 'satu .net' yang dicita- citakan oleh

Yang ini ? :senyum: :+1: :+1: :+1:

Saya pikir masalah ini harus ditutup sampai kami memiliki informasi lebih lanjut.

tapi tapi tapi... lalu apa yang akan saya lakukan dengan hidup saya??? :nangis: :nyengir:

@RehanSaeed

Dan bagaimana jika saya memiliki masalah dengan daftar "Yang Kami Ketahui"?

Haruskah saya menunggu kejelasan tentang daftar "Apa yang Kami Belum Tahu" sebelum menyampaikan kekhawatiran saya?

Atau haruskah aku diam dan menyedotnya?

Seperti yang saya sadari, banyak orang ingin...

Dari semua yang saya lihat, keputusannya 100%, tidak dapat diubah pada:

Jadi apa lagi yang saya butuhkan dari "Apa yang Kami Belum Tahu"?

@shederman Anda mungkin ingin menonton Video On.Net. Ini memberi banyak alasan di balik keputusan itu.

fyi: Saya biasanya mengubah kecepatan menjadi 1,5 untuk menonton lebih cepat. https://www.youtube.com/watch?v=N9MteJH-HsQ

Jika kita akan tetap dengan file proyek berbasis XML, maka tolong tolong TOLONG dapatkah Anda menyarankan/mendorong/memerlukan perkakas untuk meletakkan isi file dalam beberapa jenis urutan. Dan "kronologis" BUKAN urutan yang dapat diterima. Kesulitan terbesar yang saya temukan dengan file proj adalah kesulitan menggabungkannya. Hanya abjad mereka setidaknya. Ya, kami masih akan memiliki masalah penggabungan sesekali, tetapi saya akan mengambil "sesekali" daripada "di mana-mana" setiap hari.

@MelGrubb satu hal yang kami tahu adalah bahwa tata letak proyek baru TIDAK akan mencantumkan semua file yang ada, itu akan seperti project.json melakukannya

Untuk apa pun yang diharapkan dapat dikelola dengan tangan, silakan TOML.

JSON tidak masuk akal sama sekali untuk konfigurasi. Itu bahkan kurang masuk akal daripada XML.

Bagi siapa pun yang tertarik, sepertinya bit RC2 tersedia (Belum ada posting blog yang bisa saya lihat)

https://www.microsoft.com/net/core#windows

dan https://www.microsoft.com/net/download#core

Dua sen saya, fwiw:

Saya menyukai kesederhanaan project.json. Inilah yang saya ingin (dan tidak suka) lihat di perkakas berbasis MSBuild:

• MSBuild tidak boleh terikat dengan VS atau IDE/editor lainnya. Ini harus menjadi alat mandiri yang dapat diinstal sendiri. (Atau disertakan sebagai bagian dari instalasi dotnet cli.) Saya mengatakan ini karena saya harus menginstal instance VS lengkap pada agen build hanya untuk mendapatkan MSBuild. Itu tidak pernah masuk akal bagi saya.
• MSBuild (atau dotnet cli yang berisi MSBuild) itu sendiri harus dapat diinstal dengan baris perintah -- apakah apt-get, chocolately, homebrew, powershell atau bash/curl. Jika saya tidak dapat menginstal ini sebagai bagian dari penyiapan agen pembangunan yang sepenuhnya otomatis (misalnya, di circle.yml atau Dockerfile), itu akan menjadi penghalang jalan dan sumber masalah.
• MSBuild harus sangat ramah baris perintah. Saya seharusnya dapat melakukan apa saja dari baris perintah -- dan karena itu dapat mengotomatiskan apa pun dalam proses pembuatan -- dalam file circle.yml, bash, atau file skrip lainnya. Dan saya ingin melihat penggunaan stdin dan stdout yang baik, jadi saya dapat menyalurkan perintah MSBuild masuk/keluar.
• Bekerja pada proyek .NET Core di VS Code (atau editor non-VS lainnya) seharusnya tidak memerlukan informasi khusus VS dalam file csproj atau di mana pun. Info proyek, dependensi paket nuget, target platform, arahan kompiler, dll. harus dapat dibagikan ke seluruh pengembang menggunakan IDE/editor yang berbeda. Itu masuk akal dalam file proyek. Tetapi orang yang tidak menggunakan VS tidak harus melihat pengaturan perkakas VS -- itu termasuk dalam file terpisah.
• File proyek harus mudah dimengerti dan mudah diedit dengan tangan. Alatnya luar biasa, tetapi saya harus dapat membuka file dan memahami apa yang dilakukan alat untuk saya. Dan lakukan perubahan dengan mudah.
• Meskipun saya tahu tidak ada perbedaan dalam fungsionalitas/kemampuan, saya memiliki preferensi pribadi yang kuat untuk json daripada xml. Saya juga berpikir menggunakan json akan membantu menarik pengembang yang datang dari tumpukan lain. Cukup sulit untuk menarik orang ke .NET tanpa membuat salah satu hal pertama yang mereka lihat menjadi file XML besar yang sulit diuraikan. (Ini lebih emosional daripada logis, tapi saya pikir itu penting.) Tolong setidaknya jadikan json sebagai opsi, dan gunakan opsi itu di generator yeoman dan templat proyek baru lainnya. Paling buruk, harap segera terima permintaan tarik yang tak terhindarkan yang mengimplementasikan format json sederhana di repo MSBuild.
• Akan menyenangkan untuk menyimpan "skrip" gaya npm, jadi saya dapat dengan mudah membagikan perintah yang digunakan untuk dev, test, debug, build, run, docker build/run, dll. dengan tim saya. Itu bisa masuk ke file skrip mereka sendiri, tetapi masuk akal (bagi saya) sebagai bagian dari file proyek.

@jtbennett

"Tetapi orang yang tidak menggunakan VS tidak perlu melihat pengaturan alat VS -- itu termasuk dalam file terpisah."

Hanya untuk menambahkan ada juga banyak hal di file lain sekarang yang kemungkinan besar harus dimasukkan ke dalam file msbuild. Hal-hal yang diabaikan adalah contoh yang baik dari penyediaan file proyek ini masih didukung. Saya tidak dapat memberi tahu Anda berapa banyak proyek yang telah saya lihat yang dibangun di VS tetapi tidak dari baris perintah

@jtbennett

MSBuild tidak boleh terikat dengan VS atau IDE/editor lainnya.

Itu tidak akan terikat ke VS sama sekali, itu akan dikirimkan melalui Nuget sehingga tidak terikat dengan apa pun.

MSBuild (atau dotnet cli yang berisi MSBuild) itu sendiri harus dapat diinstal dengan baris perintah

Ini tidak berubah mulai hari ini, Anda masih dapat menginstal dotnet cli melalui sumber paket biasa.

MSBuild harus sangat ramah baris perintah.

_MSBuild_ akan secara efektif menjadi bagian dari build itu sendiri, jadi saya rasa Anda tidak perlu memasukkan opsi baris perintah. Namun, donet (CLI) jelas akan ramah baris perintah dan saya pikir ini yang Anda inginkan/butuhkan.

Bekerja pada proyek .NET Core di VS Code (atau editor non-VS lainnya) seharusnya tidak memerlukan informasi khusus VS dalam file csproj atau di mana pun.

Saya sepenuhnya setuju dengan ini. Berharap format proyek "baru" akan jauh lebih disederhanakan.

File proyek harus mudah dimengerti dan mudah diedit dengan tangan.

Mereka telah mengatakan bahwa ini adalah prioritas bagi mereka juga.

Meskipun saya tahu tidak ada perbedaan dalam fungsionalitas/kemampuan, saya memiliki preferensi pribadi yang kuat untuk json daripada xml. Saya juga berpikir menggunakan json akan membantu menarik pengembang yang datang dari tumpukan lain. Cukup sulit untuk menarik orang ke .NET tanpa membuat salah satu hal pertama yang mereka lihat menjadi file XML besar yang sulit diuraikan.

Saya menemukan ini menarik, saya pribadi merasa bahwa XML jauh lebih mudah untuk diuraikan daripada JSON tetapi saya pikir banyak dari itu bermuara pada seberapa baik skema yang dirancang (Untuk keduanya). Saya harus menguraikan beberapa XML yang mengerikan di masa lalu dengan nama elemen yang sangat mengerikan (seperti "Elemen") dan sementara MSBuild sama sekali bukan pelanggar terburuk dalam hal itu, itu pasti meninggalkan banyak hal yang diinginkan. Dengan JSON, nama kunci dapat mengalami masalah yang sama.

Secara anekdot, saya baru-baru ini harus mengerjakan proyek di mana seseorang mencoba menyematkan JSON ke dalam elemen XML :(

Posting blog RC2 sekarang: https://blogs.msdn.microsoft.com/webdev/2016/05/16/announcing-asp-net-core-rc2/

.net core post juga aktif https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-net-core-rc2/

Terima kasih @neoKushan !

@michaelvolz Saya tidak berpikir file itu akan tetap ada, jika ini dapat dipercaya: https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/specs/runtime-configuration-file .md

System.GC.Server (lama: gcServer) - Boolean yang menunjukkan apakah server GC harus digunakan (Default: true).

dan

Kita dapat menggunakan format yang berbeda untuk file deps, tetapi jika kita sudah mengintegrasikan parser JSON ke dalam host, tampaknya paling tepat untuk menggunakannya kembali di sini.

Tampaknya agak aneh bagi mereka untuk memiliki XML untuk _project config_ tetapi .json untuk _runtime config_?

Tampaknya agak aneh bagi mereka untuk memiliki XML untuk proyek tetapi .json untuk runtime?

Apakah sekarang? :tertawa:

@Mike-EEE Poin bagus! Saya telah memperbarui semoga memperjelas apa yang saya maksud :kissing:

@neoKushan tidak, pertama kali Anda benar. :smile: Saya setuju dengan Anda dengan cara saya yang snarky dan kontraproduktif. :smirk_cat:

Tapi ya... 100% setuju bahwa memiliki format yang berbeda dalam sebuah solusi menjengkelkan. Memiliki satu format di seluruh papan mengurangi kompleksitas, pengalihan konteks, dan karenanya _kebingungan_. Itu salah satu alasan mengapa saya ingin melihat MSBuild mengaktifkan format yang berbeda dan menjadi format agnostic . Ups, peringatan, steker tak tahu malu. :menyeringai:

Saya pikir saya akan menjadi pengikut perang suci Anda @Mike-EEE, karena kita terjebak dengan msbuild mari kita membuatnya lebih baik.

Hei terima kasih @sandorfr ... jangan ragu untuk berkontribusi pada utas di sana (walaupun itu reaksi/:+1 :). Saya merasa sedikit sendirian di sana dan pasti berjalan ke wilayah yang diperebutkan! Dari sudut pandang saya, saya akan sangat terbuka untuk meningkatkan produk saya untuk meningkatkan adopsi/kesukaan/kegunaan/kesukaan jika ada banyak pelanggan yang terpaksa menggunakan produk saya karena alasan apa pun. Tapi aku tidak bertanggung jawab, jadi. :stuck_out_tongue:

@Mike-EEE Saya membaca beberapa utas, saya sangat tertekan sekarang ... Anda melangkah ke dunia warisan pikiran warisan :D.

Mari berharap orang-orang di Microsoft akan lebih terbuka terhadap ide-ide Anda karena saya sebenarnya baik-baik saja dengan msbuild hanya jika masalahnya dibuat lebih sederhana dan lugas dan saya tidak memerlukan Gui untuk mengedit proyek saya (ya json intellisense jauh lebih baik dari tab proyek studio visual biasa).

Anda melangkah ke dunia warisan pikiran warisan :D.

Wellllll-kata @sandorfr ... wellllll-kata.

Bagi mereka yang tidak mengetahui standup, buka di sini: https://live.asp.net/

OK Saya benar-benar pemalas dan akhirnya memeriksa ini sekarang. Sepertinya standup berikutnya minggu depan? Apakah tim melewatkan minggu ini?

@Mike-EEE Menarik, itu pasti dijadwalkan untuk malam ini pada satu titik, tapi saya ingin tahu apakah itu telah berubah. Saya tweet @shanselman , semoga itu hanya kesalahan tetapi mengingat RC2 baru keluar kemarin, mereka mungkin ingin melewatkannya minggu ini.

Oke keren @neoKushan ... hanya memastikan kewarasan di kepala saya sekali. Yang pasti, saya juga tidak ingin terlalu cepat menangani semua pertanyaan dan ketidakpuasan kami. :mengedip:

dari Slack:

jongalway [9:31 AM] Saya cukup yakin ASP.NET Community Standup besok dibatalkan - baik shanselman dan damianedwards ada di OSCON.
...
davidfowl [9:34 AM] damianedwards: sudah kembali ... tapi shanselman ada di oscon
...
jongalway [9:46 AM] Ya, ASP.NET Community Standup pasti dibatalkan untuk 17/5. Saya memperbarui situs.

@Mike-EEE berurusan dengan semua ... ketidakpuasan kami

😆

Jika masih ada keraguan: https://twitter.com/shanselman/status/732585321775267842

harus melewati. Saya di #vslive dan OSCON

Ada satu hal yang sangat saya nikmati dengan project.json: semua file disertakan secara default dalam proyek, tanpa perlu secara eksplisit menyertakan masing-masing file ini. Dengan proyek besar (maksud saya ribuan file), proses penggabungan benar-benar menyakitkan karena XML, tetapi juga karena setiap file terdaftar di file csproj.

Apakah kita tahu jika akan ada perbaikan di sisi ini?

@pierrus Disebutkan bahwa mereka tidak ingin kembali ke hari-hari di mana semua file terdaftar di dalam file csproj.

@MaximRouiller OK tidak tahu itu, bagus!

@MaximRouiller tetapi mereka ingin kembali ke hari-hari di mana MSBuild adalah Cincin ™, saya berarti Build Tool. 😉

_Ash nudertog vegal durbatulûk, abu nudertog vegal gimbatul,
ash nudertog vegal thrakatulûk agh burzum-ishi krimpatul._

@shederman Saya telah memoderasi sudut pandang saya sejak reaksi pertama saya terhadap berita tersebut.

Pemikiran saya adalah bahwa mereka awalnya ingin mengirimkan format project.json tetapi menormalkan model dengan csproj/Xamarin hanya akan mengharuskan mereka untuk mendorong kerangka lebih lama. Keuntungan yang lebih cepat adalah menggabungkan kembali ke csproj. Mereka dapat menyimpan cara baru dalam file terpisah sambil menyimpan "hanya data" murni di dalam csproj. Itu bagi saya menjelaskan pekerjaan besar RC2 yang telah dilakukan.

Jika Anda memindahkan properti yang hampir tidak berubah dan menyimpan fitur baru yang keren di file terpisah? Kami tidak benar-benar kehilangan apa pun. Ya, kita akan kembali ke monster itu... tapi kita tidak terlalu jauh.

Saya tidak memiliki pengetahuan orang dalam tentang ini. Ini murni spekulasi dari saya.

Bagaimanapun... kita tidak akan berakhir dalam siklus rilis tahunan lagi. Jika mereka siap untuk bertransisi dari project.json ke csproj pasca-RTM, saya berasumsi bahwa perubahan yang lebih besar juga dapat dirilis pasca-RTM.

Perubahan yang tidak diketahui oleh siapa pun kecuali Tim MS.

@MaximRouiller Saya tidak dapat mengerjakan perubahan "mungkin" yang _mungkin_ akan terjadi.

Saya baru saja mengerjakan perubahan yang diumumkan , bahwa mereka pindah dari build yang ringan, ke menggunakan MSBuild dan xproj untuk semuanya.

Ya, kita akan kembali ke monster itu... tapi kita tidak terlalu jauh.

Um, jika kita telah _deprecated_ sesuatu yang berfungsi untuk 90% kasus penggunaan untuk memindahkan _kembali_ ke sesuatu yang terlalu rumit untuk kasus penggunaan tersebut, saya hanya punya satu pertanyaan:

Mengapa?

Mengapa dotnet build memanggil MSBuild ketika msbuild sudah melakukan ini dengan cukup baik. Mengapa menghentikan pembangunan sederhana? Mengapa bekerja ekstra ? Satu-satunya alasan sederhana, keputusan telah dibuat bahwa kita semua harus menggunakan MSBuild sepanjang waktu untuk segalanya, selamanya.

sesuatu yang berfungsi untuk 90% kasus penggunaan

[rujukan?]

Bahkan dengan asumsi itu adalah 90% dari kasus penggunaan, apakah Anda akan bekerja dengan apa pun yang gagal 1/10 kali?

kembali ke sesuatu yang terlalu rumit

Sekali lagi, [rujukan?], satu-satunya hal yang kita tahu sejauh ini adalah bahwa itu akan menjadi XML-csproj dan tidak akan berisi daftar file. Kami tidak tahu apa-apa lagi tentang bagaimana sistem akan bekerja dan saya tidak yakin kami bahkan perlu tahu, karena semua orang di sini hanya memanggil "dotnet build" dan terlepas dari bagaimana build dicapai, itu tidak akan berubah.

Mengapa dotnet build memanggil MSBuild ketika msbuild sudah melakukan ini dengan cukup baik.

Sudahkah kita beralih dari mengatakan MSBuild "terlalu rumit" menjadi "MSbuild sudah melakukan ini dengan cukup baik"? Saat ini, dotnet build hanya _tampak_ sederhana karena semua yang terjadi di latar belakang tersembunyi dari Anda. Beralih ke MSbuild tidak mengubah ini, sejauh yang Anda ketahui itu masih hanya dotnet build .

Untuk seseorang yang terus mengatakan perlu ada perbedaan antara sistem proyek dan sistem pembangunan, Anda tidak mau menerima bahwa sebenarnya ada perbedaan antara memiliki file MSBuild XML sebagai sistem proyek dan memiliki MSBuild sebagai sistem pembangunan - di sana adalah perpisahan sudah.

bekerja untuk 90% kasus penggunaan

@shederman Tolong berhenti menganggap semuanya adalah ASP.NET… Anda dianggap _dengan sengaja tidak peduli_ di utas ini. Saya menyarankan Anda untuk tenang untuk saat ini sampai kita benar-benar mendapatkan informasi lebih lanjut tentang sistem proyek baru daripada hanya berasumsi semuanya akan hancur.

@shederman Alasan Anda membuat shim di atas sesuatu adalah ketika Anda ingin menggantinya. Abstrak sehingga Anda dapat mengubah implementasinya. Kami melakukannya setiap hari. Ini disebut refactoring.

Saya berharap itu diganti. Selain XML, saya pikir itu juga lambat dibandingkan dengan hal-hal lain jika saya ingat dengan benar.

Jika seperti dotnet build pertanyaannya adalah - seberapa sulitkah mengubah proses pembuatan garis bawah? Apakah mungkin untuk mengganti msbuild ke sesuatu yang berbeda? Berapa banyak lakban yang dibutuhkan?

Jika kita bisa membuat perubahan seperti itu dalam 1 atau 2 gulungan selotip, itu bisa diterima.

@neoKushan Sudahkah kita beralih dari mengatakan MSBuild "terlalu rumit" menjadi "MSbuild sudah melakukan ini dengan cukup baik"?

Tidak. Saya yakin saya mengatakan bahwa perintah msbuild menjalankan MSBuild dengan cukup baik. Saya tidak membuat penilaian pada MSBuild sebagai alat. Apakah itu tidak jelas?

@neoKushan Bahkan dengan asumsi itu adalah 90% dari kasus penggunaan, apakah Anda akan bekerja dengan apa pun yang gagal 1/10 kali?

Tidak ada yang mengatakan apa pun tentang apa pun yang gagal . Beberapa alat lebih cocok untuk beberapa tujuan daripada yang lain. Saya akan mengatakan bahwa kekuatan dan kompleksitas MSBuild cocok untuk tujuan sekitar 10% dari build. Kita bisa berdebat tentang persentase yang tepat, tapi itu pasti kurang dari 100%.

@neoKushan Beralih ke MSbuild tidak mengubah ini

Um, itu tidak mengubah proses pembuatan no. Namun _does_ mengubah apa yang diperlukan untuk proses build agar berfungsi (yaitu file csproj), dan kecepatan pelaksanaannya.

@neoKushan Anda tidak mau menerima bahwa sebenarnya ada perbedaan antara memiliki file MSBuild XML sebagai sistem proyek dan memiliki MSBuild sebagai sistem pembangunan - sudah ada pemisahan.

Maaf, tapi saya tidak melihat bagaimana satu alat melakukan dua hal adalah pemisahan.

@poke Tolong berhenti menganggap semuanya ASP.NET

aku tidak. Saya mengatakan solusi yang diusulkan tidak berfungsi dengan baik untuk bangunan sederhana. Beberapa di antaranya adalah build ASP.NET. Secara pribadi saya tidak mengerti mengapa saya membutuhkan sesuatu yang sekuat MSBuild untuk Aplikasi Konsol sederhana.

@poke Anda sengaja dianggap bodoh di utas ini.

Saya harap begitu, ya. Karena apa yang sengaja saya abaikan adalah manfaat luar biasa yang diperoleh pengguna MSBuild.

@poke Saya menyarankan Anda untuk tenang untuk saat ini sampai kami benar-benar mendapatkan lebih banyak informasi tentang sistem proyek baru daripada hanya menganggap semuanya hancur.

Bung, aku tenang aku berjanji.

Saya hanya tidak membiarkan sudut pandang saya tidak setuju dengan berdiri tanpa tantangan. Saya berjanji kepada Anda bahwa itu bukan tanda agitasi. Kebaikan sakes, saya bahkan tidak bisa gelisah oleh beberapa picik sedikit _person_ memanggil saya bodoh 😉

Yang agak ironis ketika twerp _person_ kecil yang sama ini memanggilku untuk tenang.

Lucu sekali.

@MaximRouiller @shederman Alasan Anda membuat shim di atas sesuatu adalah ketika Anda ingin menggantinya. Abstrak sehingga Anda dapat mengubah implementasinya

Ah ya, dan itu akan menjadi alasan yang baik untuk melakukannya, kecuali dari apa yang saya dengar tidak ada niat untuk mengganti MSBuild. Ini adalah sistem build yang dipilih untuk masa mendatang. Saya ingin jika kita mengizinkan proyek untuk berdiri tanpa item spesifik MSBuild, dan jika dotnet build melakukan build lite yang ada, atau memilih alat build berdasarkan sesuatu, misalnya config. Jika Anda ingin menggunakan MSBuild, tentu saja buat file msbuild dan jalankan msbuild .

Tidak. Saya yakin saya mengatakan bahwa perintah msbuild menjalankan MSBuild dengan cukup baik.

Untuk menempatkan ini ke dalam konteks:

Mengapa dotnet build memanggil MSBuild

dotnet build melakukan lebih dari "hanya" memanggil kompiler, lihat implementasi CLI saat ini dari dotnet build . Membangun satu proyek hanyalah bagian dari proses dotnet build . Akhirnya _part_ dari proses itu akan memanggil msbuild tapi itu bukan tugas Anda, itu tugas CLI.

Saya tidak membuat penilaian pada MSBuild sebagai alat.

Semua yang telah Anda lakukan di utas ini adalah menilai MSBuild sebagai alat. Untuk mengklaim bahwa Anda tidak melakukan hal seperti itu, sejujurnya, menggelikan.

Apakah itu tidak jelas?

Sangat sedikit dari apa yang Anda katakan yang jelas, atau setidaknya dipikirkan dengan baik.

Tidak ada yang mengatakan apa pun tentang apa pun yang gagal. Beberapa alat lebih cocok untuk beberapa tujuan daripada yang lain.

Jadi beberapa alat gagal menjadi sesuai untuk tujuan.

Saya akan mengatakan bahwa kekuatan dan kompleksitas MSBuild cocok untuk tujuan sekitar 10% dari build.

Itu menarik karena setiap pengembang Visual Studio .net di luar sana pasti tidak setuju. Anda secara efektif mengatakan bahwa MSBuild tidak baik untuk 90% pengguna (mengabaikan fakta bahwa Anda mengeluarkan angka dari pantat Anda), yang - sekali lagi - menggelikan.

Um, itu tidak mengubah proses pembuatan no.

Jika prosesnya tidak berubah, maka satu-satunya argumen Anda adalah bahwa Anda tidak menyukai struktur proyek - fakta bahwa itu MSbuild atau apa pun di balik tudung sama sekali tidak relevan .

Namun itu mengubah apa yang diperlukan agar proses build berfungsi (yaitu file csproj)

Itu secara harfiah satu-satunya hal yang benar-benar berubah sejauh orang akan melihat.

dan kecepatan pelaksanaannya.

[rujukan?]

Tolong tunjukkan saya bagaimana proses baru lebih cepat atau lebih lambat, mengingat saat ini tidak ada .

Maaf, tapi saya tidak melihat bagaimana satu alat melakukan dua hal adalah pemisahan.

Karena satu alat tidak melakukan dua hal, MSBuild mungkin membangun sistem tetapi perubahannya berkaitan dengan sistem proyek. Sama sekali tidak ada yang menghentikan Anda untuk menggunakan sistem build yang berbeda jika Anda mau, itu hanya non-sepele.

aku tidak. Saya mengatakan solusi yang diusulkan tidak berfungsi dengan baik untuk bangunan sederhana

dotnet new
dotnet restore
dotnet build

Tolong tunjukkan saya bagaimana solusi yang diusulkan mengubah apa pun tentang skenario "pembuatan sederhana"

Beberapa di antaranya adalah build ASP.NET.

yo asp-net web
dotnet restore
dotnet build

Secara pribadi saya tidak mengerti mengapa saya membutuhkan sesuatu yang sekuat MSBuild untuk Aplikasi Konsol sederhana.

Anda tidak. Anda hanya perlu dotnet build . Yang masih akan Anda miliki. Tidak ada yang berubah di sana.

Aku tenang aku berjanji.

twerp kecil

:-1:

@neoKushan Akan sangat menyenangkan jika Anda dapat memahami konsep antara respons terhadap kutipan kutipan dan komentar tentang seluruh diskusi. Saya berasumsi Anda _mampu_ melakukan itu, jadi satu-satunya kesimpulan adalah itu disengaja. Jika demikian, beri tahu Anda bahwa itu adalah taktik yang tidak jujur ​​secara intelektual. Saya harap Anda tahu itu, tetapi saya memberikan manfaat dari keraguan di sini.

Saya juga berpikir Anda harus minum pil dingin. Kami hanya mendiskusikan apa yang kami yakini sebagai yang terbaik untuk kerangka kerja, kami tidak mencoba untuk _melawan_ satu sama lain. Serang argumennya, bukan orangnya. Nah, itulah yang telah saya _coba_ lakukan selama beberapa hari sekarang (kecuali dalam satu kasus baru-baru ini, lihat di bawah).

Itu menarik karena setiap pengembang Visual Studio .net di luar sana pasti tidak setuju.

Lucu, saya telah mengumpulkan bukti yang mengatakan sesuatu yang berbeda. Di mana Anda mendapatkan milik Anda?

Karena satu alat tidak melakukan dua hal, MSBuild mungkin membangun sistem tetapi perubahannya berkaitan dengan sistem proyek. Sama sekali tidak ada yang menghentikan Anda untuk menggunakan sistem build yang berbeda jika Anda mau, itu hanya non-trivial .

Ya. Jadi kami setuju. Saya akan hanya benar-benar, benar-benar menyukainya jika itu sepele.

Apakah itu benar -

Anda tidak. Anda hanya perlu membangun dotnet. Yang masih akan Anda miliki. Tidak ada yang berubah di sana.

Dan dotnet build akan melakukan apa sebenarnya? Keluar dari msbuild ? Mengapa kita tidak bisa menggunakan msbuild jika kita ingin menggunakan MSBuild? Apa sebenarnya tujuan dari dotnet build dalam situasi itu? Apa yang ditambahkan ke perkakas?

twerp kecil

Sebuah upaya untuk menjadi lucu, tapi Anda mungkin benar.

@poke Saya minta maaf tanpa syarat.

Akan sangat menyenangkan jika Anda dapat memahami konsep antara tanggapan terhadap kutipan kutipan dan komentar tentang keseluruhan diskusi. Saya berasumsi Anda mampu melakukan itu, jadi satu-satunya kesimpulan adalah itu disengaja. Jika demikian, beri tahu Anda bahwa itu adalah taktik yang tidak jujur ​​secara intelektual. Saya harap Anda tahu itu, tetapi saya memberikan manfaat dari keraguan di sini.

Secara harfiah tidak tahu apa yang Anda maksud.

Saya juga berpikir Anda harus minum pil dingin.

...

Serang argumennya, bukan orangnya.

:MasukkanRolleyEyeEmoticonDi Sini:

Lucu, saya telah mengumpulkan bukti yang mengatakan sesuatu yang berbeda. Di mana Anda mendapatkan milik Anda?

Oke keren, jadi dari mana angka 10%/90% itu?

Ya. Jadi kami setuju. Aku hanya akan sangat, sangat menyukainya jika itu sepele.

Yang tidak ada hubungannya dengan mereka berubah menjadi msbuild, Anda akan mengalami kesulitan mengubah sistem build saat ini dari dotnet build .

Dan dotnet build akan melakukan apa sebenarnya? Keluar untuk msbuild?

Apa yang berbeda dengan dotnet build memanggil msbuild daripada dnx atau roslyn?

Mengapa kita tidak bisa menggunakan msbuild saja jika kita ingin menggunakan MSBuild?

Jadi Anda ingin menggunakan MSBuild sekarang? Tidak ada yang menghentikan Anda, ini adalah paket nuget hari ini. Tergila-gila. Saya terkejut Anda bahkan bertanya, mengingat betapa Anda membenci msbuild.

Apa sebenarnya tujuan dari dotnet build dalam situasi itu? Apa yang ditambahkan ke perkakas?

Apakah kita benar-benar membahas manfaat dotnet build ? Anda tidak suka dotnet build ? Anda tidak mengerti tujuan dari dotnet build ? Itu sepertinya tidak mungkin. Apa yang Anda coba tanyakan?

@neoKushan tolong berhenti memusuhi dia. ini tidak konstruktif.

Oke keren, jadi dari mana angka 10%/90% itu?

Itu datang dari pengalaman pribadi saya. Saya telah menemukan bahwa sekitar 90% dari build yang saya dan tim saya buat dalam beberapa tahun terakhir tidak memerlukan apa pun yang lebih kompleks daripada yang dilakukan RC1 dotnet build .

Yang tidak ada hubungannya dengan mereka berubah ke msbuild, Anda sudah akan kesulitan mengubah sistem build saat ini dari dotnet build.

Tolong jelaskan, saya tidak yakin apa yang Anda maksud di sini.

Jadi Anda ingin menggunakan MSBuild sekarang? Tidak ada yang menghentikan Anda, ini adalah paket nuget hari ini. Tergila-gila. Saya terkejut Anda bahkan bertanya, mengingat betapa Anda membenci msbuild.

_mendesah_. Pertanyaan saya adalah: mengapa dotnet build harus keluar ke MSBuild ketika msbuild melakukannya dengan sangat baik? Mengapa dua perintah melakukan satu hal?

Saya sudah menanyakan ini sekitar tiga kali sejauh ini, dan setiap kali Anda salah paham atau salah mengartikannya.

Saya bertanya tentang tindakan dua perintah baris perintah yang berbeda
Saya bertanya mengapa keduanya akan melakukan hal yang sama
Saya bertanya, jika mereka berdua melakukan hal yang sama, mengapa tidak memiliki satu perintah
Saya bertanya apa perintah kedua menambah situasi jika mereka berdua melakukan hal yang sama
Saya tidak memberikan penilaian pada kualitas alat yang mendasari dalam konteks itu, meskipun saya mungkin telah melakukannya di tempat lain
Penilaian tersebut di tempat lain tidak berdampak pada pertanyaan yang diajukan, karena pertanyaan yang diajukan adalah tentang perintah baris perintah dan tindakannya, bukan pada alat yang mendasarinya sama sekali
Saya tidak mencoba membahas apa lagi yang mungkin atau mungkin tidak dilakukan alat tersebut di masa lalu, hanya apa yang akan mereka lakukan di masa depan.

Maaf untuk eksposisi panjang yang menjelaskan pertanyaan satu kalimat, tetapi tampaknya perlu.

Sebuah artikel di InfoQ :
"Microsoft telah sampai pada kesimpulan bahwa eksperimen project.json telah gagal dan akan beralih kembali menggunakan file .csproj." :kecewa:

Seperti yang saya katakan, persepsi itu penting.

Pertanyaan saya adalah: mengapa dotnet harus membangun shell ke MSBuild ketika msbuild sudah melakukannya dengan sangat baik? Mengapa dua perintah melakukan satu hal?

Karena mereka tidak melakukan hanya satu hal?

Mengapa MSBuild harus keluar ke csc ketika csc sudah melakukan pekerjaan yang baik untuk membangun barang? Mengapa dua perintah melakukan satu hal?

Mengapa dotnet test harus keluar ke runner pengujian xUnit ketika ia sudah melakukan pekerjaan yang baik dalam menjalankan pengujian sendiri. Mengapa dua perintah melakukan satu hal?

Mengapa dotnet restore harus keluar ke NuGet ketika NuGet sudah melakukan pekerjaan yang baik untuk menginstal paket. Mengapa dua perintah melakukan satu hal?

Anda mendapatkan idenya... (Saya harap :wink :)

@sandorfr

@neoKushan tolong berhenti memusuhi dia. ini tidak konstruktif.

Saya tidak sengaja memusuhi siapa pun, saya mendekonstruksi argumen @shederman , yang persis seperti yang dia ingin orang lakukan:

Serang argumennya, bukan orangnya.

Meskipun pada titik ini, saya bahkan tidak sepenuhnya yakin apa argumen @shederman karena kami tampaknya entah bagaimana berubah dari XML menjadi buruk, menjadi MSBuild menjadi buruk hingga sekarang dotnet build buruk.

Mari kita lanjutkan.

Itu datang dari pengalaman pribadi saya.

Ini adalah "bukti" Anda? Yang, ingat, Anda cetak tebal:

Lucu, saya telah mengumpulkan bukti yang mengatakan sesuatu yang berbeda. Di mana Anda mendapatkan milik Anda?

Dan sekarang "Pengalaman pribadi". Itulah yang kami sebut bukti _anecdotal_.

Saya telah menemukan bahwa sekitar 90% dari build yang saya dan tim buat dalam beberapa tahun terakhir tidak memerlukan apa pun yang lebih kompleks daripada yang dilakukan oleh build RC1 dotnet.

Dan apa yang Anda harapkan dari RC2 dotnet build atau RTM dotnet build atau pasca-RTM dotnet build berubah dalam hal ini?

Tolong jelaskan, saya tidak yakin apa yang Anda maksud di sini.

Argumen Anda tampaknya (Dan perbaiki saya jika saya salah) sesuatu di sepanjang baris "Tidak sepele untuk membuat dotnet build melakukan sesuatu selain dari apa yang diprogram Microsoft untuk dilakukan". Yang baik-baik saja di masa DNX karena kita semua menyukai DNX, tetapi sekarang Microsoft ingin menggunakan MSBuild di bawah tenda dan Anda tidak menyukai MSBuild, Anda ingin opsi untuk mengganti MSbuild untuk sesuatu yang lain - maksud saya adalah ini bukan sesuatu yang baru, jika Anda memiliki masalah dengan DNX maka Anda juga tidak dapat mengubahnya, jadi apa pun "masalah" Anda dengan dotnet build , bukanlah hal baru dan karenanya saya pikir itu tidak relevan ke diskusi _actual_ di sini, yang merupakan struktur dari project.json pindah ke . csproj

mendesah. Pertanyaan saya adalah: mengapa dotnet harus membangun shell ke MSBuild ketika msbuild sudah melakukannya dengan sangat baik? Mengapa dua perintah melakukan satu hal?

@khellang sudah menjawab ini, jadi saya tidak ingin mengulanginya sendiri, tetapi itu juga karena saya sudah menyatakan dengan singkat apa perbedaannya (saya benci mengutip diri saya sendiri tetapi saya tidak berpikir Anda benar-benar membaca ini):

dotnet build melakukan lebih dari "hanya" memanggil kompiler, lihat implementasi CLI saat ini dari dotnet build . Membangun satu proyek hanyalah bagian dari proses dotnet build . Akhirnya _part_ dari proses itu akan memanggil msbuild tapi itu bukan tugas Anda, itu tugas CLI.

Jadi, sekali lagi, setidaknya untuk ketiga kalinya: menelepon dotnet build tidak identik dengan menelepon msbuild . Ini bukan, seperti yang Anda katakan, "dua perintah melakukan satu hal" dan tidak pernah ada. Itu bahkan tidak pernah dalam cakupan seluruh diskusi ini namun entah bagaimana Anda berakhir di sana.

Diskusi sebenarnya, yang benar-benar penting adalah struktur project.json dan bagaimana itu digabungkan ke .csproj. Sistem pembangunan yang mendasari sebagian besar tidak relevan jika Anda hanya menginginkan sesuatu yang sederhana karena Anda akan selalu hanya memiliki dotnet build .

Jadi bagaimana kita bisa membedakan antara apa yang dilakukan msbuild vs apa yang dilakukan dotnet build sekarang? Apa perbedaan dalam cara kerjanya? Saya pikir itu yang hilang dalam diskusi ini. Semua orang mungkin sudah tahu, tapi saya pikir mungkin meletakkannya di atas meja mungkin membuat kejelasan.

@khellang Saya suka cara Anda mengekspresikannya, tetapi kemudian dari sana, saya dapat mengonfigurasi apa yang dilakukan dotnet test . Saya dapat menempatkan test runner yang berbeda dari xunit di project.json, dan dotnet test akan memanggil test runner itu.

Namun, dari apa yang saya dengar tentang perubahan yang akan datang, tidak akan ada kemampuan serupa dengan dotnet build . Itu akan selalu menggunakan MSBuild untuk melakukan pembuatannya. Apakah pemahaman itu tidak benar?

@neoKushan Saya tidak sengaja memusuhi siapa pun, saya mendekonstruksi poin demi poin argumen @shederman

Setidaknya kami sekarang tahu apa yang Anda _pikir_ Anda lakukan. Apa yang Anda _sebenarnya_ lakukan adalah salah mengartikan, menggabungkan posisi, dengan sengaja salah paham, dan umumnya menjadi sedikit brengsek. Nada bicara Anda agresif, dan Anda sengaja bersikap tumpul. Sedemikian rupa sehingga saya harus mencoba dan memecah semuanya menjadi satu pemikiran pada satu waktu. Yang, lucunya, Anda salah mengartikannya sebagai perubahan posisi.

@neoKushan Meskipun pada titik ini, saya bahkan tidak sepenuhnya yakin apa argumen @shederman karena kami tampaknya entah bagaimana telah berubah dari XML menjadi buruk, ke MSBuild menjadi buruk hingga sekarang dotnet build buruk.

XML-nya buruk. MSBuild buruk. Jika dotnet build hanya menggunakan MSBuild, itu juga buruk. Tolong, coba dan pertahankan. Ini tidak begitu rumit. Jika Anda tidak sengaja bersikap tumpul, Anda akan memahaminya sejak lama dan dapat benar-benar menambahkan masukan yang membangun.

@neoKushan Ini "bukti" Anda? Yang, ingat, Anda cetak tebal:

Um tidak, itu pengalaman pribadi saya, bukan buktinya. Bukti saya adalah 281 responden dari 383 yang percaya bahwa pemindahan .NET Core kembali ke MSBuild adalah ide yang buruk. Dan 85 responden yang percaya bahwa MSBuild pada dasarnya rusak. ITU bukti saya. Di mana milikmu tepatnya?

Anda tahu, untuk mendukung pernyataan Anda bahwa "... _every single_ Visual Studio .net developer di luar sana harus tidak setuju"? [Penekanan ditambahkan]

@neoKushan Diskusi sebenarnya, yang benar-benar penting adalah struktur project.json dan bagaimana itu digabungkan menjadi .csproj

Saya sebenarnya setuju denganmu. TAPI latar belakang sangat penting. Rencana yang diungkapkan MS adalah MSBuild akan menjadi pusat dari build universe. Saya tidak _suka_ itu, tapi mari kita lanjutkan. Mengingat itu, maka ada pertanyaan sederhana:

"Apakah MSBuild akan menjadi sistem pembangunan utama untuk .NET Framework selamanya ?"

Jika demikian, kita hanya memerlukan perintah msbuild , dan kita tidak memerlukan perintah dotnet build , itu sangat berlebihan.

Namun, jika kami menerima bahwa pada titik tertentu MSBuild mungkin bukan _One True Build System_, maka kami berada di wilayah yang lebih menarik. Kemudian, memiliki dotnet build masuk akal. TAPI sangat penting bagi kita untuk mengingat masa depan itu saat mendiskusikan penggabungan csproj dan project.json.

Apa yang saya coba (mungkin dengan buruk) tunjukkan adalah bahwa opsi yang lebih baik (dalam pikiran saya) adalah mencoba dan menjaga pemisahan yang jelas antara file _project definition_ dan file _build definition_. Ini akan menyiapkan kami lebih baik untuk dotnet build yang dapat mendukung beberapa mesin build. Sebaliknya, jika kita memindahkan semuanya ke csproj, maka kita mengunci diri kita sendiri ke dalam dunia MSBuild.

Dan ya, saya memahami bahwa situasi "hanya satu build yang benar" ini ada di DNX. Tapi saya tidak menginterogasi itu karena saya _menyukai_ build yang kami miliki. Ah, situasi yang kita tempati ketika kita dengan senang hati menerima ketidakadilan yang kita _suka_ .

Jadi, pertimbangkan situasi di mana kita memiliki dotnet build dapat menggunakan salah satu dari beberapa alat pembangunan, tergantung pada konfigurasi. Sama seperti dotnet test dapat menggunakan salah satu dari beberapa test runner. Sekarang, mengingat dunia imajiner seperti itu, sekarang bagaimana Anda menggabungkan csproj dan project.json? Itulah diskusi yang ingin saya lakukan.

@rhires Dari level yang sangat tinggi dotnet build :

1. Mengumpulkan file proyek
2. Menentukan apakah prasyarat terpenuhi untuk build inkremental
3. Membaca project.json
4. Menentukan kerangka kerja target
5. Untuk setiap proyek:
   
   
   
   1. Bangun dependensinya
   
   
   2. Jika inkremental, periksa apakah pembangunan kembali diperlukan
   
   
   3. Menentukan direktori keluaran
   
   
   4. Mengumpulkan file sumber
   
   
   5. Menentukan opsi kompilasi
   
   
   6. Menjalankan skrip prakompilasi
   
   
   7. Jalankan kompiler dengan file sumber dan opsi
   
   
   8. Jalankan skrip postcompile
   
   
   9. Keluaran laporan
   
   

@shederman Terima kasih! Dari titik ini, apa yang akan ditambahkan/dikurangi/diganti oleh msbuild ke/dari/dalam proses ini?

Setidaknya kami sekarang tahu apa yang Anda pikir Anda lakukan. Apa yang sebenarnya Anda lakukan adalah salah mengartikan, menggabungkan posisi, dengan sengaja salah paham, dan umumnya menjadi sedikit brengsek. Nada bicara Anda agresif, dan Anda sengaja bersikap tumpul. Sedemikian rupa sehingga saya harus mencoba dan memecah semuanya menjadi satu pemikiran pada satu waktu. Yang, lucunya, Anda salah mengartikannya sebagai perubahan posisi.

Panci -> Ketel

Anda telah mengubah posisi Anda berkali-kali sehingga Anda bahkan tidak dapat mempertahankan diri Anda sendiri, Anda telah berdebat tentang setiap aspek dari rantai pembangunan, menunjukkan bahwa Anda jelas tidak memiliki pemahaman yang baik tentang bagaimana itu semua. bersama-sama seperti yang Anda _pikir_ Anda lakukan, namun _saya_ menjadi keledai karena saya berani menunjukkan di mana argumen Anda gagal. Saya masih menunggu Anda menanggapi setengah dari poin yang saya kemukakan di atas, tetapi yang Anda lakukan hanyalah melanjutkan untuk memilih beberapa aspek lain dari proses pembuatan.

XML-nya buruk. MSBuild buruk. Jika dotnet build hanya menggunakan MSBuild, itu juga buruk.

Tidak ada orang lain selain _you_ yang mengklaim hal seperti ini. Bukan siapa-siapa. Bahkan tidak ada petunjuk sedikit pun bahwa hal semacam itu akan terjadi. Saya telah mengatakan kepada Anda berulang kali bahwa dotnet build tidak _just_ akan memanggil MSBuild , saya telah mengatakan kepada Anda bahwa dotnet build dan msbuild tidak sepenuhnya identik dengan satu sama lain dan dotnet build melakukan lebih dari sekadar memanggil kompilator. Saya bahkan menautkan Anda ke kode sumber sialan dan yang lain telah datang dan mengatakan hal yang sama, namun Anda masih bersikeras bahwa ini adalah apa yang terjadi?

Tolong, coba dan pertahankan.

Bagaimana dengan _you_ keep up? Tolong, tunjukkan di mana Anda mendapatkan ide bahwa dotnet build hanya akan menelepon msbuild . Siapa yang memberitahumu itu? Di mana Anda membacanya?

Bukti saya adalah 281 responden dari 383 yang percaya bahwa pemindahan .NET Core kembali ke MSBuild adalah ide yang buruk. Dan 85 responden yang percaya bahwa MSBuild pada dasarnya rusak. ITU bukti saya. Di mana milikmu tepatnya?

Dan Anda menarik 10% dari angka-angka itu, bukan? Ingat, ini adalah klaim Anda:

Saya akan mengatakan bahwa kekuatan dan kompleksitas MSBuild cocok untuk tujuan sekitar 10% dari build.

Kemudian Anda kemudian berkata:

Lucu, saya telah mengumpulkan bukti yang mengatakan sesuatu yang berbeda.

Jadi di mana bukti ini? Saya ingin tahu bagaimana Anda menarik sosok itu dari "bukti" Anda.

Anda tahu, untuk mendukung pernyataan Anda bahwa "... setiap pengembang Visual Studio .net di luar sana pasti tidak setuju"?

Mudah: https://msdn.microsoft.com/en-us/library/ms171468.aspx

Visual Studio menghosting MSBuild untuk memuat dan membangun proyek terkelola.

Jika Anda menggunakan Visual Studio untuk membangun proyek Anda, Anda menggunakan MSBuild. Bahkan saat bekerja dengan .net core hari ini, bahkan dengan RC1 VS menggunakan MSbuild di bawah tenda. Anda mungkin tidak menyukai MSbuild, tetapi seperti yang saya katakan hampir setiap pengembang VS di luar sana menggunakannya baik mereka menyadarinya atau tidak.

Rencana yang diungkapkan MS adalah MSBuild akan menjadi pusat dari build universe.

Saya tidak setuju dengan ini. Mereka tidak pernah mengatakan bahwa itu akan menjadi pusat, semua yang mereka katakan adalah bahwa beberapa bagian dari project.json akan berakhir kembali ke .csproj - di luar ini, mereka tidak mengatakan sepatah kata pun tentang sejauh mana ini mengubah dotnet build proses.

"Apakah MSBuild akan menjadi sistem pembangunan utama untuk .NET Framework selamanya?"

Jika demikian, kita hanya memerlukan perintah msbuild, dan kita tidak memerlukan perintah dotnet build, itu sangat berlebihan.

Seperti yang telah dinyatakan berkali-kali sekarang, dotnet build dan msbuild adalah dua hal yang benar-benar terpisah. dotnet build melakukan lebih dari sekadar memanggil rantai alat kompiler. Tujuan dari dotnet build adalah untuk menjaga agar proses build tetap sederhana bagi orang-orang. Melihat lagi:

dotnet new
dotnet restore
dotnet build

Bahkan jika msbuild menjadi komponen inti dari dotnet CLI, itu tidak mengubah fakta bahwa dotnet build adalah bersih, pembungkus sederhana di sekitar apa yang (dan akan selalu) sistem yang cukup kompleks. Neraka, setengah alasan dotnet CLI ada (Dan DNX sebelumnya) adalah secara khusus untuk menjauh dari argumen baris perintah yang akhirnya menjadi MSBuild. Argumen Anda agak seperti mengatakan "Mengapa kita membutuhkan perintah npm install padahal saya hanya bisa curl paketnya?". Tentu, Anda dapat melakukan semuanya secara manual jika Anda benar-benar menginginkannya, tetapi Anda hampir tidak mendapatkan apa-apa darinya. Jadi bagaimana jika dotnet build menggunakan msbuild bawah tenda? Anda hampir pasti tidak akan pernah melihatnya, atau perlu mengetahuinya.

Anda tidak dapat membandingkan pengalaman lama Anda dengan MSBuild, ini sangat berbeda. Kita semua (tampaknya) telah dibakar oleh yang itu karena kita terbiasa membuka VS, membuat proyek dan membuatnya baru saja dibangun, tetapi kemudian ketika Anda pergi untuk membangun proyek yang sama di server build, tiba-tiba mengeluh tentang omong kosong yang seharusnya _berfungsi_. Mungkin salah satu hal terbaik yang dilakukan Microsoft dengan TFS 2015 adalah membuat definisi build yang terkait dengan _Visual Studio_ daripada _MSBuild_ karena Anda kembali ke "hanya bekerja". Itulah tepatnya toolchain build ini - dotnet build tidak dimaksudkan untuk menggantikan seluruh sistem build Anda, ini hanya terkait dengan membangun proyek Anda, bahkan jika ia menggunakan MSBuild bawah tenda. Jika Anda ingin menggunakan sesuatu seperti TeamCity atau Jenkins, hanya dotnet build Anda harus memberitahu mereka untuk menelepon dan dotnet melakukan sisanya. _Bagaimana_ hal itu tidak menjadi perhatian Anda.

Satu-satunya hal - dan maksud saya ini sepenuhnya, satu-satunya hal yang benar-benar berubah untuk Anda adalah file project.json/csproj. Itu dia_. Itulah mengapa semua perdebatan tentang apa yang sebenarnya dilakukan dotnet build dan apa yang baik dan buruk dari MSBuild adalah benar-benar _tidak ada gunanya_.

@neoKushan berhenti saja ...

@neoKushan berhenti saja...

Sebagian dari saya suka membayangkan tim ASP.NET sengaja membatalkan standup karena mereka menikmati pertunjukan, dan memberikan jawaban akan mengakhiri semuanya. :senyum:

Dari posisi agnostik saya (sekarang tegas), kedua belah pihak tampaknya sengaja tumpul terhadap poin yang lain untuk beberapa waktu sekarang. Anda berhasil menetapkan citra mental saya tentang komunitas .NET Core sebagai tidak konstruktif dan lebih buruk. Bicara tentang persepsi...

Sebagian besar barang non-NuGet akan digabungkan ke csproj. Apa yang akan terjadi pada barang NuGet jika tidak ada project.json (nuget.json?) ?

menyediakan cara bagi pengguna untuk mengelola dependensi mereka seperti yang mereka suka, dan mungkin memberikan dotnet nuget secara default karena NuGet sudah mapan di komunitas .net.

tetapi jangan memasangkan semua hal inti dotnet dengan satu-satunya cara untuk mengelola dependensi ( dotnet restore tidak boleh sama dengan dotnet nuget restore ), bagi banyak orang nuget hanyalah repositori paket tetapi bukan manajer ketergantungan, orang memang memiliki pilihan lain yang mungkin mereka anggap lebih produktif/cocok untuk kasus penggunaan "manajer ketergantungan".

Apakah kami akan mempertahankan IntelliSense untuk manajemen ketergantungan? Ini pada dasarnya adalah salah satu fitur demo terbaik yang kami miliki untuk project.json.

Anda dapat menggunakan kembali logika, saya tidak melihat ini sebagai masalah besar, misalnya, saya membuka nuget.org dan melakukan pencarian untuk sebuah paket dan menyalin id dari url, itu efisien.

Anda mungkin ingin memberikan penyelesaian shell juga, yang akan memberi Anda banyak kekaguman dari orang-orang yang menggunakan bash atau zsh :

dotnet nuget add S[tab] menyediakan daftar penyelesaian untuk pengidentifikasi proyek yang dimulai dengan S

memiliki intellisense di msbuild *file proj harus dapat dilakukan juga jika Anda ingin membuat tag <NuGet> sana, tetapi sama, jangan memasangkan nuget ke seluruh ekosistem, yaitu <Package>NuGetPackageId</Package> seharusnya' t sama dengan <NuGet>NuGetPackageId</NuGet> ATAU harus ada cara yang sangat sederhana (dan didokumentasikan dan didukung dengan sangat baik) untuk menimpanya.

Plugin Paket Visual Studio memang memiliki pelengkapan otomatis pada nuget, ini berfungsi tetapi agak lambat karena saya menganggap perlu waktu untuk mengembalikan respons dari nuget.org.

Apakah kami mempertahankan format JSON untuk manajemen ketergantungan? XML mengerikan untuk hal-hal semacam itu (lihat Maven). JSON lebih sederhana untuk mewakili dependensi tersebut.

Jika Anda mencari ide untuk format, Anda dapat melihat paket.dependencies , jika tidak, menurut saya itu tidak terlalu penting, mengedit project.json kira-kira sama baiknya dengan mengedit packages.config dalam hal berurusan dengan NuGet, lakukan apa pun yang nyaman bagi pengguna yang memilih NuGet sebagai manajer ketergantungan paket (yang bukan 100% pengguna dan tidak harus melakukannya)

Sebagai catatan tambahan, jika Anda masih memerlukan file lock , dapatkah Anda membuatnya dapat dibaca pengguna, sesuatu yang diperiksa di repositori, dan mudah dibedakan?

@rhires Dari titik ini, apa yang akan ditambahkan/dikurangi/diganti oleh msbuild ke/dari/dalam proses ini?

Yah, itu tergantung pada bagaimana mereka mengintegrasikannya. Jika mereka melakukan "penguncian keras", mengintegrasikan msbuild jauh ke dalam dotnet build, yang tampaknya ditunjukkan oleh info publik sebagai pendekatan pilihan mereka, maka itu akan diganti seluruhnya oleh msbuild.

Namun, jika mereka membuat dotnet build dikonfigurasi, saya berharap itu akan berfungsi seperti:

1. Mengumpulkan file proyek
2. Membaca project.json
3. Menentukan kerangka kerja target
4. Tentukan alat build yang akan digunakan
5. Keluar ke alat build
6. Keluaran laporan

@neoKushan Itu sebabnya semua perdebatan tentang apa yang benar-benar dilakukan dotnet build dan apa yang baik dan buruk dari MSBuild sama sekali tidak ada gunanya.

👍

Apa yang saya ingin _discuss_ adalah seperti apa project.json dan csproj akan terlihat di dunia di mana dotnet build dapat keluar ke MSBuild sebagai salah satu dari _banyak kemungkinan alat bantu_. Apakah itu tidak apa apa? Bisakah kita berbicara tentang apa yang akan ada di project.json vs apa yang akan ada di csproj, mengingat itu?

Karena kalau kita _bisa_ berdiskusi itu saya yakin thread ini justru bisa menjadi konstruktif.

@jmm Anda berhasil menetapkan citra mental saya tentang komunitas .NET Core sebagai tidak konstruktif dan lebih buruk

Maaf tentang itu. Namun, jika Anda punya waktu, saya sarankan membaca beberapa arsip obrolan dari beberapa proyek sumber terbuka besar lainnya.

Bertengkar sebenarnya merupakan tanda komunitas yang sehat, seperti halnya dalam kehidupan. Ketika setiap orang mengikuti sekelompok pemimpin secara membabi buta, yah, hal-hal biasanya tidak begitu baik. Keputusan, bukti, dan pengambilan keputusan harus terbuka untuk diinterogasi.

@shederman Demi melanjutkan diskusi yang produktif, saya juga ingin menarik garis untuk membahas implikasi dari perubahan yang diusulkan.

Saya pikir diskusi inti di sini harus pada tata letak dan format .csproj "baru" dan apa yang terjadi pada project.json (Atau lebih spesifik, struktur "proyek" secara keseluruhan). Saya tidak berpikir sistem build, apakah itu msbuild atau tidak, cara kerja dotnet build, dll. Berada dalam lingkup masalah _this_. Itu bukan untuk mengatakan bahwa diskusi tentang itu tidak disukai atau tidak valid, hanya saja mereka tidak termasuk dalam masalah _spesifik_ ini, melainkan mereka harus menjadi masalah yang terpisah. Seperti yang dapat dibuktikan oleh pengembang berpengalaman mana pun, sangat frustasi ketika laporan bug berisi banyak bug yang terpisah dan biasanya hal pertama yang Anda lakukan adalah membaginya menjadi beberapa masalah untuk dilacak - saya pikir itulah yang sebenarnya hilang di sini.

Dari perspektif _personal_ saya sendiri, saya tidak peduli apa sistem build itu atau bagaimana cara kerjanya. Saya tidak bermaksud agar terdengar bodoh atau meremehkan mereka yang melakukannya, maksud saya bahwa dari perspektif pengembang, saya hanya ingin tahu bahwa "dotnet build" mengeluarkan Majelis saya selama struktur proyek benar - sejauh ini seperti yang saya ketahui, dotnet build -> Proyek ->-> Perakitan. Satu-satunya hal yang benar-benar penting bagi saya, dan apa ruang lingkup diskusi ini (Dan saya pikir kita akhirnya sepakat di sini) adalah seperti apa proyek itu dan apa artinya bagi alur kerja harian saya.

Saya tidak ingin berurusan dengan penggabungan neraka hanya karena saya menambahkan file .cs, saya juga tidak ingin berurusan dengan file XML seribu baris hanya karena beberapa sistem yang _Saya tidak peduli_ bergantung padanya - saya tidak' t berpikir salah satu dari kita melakukannya dan itu telah menjadi momok pengembangan VS selama bertahun-tahun sekarang. Kami memiliki secercah harapan dengan format project.json seperti yang ada sekarang karena _jauh lebih baik_ daripada yang sebelumnya, jadi saya benar-benar mengerti dan mengerti mengapa emosi berubah begitu cepat hanya dengan petunjuk bahwa kami akan kembali ke "masa lalu yang buruk", tetapi pada saat yang sama perlu dinyatakan bahwa kita tidak boleh menipu diri sendiri - project.json hari ini sama sekali tidak _perfect_, ia memiliki serangkaian masalah sendiri dan meskipun mungkin kecil dibandingkan dengan masalah csproj "lama", ada baiknya bersikap objektif dan mendiskusikan di mana hal-hal dapat ditingkatkan dan apa yang bisa lebih baik.

Pasti ada kemungkinan _terbaik dari kedua dunia_.

Saya pikir diskusi inti di sini harus pada tata letak dan format .csproj "baru" dan apa yang terjadi pada project.json (Atau lebih spesifik, struktur "proyek" secara keseluruhan).

Anda tahu, itu telah disebutkan beberapa kali di utas ini, tetapi saya pikir saya akan menyebutkannya lagi, hanya untuk membagikan "aha pribadi" saya sendiri pagi ini, tetapi ada upaya lain yang sedang berjalan dengan Sistem Proyek berbasis Roslyn - atau untuk lebih akurat dari yang readme yang Sistem Proyek Central (CPS) . Menelusuri dokumentasinya, tampaknya lebih merupakan upaya definisi proyek daripada proses. Mungkin di sinilah semua keajaiban antara .json dan .csproj dikonsolidasikan? Dan kemudian MSBuild akan diturunkan sebagai titik akhir proses? Bukankah _itu_ menyenangkan. :senyum:

Bagaimanapun, saya sudah memulai/menonton repo itu untuk mulai mendapatkan pembaruan tentang apa yang terjadi di sana. :+1:

(Saya juga setengah bertanya-tanya apakah kita harus memindahkan diskusi ini ke masalah baru di sana.)

@neoKushan Jelas, fakta bahwa ada msbuild yang terlibat tidak bermasalah dengan sendirinya. Dan saya pikir ada jalan ke depan yang memungkinkan kita untuk menjaga format file sederhana yang dapat dibaca/diedit manusia sambil memanfaatkan kekuatan msbuild.

Yang membuat saya khawatir, adalah argumen seperti "msbuild telah diuji pertempuran", msbuild biasa tetapi xplat saat ini sepertinya tidak. Ketika kami melihat masalah pada repo github terkait, itu belum cukup. Selain itu, tim msbuild telah mengatakan bahwa mendukung format serialisasi baru/yang ditingkatkan tidak akan menjadi target untuk msbuild melainkan untuk sistem build baru (yang tidak akan terjadi dalam waktu dekat).

Saya juga khawatir ketika orang berasumsi bahwa yang kami lakukan hanyalah menambahkan penghapusan dependensi. Mungkin itu yang mereka lakukan karena mereka hanya membuat aplikasi 'hello worlds'. Tetapi opsi lain seperti buildOptions dan override oleh moniker sangat kuat dan praktis. Belum lagi pengalaman editor berbasis skema json saat ini luar biasa.

Salah satu jalurnya adalah memiliki tugas msbuild yang akan memuat project.json sebagai alternatif. Kemudian, biarkan pengembang memilih dalam pengaturan proyek jika mereka ingin mengaktifkan project.json yang akan menambahkan tugas itu ke csproj.

@Mike-EEE Ya ada harapan :)

Saya cukup yakin bahwa kecenderungan saat ini adalah membuat project.json menjadi nuget.json - yang diharapkan akan menyelesaikan masalah ketergantungan dan membiarkan sebagian besar fungsionalitas project.json yang ada tetap utuh.

Satu-satunya hal yang saya tidak tahu adalah bagaimana ini memengaruhi multitargeting, apakah csproj dan nuget.json harus menyadari dan memahami apa yang mereka targetkan masing-masing? Apakah kita berakhir dengan csproj untuk setiap target (yuck!), atau dapatkah mereka memperluas .csproj cukup untuk menjelaskannya?

project.json menjadi nuget.json

Hanya ingin tahu di sini ... di mana percakapan _this_ terjadi? Saya telah mendapatkan tim nuget sebelumnya untuk mengunci dengan format tertentu. Mengenai project.json mereka mengatakan bahwa itu adalah masalah perkakas Visual Studio dan sesuatu yang tidak dapat mereka atasi. Sekarang tampaknya dinamika telah berubah dan telah menyalin/menempel lebih banyak masalah yang sama. :stuck_out_tongue:

Untuk memperjelas kekhawatiran saya, kami sekarang mencampur JSON dan XML bersama-sama yang menghasilkan inefisiensi setidaknya.

Hanya ingin tahu di sini ... di mana percakapan ini terjadi?

Yah awalnya dinyatakan di sini: https://blogs.msdn.microsoft.com/webdev/2016/05/11/notes-from-the-asp-net-community-standup-may-10-2016/

Kemungkinan file project.json tetap ada, dan berisi semua referensi paket untuk NuGet dan diganti namanya menjadi nuget.json.

Dan saya pikir inilah yang sebenarnya dibahas di sini, berapa banyak yang Anda ambil dari project.json dan dimasukkan ke dalam .csproj? Dalam proyek saya, sebagian besar project.json telah menjadi referensi paket, terutama jika saya menargetkan beberapa kerangka kerja. Di atas menunjukkan bahwa semua ini akan tetap ada dan hanya bit "lainnya" yang akan dikeluarkan. Dalam pengalaman saya (sekali lagi: Pribadi), bit "lain" ini benar-benar tidak banyak berubah sepanjang umur proyek, jadi meskipun dalam XML, itu tidak banyak XML dan harus cukup statis ... satu harapan .

Saya setuju bahwa mencampur dan mencocokkan XML dan JSON untuk konfigurasi yang berbeda agak bau, tetapi kemudian saya agak bias terhadap JSON karena saya bukan penggemar berat cara penggunaannya. Itu pasti preferensi pribadi.

Yah itu awalnya dinyatakan di sini ...

Ah ya... tentu saja! OKE. Hanya memastikan. Semoga besok akan menjadi hari dimana kita akhirnya mendapatkan kejelasan (baik atau buruk!) seputar ini.

Saya setuju bahwa mencampur dan mencocokkan XML dan JSON untuk konfigurasi yang berbeda agak sedikit bau

Sangat senang saya bukan satu-satunya yang melihat ini dan merasa seperti ini. :) Tampaknya sepi di sana untuk sementara waktu ketika saya pertama kali berjuang melawan kesedihan melihat .JSON merayap ke dalam proyek. Benar-benar masuk akal dari latar belakang web-appdev, tetapi appdev asli tidak seperti itu, dan sebaliknya ketika datang ke XML.

Haha... ngomong-ngomong, menulis di atas membuatku mengeluarkan arsip lama. Inilah saya kembali pada tahun 2014 membuat kasus untuk (ya, Anda dapat menebaknya!) Xaml bukannya JSON hahaha oh lihat betapa muda dan naifnya saya dulu! Sangat lucu dan sederhana! Wah, apakah saya memiliki dunia untuk dipelajari. :stuck_out_tongue: Tapi, saya akan mengatakan bahwa ada beberapa kemajuan. Kami memang menyingkirkan .ini yang digunakan untuk konfigurasi server web . :senyum:

@neoKushan Pasti ada yang terbaik dari kedua kemungkinan dunia.

👯 👯 👯

@neoKushan Saya cukup yakin bahwa kecenderungan saat ini adalah membuat project.json menjadi nuget.json...Satu-satunya hal yang saya tidak tahu adalah bagaimana ini memengaruhi multitargeting, apakah csproj dan nuget.json harus menyadarinya dan memahami apa yang mereka targetkan masing-masing?

Menggunakan skema project.json sebagai titik awal, dari sudut pandang saya, item berikut mungkin _not_ berada dalam file definisi build:

• Daftar file sumber
• Ketergantungan proyek
• Kerangka target
• Perintah proyek (misalnya web, tes, dll)
• Akar web
• Metadata
• Versi bahasa

Berikut ini saya tidak _percaya_ harus ada dalam file definisi build, tetapi saya akan _meh_ tentang hal itu jika ada:

• Definisi konfigurasi
• Skrip, sebelum dan sesudah

Berikut ini mungkin _harus_ ada dalam file definisi build:

• Opsi kompilasi (tidak termasuk versi bahasa)

Di atas hanya untuk memancing diskusi. Senang memperdebatkan setiap poin individu. Sarankan untuk mengabaikan apa nama file dan formatnya untuk saat ini.

@shederman Apakah kita perlu mengklarifikasi apa yang Anda maksud dengan "membangun definisi"? Mungkin terminologi saya tidak aktif, tetapi saya tidak akan menyebut project.json saat ini sebagai file _build definition_ melainkan file _project definition_ (dan hal yang sama berlaku untuk file csproj baru). Mungkin semantik, tetapi bagi saya definisi build menyarankan itu mendefinisikan _bagaimana hal-hal dibangun_, sedangkan definisi proyek mendefinisikan apa yang membentuk sebuah proyek dan meninggalkan langkah-langkah pembangunan ke sesuatu yang lain.

_Ini adalah proyek saya, ini terdiri dari item-item ini dan memiliki dependensi ini. Bagaimana Anda membangunnya bukan urusan saya._

Banyak proyek dapat ditentukan hanya melalui konvensi, seperti bagaimana nama Majelis berasal dari folder tingkat atas. Mengikuti garis pemikiran ini, _nuget.json_ hanya akan ada hubungannya dengan nuget - jadi paket/dependensi akan masuk ke sana dan saya pikir kita semua senang dengan itu.

Yang tidak bisa saya putuskan adalah kerangka kerja target. Jika Nuget.json hanya peduli dengan resolusi ketergantungan, maka meskipun mungkin memiliki beberapa pemisahan untuk referensi ketika menargetkan kerangka kerja yang berbeda, saya tidak sepenuhnya yakin itu harus menjadi orang yang memutuskan kerangka kerja mana yang sebenarnya ditargetkan, itu tampaknya sesuatu yang lebih untuk _project definition_ (Apa pun yang akhirnya menjadi).

Kemudian lagi, ada lebih banyak nuget dari sekedar referensi paket, itu juga berisi paket _definition_ dan versi juga ketika perpustakaan Anda _menjadi_ paket nuget. Sepertinya nuget.json kemudian melakukan setidaknya dua hal berbeda dan itu mulai sedikit berbau. Mungkin (hanya meludah di sini), csproj akan mendefinisikan detail paket, kerangka kerja target, dll. dan setiap kerangka kerja target dapat menunjuk ke file .json, yang pada dasarnya adalah paket nuget. Dengan kata lain, alih-alih satu nuget.json, Anda akan memiliki file .json terpisah untuk setiap kerangka kerja. Itu mungkin ide yang buruk, saya belum terlalu memikirkannya.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ :

Kami memiliki dua pilihan. Salah satunya adalah memindahkan semua proyek .NET untuk menggunakan project.json. Ini akan mengharuskan kami melakukan pekerjaan perkakas yang menyentuh semua jenis proyek di Visual Studio, Xamarin dan mitra kami seperti Unity. Kami harus memperluas project.json untuk mendukung semua skenario pembangunan yang diperlukan oleh masing-masing jenis proyek ini dan menyediakan cerita migrasi . Pilihan lainnya adalah membangun jembatan sehingga proyek .xproj dapat mereferensikan proyek .csproj dan proyek .csproj dapat mereferensikan proyek .xproj di Visual Studio dan Xamarin Studio. Bridge juga memiliki tantangan, misalnya ketika pelanggan membuat proyek, mereka sekarang harus memilih .xproj atau .csproj, yang hanya menambah lebih banyak pilihan dan kerumitan.

Dan

Setelah melihat pilihan kami, ternyata akan lebih mudah untuk memindahkan proyek .NET Core ke .csproj/MSBuild sehingga semua proyek .NET menggunakan alat dan sistem pembangunan yang sama.

Kami berencana untuk meningkatkan .csproj untuk mendukung fungsionalitas yang hilang:

• Tidak ada daftar file dalam sistem proyek
• Alat CLI untuk melakukan operasi apa pun pada file proyek, untuk sebagian besar skenario Anda tidak akan mengedit file
• Bangun paket langsung dari proyek
• Multi-penargetan

Dan karena semua .NET menggunakan perkakas yang sama, kami kemudian dapat melihat peningkatan MSBuild. Kami akan meminta umpan balik dari pelanggan dan komunitas untuk mendukung JSON alih-alih XML, karena alat kami tidak menghasilkan file yang terlalu bertele-tele dan banyak lagi. Dan karena semuanya menggunakan alat yang sama, peningkatan ini dapat bekerja pada semua proyek .NET.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/#comment -71485:

Dengan asumsi bahwa .csproj masih berarti Proyek C#, tentu saja akan ada target lain untuk proyek non-C#, benar? [Ben]

Ya. [Scott H]

Saya agak takut bahwa .net akan terjebak dengan sistem pembangunan kompleks-legacy-justForTooling sebagai msbuild, mungkin kita harus mulai dengannya untuk menjalankan dotNetCore dan kemudian merencanakan sistem pembangunan modern yang baru?
Untuk memberikan harapan kepada setiap orang dan melakukan sesuatu tanpa terburu-buru mengirimkan .netcore.

Saya tidak sering perlu mengedit file msbuild, tetapi ketika saya membutuhkannya sangat sulit, pendekatan deklaratif membuat Anda tersesat, saya membawa contoh saya, sepertinya tidak ada yang bisa menyelesaikan masalah sederhana seperti ini https://github .com/madskristensen/BundlerMinifier/issues/89
Jika setelah 6 bulan tidak ada yang bisa menjalankan tugas (dua tugas berbeda masing-masing tidak mengetahui tentang yang lain) demi satu tanpa peretasan kotor atau dengan cara tambahan mungkin ada sesuatu untuk diperbaiki di sana.

Terima kasih

Alat CLI untuk melakukan operasi apa pun pada file proyek, untuk sebagian besar skenario Anda tidak akan mengedit file

:-1:

Saya mendukung alat CLI untuk membantu Anda melakukan pekerjaan Anda, tetapi jika saya _memiliki_ untuk menggunakan alat CLI untuk mengelola referensi dan paket, saya akan marah. Install-package itu hebat, tetapi bisa mengetikkan setengah dari nama paket dan membuatnya memunculkan daftar kemungkinan, dengan semua versinya, sungguh menakjubkan.

alat cli sangat bagus untuk otomatisasi tetapi cara yang buruk untuk melakukan tugas kecuali untuk yang dasar seperti npm install atau dotnet restore . Jika kita harus mempelajari hal-hal seperti dotnet buildoptions define add --framework net451 SOME_DEFINE pasti sangat menyebalkan. Ini adalah kerugian besar.

Sebuah cerita perkembangan yang baik adalah:

• Proyek yang mudah diedit dan buat file
• Sistem build yang dapat dikonfigurasi
• Alat cli yang sederhana, dirancang dengan baik, dan lengkap
• Gui Hebat, alat IDE

Membuat salah satu dari mereka yang miskin (yang sebenarnya hebat sebelumnya) untuk membuat yang lain dapat diterima adalah hal yang bodoh.

Argumen unity dan xamarin sebenarnya cukup buruk. Saya tidak berpikir mereka akan pindah ke .net core secepat itu, dan mundur untuk kenyamanan mereka hanya timpang ketika merancang untuk masa depan .net.

Dan karena semua .NET menggunakan alat yang sama, kami kemudian dapat melihat peningkatan MSBuild

Tidak ada MSBuild yang ditingkatkan sebelum kita dipaksa ke dalamnya...

Artikel ini sebenarnya bukan posting blog yang kita tunggu-tunggu dan ini menegaskan bahwa .net core sedang tersesat di sana.

cli tools bagus untuk otomatisasi tetapi cara yang buruk untuk melakukan tugas kecuali untuk yang dasar seperti npm install atau dotnet restore.

Sekali lagi saya merasa masalah ini adalah benturan budaya/preferensi/filsafat. Di suatu tempat di sepanjang jalan CLI menjadi ide yang baik untuk menggantikan GUI, ketika Anda benar-benar membutuhkan keduanya karena Anda akan menemukan pengembang (sekali lagi) memiliki preferensi pendekatan mereka. Beberapa inovasi tentu diperlukan di bidang ini, karena tampaknya selalu menjadi masalah: CLI dibuat, tetapi GUI tidak dan sebaliknya.

Bagi saya sepertinya semacam kerangka kerja diperlukan untuk membuat API dan kemudian versi CLI dan GUI dibuat secara otomatis untuk Anda.

Kita bisa menyebutnya... CLIGUIAPI! :+1: :+1: :+1: #masalah terpecahkan

masalah ini adalah benturan budaya/preferensi/filsafat

Jelas dan ini adalah salah satu yang tidak dapat Anda pecahkan kecuali untuk menangani setiap pendekatan dengan pendekatan terbaik. node.js dan saya bukan penggemar berat tumpukan ini melakukan pekerjaan yang baik dengan memiliki alat cli yang hebat npm dan package.json. Bagian Gui ditangani oleh berbagai vendor (webstorm, vs code, visual studio). Sistem build mewah seperti gulp seratus persen opsional.

mungkin saya minoritas dalam hal ini dan mungkin tidak, tetapi sementara saya menyukai project.json, alasannya dijelaskan di sini https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project -json/ sangat masuk akal bagi saya. Saya merasa cukup yakin bahwa kami akan berakhir dengan pengalaman yang baik jadi saya benar-benar tidak khawatir tentang ini dan itu tidak mengurangi antusiasme saya untuk kerangka kerja baru ini. Orang-orang tampaknya sangat cepat keluar dari garpu dan bertindak seolah-olah ini adalah akhir dunia bahkan sebelum melihat seperti apa pengalaman terakhirnya.

Saya sudah berhenti membaca beberapa waktu yang lalu, tetapi saya akan menutup masalah ini segera setelah kami memiliki jawaban pasti tentang project.json .

Bagaimana dengan menyimpan project.json dan .csproj, di mana .csproj dihasilkan oleh perintah dotnet restore dan tidak disinkronkan dalam kontrol versi secara default? Perbedaannya adalah, alih-alih dotnet restore menghasilkan "project.lock.json" (dan melakukan hal-hal lain), itu akan menghasilkan (atau memperbarui) file ".csproj". Bahkan "project.lock.json" dan ".csproj" dapat tetap ada karena keduanya dibuat secara otomatis. Bendera dapat digunakan di dotnet restore untuk menghasilkan .csproj. Dalam pengumumannya, Microsoft sudah mengatakan- "Alat CLI untuk melakukan operasi apa pun pada file proyek, untuk sebagian besar skenario Anda tidak akan mengedit file". IMHO, dotnet restore paling cocok untuk menjadi alat CLI ITU, yang akan menggunakan project.json sebagai input. Keuntungannya akan-

• Kedua format project.json dan .csproj dapat tetap tidak berubah. Itu berarti .csproj baru yang dihasilkan akan kompatibel dengan versi sebelumnya dari Visual studio dan alat lainnya. dotnet restore dapat menyisipkan daftar "termasuk" file proyek secara eksplisit dalam file .csproj.
• Karena .csproj dibuat secara otomatis dan tidak dalam kontrol versi, pengembang tidak harus berurusan dengan pengeditan tangan dan penggabungan .csproj.

Ya... tidak.

Penutupan. Segala sesuatu yang bisa dikatakan telah dikatakan.

Jika Anda ingin mengetahui bagaimana seharusnya dibuat dan berada di tim desain yang membicarakannya... silakan lakukan .

Jika tidak, itu akan membuang-buang ruang dan terutama... mengisi kotak masuk.

@MaximRouiller berharap Anda akan mengumpulkan komentar yang berfokus pada menjawab pertanyaan awal Anda meskipun jumlah kebisingan.

diposting kemarin:

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/

@neoKushan Apakah kita perlu mengklarifikasi apa yang Anda maksud dengan "membangun definisi"? Mungkin terminologi saya tidak aktif, tetapi saya tidak akan menyebut project.json saat ini sebagai file definisi build melainkan file definisi proyek (dan hal yang sama berlaku untuk file csproj baru). Mungkin semantik, tetapi bagi saya definisi build menyarankan itu mendefinisikan bagaimana sesuatu dibangun, sedangkan definisi proyek mendefinisikan apa yang membentuk sebuah proyek dan meninggalkan langkah-langkah membangun ke sesuatu yang lain.

Cukup banyak tempat di pemikiran saya. Definisi proyek akan menjadi deskripsi deklaratif murni tentang apa proyek itu. Metadata, versi, spesifikasi file, dll. Definisi build akan menjadi langkah-langkah yang dilakukan untuk mengubah proyek menjadi kode yang dapat dieksekusi. Definisi build hampir pasti membutuhkan sesuatu yang cukup kaya untuk mengekspresikannya, kode favorit saya.

Tapi, semuanya tampak diperdebatkan: @MaximRouiller dan MS telah menutup semuanya. Umpan balik Anda telah diabaikan dan dibunuh, terima kasih telah menelepon.

Secara keseluruhan, keseluruhan csproj -> project.json -> csproj adalah serangkaian keputusan buruk yang akan kembali menghantui MS dalam adopsi .NET IMHO. Tren pengembang yang meninggalkan .NET untuk padang rumput yang lebih hijau akan terus berlanjut.

Sangat sedih.

@shederman Tidak ada korelasi antara penurunan indeks Tiobe untuk C# dan keputusan untuk beralih kembali ke csproj. Penurunan indeks Tiobe juga bukan merupakan indikasi menurunnya kesehatan ekosistem C#. Lebih banyak bahasa yang memasuki pasar mempersulit satu bahasa untuk mempertahankan pangsa pasar yang besar.

Saya tidak jelas tentang dampaknya secara keseluruhan, tetapi saya akan menunjukkan bahwa harus ada pemisahan evaluasi kekhawatiran di sini. Jika csproj berarti hanya karena saya menambahkan file, rekan tim saya khawatir tentang dampak lain yang terkait dengan proses pembuatan, maka kita ketinggalan perahu.

csproj adalah sesuatu yang saya toleransi, bukan pilihan.

@jerometerry Saya tidak mengatakan ini sendiri akan menyebabkan penurunan. Tetapi banyak dari perubahan inovatif di .NET Core ditujukan untuk menahan penurunan, dan kerugian pada AWS. Perubahan ini perlahan-lahan dipahat satu per satu, dan dengan demikian .NET Core menjadi semakin tidak mungkin untuk menarik pengembang ke platform.

Selain itu, pengambilan keputusan yang buruk - yang dapat ditelusuri kembali ke keputusan untuk memperkenalkan project.json hingga hari ini bukanlah pertanda baik.

Jika MS bertekad untuk fokus pada masa lalu, mereka seharusnya tidak terkejut ketika mereka kalah di masa depan. Pemikiran yang membawa Anda ke dalam masalah tidak mungkin membuat Anda keluar darinya.

Lebih banyak bahasa yang memasuki pasar mempersulit satu bahasa untuk mempertahankan pangsa pasar yang besar.

Benar, tetapi menurut pengalaman saya, lebih banyak kerusakan daripada yang diperlukan di .NET disebabkan oleh friendly fire.

BTW... ada standupnya juga kemarin? Saya masuk ke live.asp.net tetapi hitungan mundur baru saja diatur ulang, tanpa video/umpan atau apa pun ...

@Mike-EEE Mereka mendengar Anda akan datang :stuck_out_tongue_winking_eye:

Frustrasi karena mereka melakukan ini. Saya membuat blog tentang itu: http://www.brettmorrison.com/microsofts-little-decision-is-a-big-mistake

Dari standup hari ini: https://youtu.be/YJsQ3tnS7Ew?t=38m45s

Dia secara khusus membahas project.json di sini: https://youtu.be/YJsQ3tnS7Ew?t=26m12s

Meskipun format project.json jauh lebih sederhana untuk diedit (kecuali Anda berada pada tahap .NET dev menjadi drag and drop dataset-monkey), masalah terbesar bagi saya adalah tidak ada yang mau repot-repot memperbarui perpustakaan mereka ke . inti bersih. Sejauh ini saya telah berhasil membuat satu cabang Restsharp berfungsi, tetapi ini menggunakan format project.json. JSON.NET, Structuremap, NUnit, dll., dll. semuanya memiliki cabang DNX basi di mana sepertinya para pengembang mengabaikan harapan.

Jadi agak aneh untuk menyebut .NET Core RC1/2 sebagai kandidat rilis ketika format proyek alat baris perintah dotnet sedang dihapus. Bagi saya itu masih perangkat lunak beta atau bahkan alfa karena masih eksperimental.

Motivasi utama saya untuk pindah ke vNext adalah menggunakan hosting Linux murah, dan Docker. Alat migrasi proyek ASAP akan bijaksana karena kebanyakan orang akan sepenuhnya dilumpuhkan oleh perpustakaan mereka melalui referensi nuget yang tidak memiliki versi .NET Core.

@yetanotherchris dnx adalah sebuah konsep di rc1, itu berubah menjadi dotnet cli di rc2, jadi sebagian besar proyek atau cabang dnx akan basi saat ini

project.json masih di sini dan diperlukan untuk rc2, diskusi tentangnya akan dihentikan di masa mendatang setelah RTM

json.net alias newtonsoft.json berfungsi dan digunakan oleh kerangka kerja itu sendiri, saya juga menggunakannya dalam proyek saya
nunit tidak kompatibel, semua orang menggunakan xunit afaik
structuremap memang memiliki dan perpustakaan yang kompatibel dengan rc2

masih ada banyak hal pihak ke-3 yang belum di-porting ke rc2, tetapi Microsoft tidak mengontrol waktu proyek lain dan kapan mereka akan membuat perpustakaan yang kompatibel

@yetanotherchris Jika Anda menggunakan impor di project.json Anda, Anda dapat menentukan moniker non-netstandard lama dan itu akan menggunakannya:

"frameworks": {
  "netcoreapp1.0": {
    "imports": [
      "dotnet5.6",
      "dnxcore50",
      "portable-net45+win8"
    ]
  }

Mungkin karena alasan ini tidak banyak orang yang repot-repot memperbarui perpustakaan mereka dulu, tidak perlu mencapai target bergerak lain sebelum RTM yang sebenarnya.

@joeaudette saya sedang berbicara tentang nama cabang (DNX) bukan alat baris perintah dotnet . Banyak orang menggunakan NUnit, ini adalah rangkaian pengujian de facto di luar MsTest. Saya tidak yakin dari mana Anda menemukan paket JSON.NET atau Structuremap, ada versi tidak resmi dari Structuremap yang disebut DNX dan cabang Newtonsoft di sini dan .NET Standard 1.0 beta di nuget.org (standar .net sekarang berlebihan sejauh yang aku tahu).

@neoKushan terima kasih, saya akan memeriksanya.

Saya pikir poin utama saya adalah agak konyol menyebutnya sebagai kandidat rilis karena akan benar-benar berubah untuk versi final. Mungkin dalam sebulan kita akan mendapatkan kesibukan aktivitas sekarang sistem build tidak sepenuhnya berbeda dari yang lama dan yang baru - meskipun sebagai seseorang yang terutama adalah pengembang web, saya lebih suka project.json .

@yetanotherchris

(Standar .net sekarang berlebihan sejauh yang saya tahu).

Apa yang membuatmu mengatakan itu? Netstandard tidak akan hilang dengan perubahan proyek, ini akan tetap ada. Anda akan dapat menargetkan standar bersih di file csproj Anda di masa mendatang. Netstandard sangat penting. Salah satu alasan utama mereka meninggalkan project.json adalah untuk menyatukan seluruh ekosistem .net dan itulah yang juga dibawa oleh netstandard.

Saya pikir poin utama saya adalah agak konyol menyebutnya sebagai kandidat rilis karena akan benar-benar berubah untuk versi final.

Saya setuju sampai batas tertentu dengan ini, meskipun saya tidak berpikir itu berubah sebanyak yang orang pikirkan. Sebagai permulaan, project.json masih akan ada di sini untuk RTM, semua perubahan akan terjadi setelah itu. Anda mungkin bertanya mengapa menyebutnya "Final" jika itu akan berubah dan mungkin ada benarnya di sana, tetapi pada akhirnya semua kode dan pustaka Anda dan semua yang tidak berubah, itu hanya proyek _definition_. Itu bukan perubahan besar seperti yang mungkin dipikirkan orang pada awalnya, meskipun pasti akan ada kesenangan migrasi yang bisa didapat.

@yetanotherchris Anda harus ingat bahwa rc2 adalah pratinjau dan Anda juga harus mencari paket pratinjau dari pihak ke-3
https://www.nuget.org/packages/Newtonsoft.Json/9.0.1-beta1
https://www.nuget.org/packages/StructureMap.Dnx/0.5.1-rc2-final

Saya tidak tahu tentang NUnit apakah itu akan didukung nanti tetapi untuk saat ini proyek .NET Core dan ASP.NET Core orang menggunakan xunit
https://xunit.github.io/docs/getting-started-dotnet-core.html

@yetanotherchris Saya pikir kita semua bisa setuju bahwa rc1 seharusnya diberi label beta9, rc2 adalah rilis kualitas rc nyata pertama
project.json dan alat semacam itu bukan bagian dari kerangka kerja itu sendiri, perkakas akan tetap dipratinjau dan dapat berubah untuk sementara waktu bahkan ketika kerangka kerja adalah RTM

Saya bahkan tidak akan terkejut jika kami bahkan membawa kembali- mungkin kami menyimpan project.json, dan itu hanya berfungsi dalam skenario terbatas. Jika itu yang diinginkan orang, kami akan mendukung gagasan itu.

Scott Hunter, dotnetConf 2016 Hari 1 Keynote 12m24s

Adakah yang tahu jika Tuan Hunter ada di GitHub? Dan memantau obrolan di forum produk? Dari suaranya, dia kehilangan umpan balik di sini.

Sebagai pengelola program untuk .NET dan Visual Studio, saya ragu @coolcsh sejujurnya punya waktu luang.

Saya akan sangat ngeri jika dia tidak menyadari umpan balik yang telah diberikan. Mungkin tidak semua detailnya, tetapi pasti ada dorongan balik yang signifikan.

Inilah kesempatan Anda semua orang:
https://blogs.msdn.microsoft.com/webdev/2016/06/08/notes-from-the-asp-net-community-standup-june-2-2016/

Saya memasukkan satu dolar ke dalam toples tip, sehingga untuk berbicara. :stuck_out_tongue:

tugberkugurlu mungkin telah melakukan sesuatu dengan komentar "tiba-tiba, pengembang perusahaan materi gelap mulai memberikan umpan balik di balik pintu tertutup". Cara lain yang dapat dikemukakan adalah, "pelanggan perusahaan kami mengemukakan beberapa kekhawatiran yang valid tentang kompatibilitas, dan investasi mereka saat ini dalam produk kami". Sementara 'komunitas' tampak tidak senang karena tidak menjadi bagian terbesar dari suara, yah, semuanya, pelanggan perusahaan membawa tongkat yang cukup besar: mereka membayar banyak uang untuk akses ke platform, peralatan, dan dukungan. Kekhawatiran mereka tidak akan diabaikan, juga tidak seharusnya. Pada akhirnya apa yang tampaknya diinginkan oleh MS adalah memungkinkan jumlah maksimum pengembang membangun apa yang ingin mereka bangun, dengan mudah, dan mereka juga ingin mencoba mengaktifkan interoperabilitas dan berbagi di hampir setiap domain yang dapat ditentukan. Mereka menjanjikan untuk membuat csproj menjadi lebih mudah untuk digunakan dan jauh lebih mampu. Jadi, sekarang, mereka siap untuk mewujudkannya.

Seperti yang telah saya katakan berkali-kali, saya adalah pengembang perusahaan di sebuah bank besar, pelanggan perusahaan. KAMI tidak berkonsultasi tentang perubahan ini. Jadi SIAPA sebenarnya "pengembang perusahaan materi gelap" itu? Informasi itu tampaknya sangat rahasia. 007 barang tingkat.

Ini semua baik dan baik menyatakan bahwa pelanggan perusahaan membawa tongkat besar, tapi ternyata hanya BEBERAPA dari mereka yang bisa melakukannya. Yang mana? Berdasarkan kriteria apa? Bagaimana kita masuk ke daftar istimewa itu? Mitra level berapa? Pengeluaran tahunan apa? Pikiran bertanya ingin tahu berapa PERSIS kita harus membayar MS sebelum mereka benar-benar mendengarkan pendapat kita?

@shederman apakah Anda pengembang seluler perusahaan, atau pengembang UWP perusahaan? Atau Pengembang Kesatuan Perusahaan?

Bukan dari salah satu di atas. Kami menulis sistem inti untuk manajemen aset dan integrasi bank. Beberapa barang online juga.

@shederman Saya curiga mungkin itu sebabnya Anda tidak ditanya?

Mohon klarifikasi?

Apakah Anda benar-benar mengatakan bahwa satu-satunya pengembang perusahaan yang sekarang didukung MS adalah mereka yang melakukan pekerjaan seluler untuk 1% pasar, aplikasi UWP untuk um, 5% pengguna yang peduli, dan pengembangan game? Dari seluruh spektrum pengembangan, MS memunggungi segalanya kecuali itu ?

um. Tidak.

Saya mengatakan bahwa perubahan terjadi setelah berbicara dengan grup _those_, jadi itu sebabnya Anda tidak ditanya. Microsoft harus mendukung semua pengembang mereka, bukan hanya pengembang asp.

Ya, jadi jika mereka ingin mendukung semua pengembang mereka, mungkin mereka harus berbicara dengan semua pengembang. Mungkin hanya berbicara dengan subset terpilih 5% dari pengembang perusahaan bukanlah cara yang baik untuk mengukur pendapat pengembang perusahaan secara keseluruhan.

Jadi, untuk mendengarkan pendapat bank besar, kita harus mengalihkan semua pengembangan kita ke UWP/Unity/Mobile?

Itu konyol.

mungkin mereka harus berbicara dengan semua pengembang.

Bukankah itu yang telah mereka lakukan selama 2+ tahun terakhir?

@shederman Jadi hanya karena

Juga, berhenti mengarang angka-angka – _itu_ konyol.

@poke Saya bertanya siapa yang terlibat? Saya mengatakan bahwa saya telah mendengar pengembang materi gelap perusahaan dikonsultasikan, dan menunjukkan bahwa saya di bank, dan kami tidak, jadi siapa sebenarnya?

Saya benar-benar berpikir jumlahnya cukup murah hati, tapi oke.

@shederman Saya pikir Anda terlalu banyak melihat semua ini. Fokus selama 2 tahun terakhir telah tepat di sisi asp.net, tetapi ketika kata .net core mulai menyebar, banyak orang mulai bertanya "Bagaimana saya bisa menggunakan ini?". Itu tidak beberapa kesepakatan ruang belakang, itu orang meminta harfiah tahun . Anda hanya perlu melihat- lihat untuk melihat banyak orang menginginkan lebih dari .net core.

Ada juga masalah permintaan dukungan perusahaan yang sebenarnya dari organisasi besar yang ingin tahu cara mem-porting barang-barang mereka yang ada menjadi lintas-plat - Anda mungkin tidak "Ditanyakan" karena Anda tidak memerlukan seseorang dari Microsoft untuk memberi tahu Anda bahwa apa Anda coba lakukan berada di luar cakupan proyek.

Cara lain untuk melihatnya - dan cara saya secara pribadi melihatnya - adalah Anda telah ditanya, Anda ditanya begitu pengumuman dibuat beberapa bulan yang lalu. Untuk semua tangisan orang yang mengatakan bahwa keputusan dibuat tanpa berkonsultasi dengan siapa pun, Microsoft telah berulang kali menyatakan bahwa mereka masih mengerjakan detailnya, bahwa mereka masih belum mengumpulkan bagian terakhir dan sekarang adalah waktunya untuk menyuarakan pendapat Anda . Scott Hunter bahkan mengatakan bahwa jika orang _benar-benar_ menginginkan project.json sebagai opsi, mereka akan mempertimbangkan untuk mempertahankannya. Tonton keynote dotnetconf jika Anda tidak percaya.

@neoKushan Saya menghargai bahwa Scott melangkah mundur sedikit dengan mengatakan bahwa mereka akan mempertimbangkan untuk mempertahankannya, tetapi benar-benar perlu ada satu titik terpusat bagi orang-orang untuk menyatakan bahwa inilah yang mereka inginkan jika tidak, masalah project.json akan terus bermunculan diskusi di mana-mana. Ini juga berarti bahwa ketika dibawa ke atas, semua orang dapat membalas dengan hal yang sama "hei, mereka akan mempertimbangkan untuk menyimpannya jika pengembang benar-benar menginginkannya, di sinilah Anda harus memberi tahu mereka".

project.json adalah langkah yang baik. Tapi itu naif menurut saya. Itu tidak memperhitungkan kesadaran bahwa orang ingin memiliki proyek hibrida yang ditulis dalam C++ atau F#. Beberapa keputusan desain awal mereka seperti dnx dan menggunakan nuget sebagai unit perakitan tidak layak untuk ekosistem dotnet secara keseluruhan. Apa yang Anda lihat adalah bahwa dalam proses membawa harmoni ke dotnet, mereka harus membuat pilihan sulit ini.

Forking dan Re-inventing menurut saya tidak akan membantu ekosistem dotnet, itu hanya akan merugikannya. Node and Go (terutama Go) sangat menarik bagi pemula karena mereka memiliki platform/alat yang homogen dan konsisten.

Saya menemukan seluruh argumen XML vs JSON konyol karena dalam 5 tahun lagi, itu akan menjadi JSON vs YAML dan setelah itu YAML vs Groovy (misalnya gradle). XML tidak seburuk yang Anda semua bayangkan. MSBuild sangat matang dan memiliki banyak investasi di dalamnya yang akan menguntungkan semua orang.

Yang mengatakan, BANYAK pekerjaan yang harus dilakukan dengan MSBuild untuk memastikan Anda bisa mendapatkan cara yang sama atau setidaknya cara yang tidak terlalu menyakitkan untuk menggunakan dan mengedit file csproj. Kemudian pindahkan dependensi nuget ke file nuget.json. Manfaatkan Convention over Configuration sehingga jika Anda berada di "jalur bahagia", csproj Anda akan hampir kosong, sedikit seperti web.config hari ini. dan kemudian memiliki opsi cli yang mengubah csproj

Bagi saya, saya akan melewatkan project.json tetapi bukan karena alasan yang Anda pikirkan.. Proyek C# akan baik-baik saja. Saya akan melewatkannya karena F# Saya lebih suka mengedit project.json untuk urutan kompilasi daripada mengedit msbuild. Sekali lagi bukan karena xml jahat tetapi karena file fsproj memiliki banyak kembung yang disebabkan oleh msbuild

Masalah saya dengan keputusan ini terutama adalah cara file csproj kurang tentang xml/json dan jauh lebih banyak tentang apa yang mereka pilih untuk disertakan dalam file csproj. Itu berisi definisi proyek, berisi pengaturan IDE, berisi langkah-langkah pembuatan, berisi referensi ...

Tidak banyak yang _tidak_ berakhir dalam hal itu. Ini membuatnya mengerikan dan hanya diperparah ketika harus berurusan dengan msbuild yang terkadang cukup misterius. Jika Anda benar-benar tertarik untuk membuat .NET Core bagus dan tidak hanya berfungsi, buat file proyek agnostik untuk membangun perkakas. Saya harus dapat menentukan apa proyek saya dan bergantung pada apa, terpisah dari cara membangunnya. Belum lagi ini mulai memungkinkan kita memilih perkakas, bahkan jika opsi awal baru saja didukung oleh msbuild sekarang.

Saya setuju dengan ini. Pada akhirnya, masalah utama dengan csproj adalah bahwa
itu melakukan segalanya.

Saya suka jalan tengah yang disarankan PatriotBob...

Pada Selasa, 21 Jun 2016 pukul 13:28 PatriotBob [email protected] menulis:

Masalah saya dengan keputusan ini terutama karena file csproj lebih sedikit
tentang xml/json dan lebih banyak lagi tentang apa yang mereka pilih untuk disertakan dalam csproj
mengajukan. Itu berisi definisi proyek, itu berisi pengaturan IDE, itu
berisi langkah-langkah membangun, itu berisi referensi ...

Tidak banyak yang _tidak_ berakhir dalam hal itu. Ini membuatnya
mengerikan dan hanya diperparah ketika harus berurusan dengan makhluk msbuild
cukup misterius di kali. Jika Anda jujur ​​tertarik untuk membuat .NET Core bagus
dan tidak hanya berfungsi membuat file proyek agnostik untuk membangun perkakas. saya harus
dapat menentukan apa proyek saya dan apa yang bergantung pada terpisah dari
bagaimana membangunnya. Belum lagi ini mulai memungkinkan kita memilih
perkakas, bahkan jika opsi awal baru saja didukung oleh msbuild sekarang.

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/aspnet/Home/issues/1433#issuecomment -227511911, atau bisukan
benang
https://github.com/notifications/unsubscribe/AKh-zsedLYg_PToadpD-_ewZPci0oHGCks5qOB8rgaJpZM4IcGCt
.

Seluruh XML buruk, JSON sangat bagus, kehebohan sangat berlebihan. Saya suka apa yang dikatakan PatriotBobo.

mengelola proyek as/w sepenuhnya dari npm 's package.json tidak pernah begitu sederhana dan ringkas mendeklarasikan proyek saya, membangun proyek saya, memutakhirkan proyek saya (misalnya greenkeeper), membaca/menulis/mengurai data tentang proyek saya, dan memublikasikan proyek saya dengan sangat mudah. _begitu mudah. seperti kebanyakan dari kita, riwayat saya ada di c++/Java/python/node, dengan play di yang lain. saya merindukan pengalaman npm di semua proyek saya sekarang.

project.json berjanji untuk menghasilkan karakteristik yang sama ini. Saya pikir ini adalah model yang patut ditiru, dan tidak mengorbankan kesederhanaan dan kekuatan.

jika tim .net inti tim berpikir solusi lain dapat memberikan sifat-sifat ini, sangat baik , dan kekuatan untuk mereka! namun, tolong jangan merusak keindahan dalam kesederhanaan saat Anda maju.

juga, saya mengerti bahwa saya hanya berisik pada titik ini di utas raksasa. mungkin moderator harus mempertimbangkan untuk menutupnya dan menangani cobaan dengan cara yang lebih terkendali. banyak umpan balik yang baik. mungkin sedikit trolling juga :$ :)