Runtime: Aturan keamanan warisan dilanggar menurut jenis: 'System.Net.Http.WebRequestHandler'. Tipe turunan harus cocok dengan aksesibilitas keamanan tipe dasar atau kurang dapat diakses.

Saya kebetulan melihat ini hari ini dari laporan lain. / cc @ChadNedNedNed

Sepertinya ini mungkin karena atribut keamanan yang hilang pada System.Net.Http.dll out-of-band dibandingkan dengan kotak masuk System.Net.Http.dll. Versi kotak masuk memiliki AllowP PartiallyTrustedCallers. Begitu juga dengan kotak masuk System.Net.Http.WebRequest.dll. Ini berarti semuanya diperlakukan sebagai SecurityTransparent kecuali dijelaskan sebaliknya.

OOB System.Net.Http.dll tidak memiliki AllowP PartiallyTrustedCallers, yang membuat semuanya penting bagi keamanan. Sekarang ketika kotak masuk WebRequest.dll memuat OOB System.Net.Http.dll itu melanggar aturan keamanan, karena WebReqeuestHandler transparan, tetapi HttpClientHandler yang berasal darinya sangat penting.

Repro saya:

1. File> aplikasi desktop baru
2. Properti proyek> penandatanganan> aktifkan penandatanganan nama kuat
3. Tambahkan referensi ke System.Net.Http.WebRequest
4. Instal System.Net.Http 4.1.0.
5. Pada dasarnya, panggil saja WebRequestHandler () baru;

ericstj benar, saya punya masalah yang sama di sini. Ini adalah masalah kritis pada System.Net.Http 4.1.0 yang harus diperbaiki. Saya tidak dapat menggunakan pustaka ini dengan .net4.6.1 karena tidak memiliki konsistensi.

Masalah ini sangat menyebalkan untuk ditangani, dan khususnya membuat penggunaan klien Azure KeyVault menyakitkan bagi tim saya. Satu-satunya alternatif yang tidak menyakitkan adalah menurunkan versi ke .NET 4.5.2, yang tidak dapat diterima.

Selain itu, solusi yang tercantum sebelumnya tidak cukup. Jika Anda ingin menggunakan NET 4.6.x, apa yang kami temukan adalah Anda harus melakukan hal berikut agar dapat bekerja dengan andal: nonaktifkan pemeriksaan ketergantungan, downgrade System.Net.Http, edit CSPROJ dan nonaktifkan pengalihan pengikatan otomatis, modifikasi app.config, dan biasanya membersihkan / keluar VS / dan membangun kembali seperti yang sering saya lihat System.Net.Http sedang digunakan, bahkan untuk proyek sepele. Berikut prosedur yang dapat diandalkan untuk memperbaikinya.

1. Klik kanan proyek di Visual Studio dan pilih Kelola Paket NuGet.
2. Buka tab Terpasang.
3. Gulir ke bawah ke SYSTEM.Net.Http - bukan Microsoft.Net.Http.
4. Di panel kanan, jika Terpasang bukan 4.0.0.0, maka setel Versi ke 4.0.0.0.
5. Di panel kanan, setel perilaku Ketergantungan ke Abaikan Ketergantungan. Jika Anda TIDAK melakukan ini, paket Microsoft.IdentityModel.Clients.ActiveDirectory akan diturunkan secara substansial, yang mana TIDAK benar.
6. Klik Perbarui - tombol ini harus benar-benar berlabel "Ubah Ke Versi".
7. Di jendela Pratinjau, verifikasi bahwa HANYA perubahan yang tercantum adalah "Menginstal System.Net.Http". Jika Anda lupa menyetel perilaku Ketergantungan dengan benar, perubahan tambahan akan dicantumkan di sini.
8. Klik OK / Yes / I Agree pada dialog konfirmasi dan tunggu prosesnya selesai. Setelah selesai, daftar paket akan menampilkan dua nomor versi - tanda centang di sebelah nomor yang sedang digunakan.
9. Pada tab Terpasang NuGet, pilih daftar untuk Microsoft.IdentityModel.Clients.ActiveDirectory.
10. Di panel detail sebelah kanan, setel perilaku Ketergantungan ke "Abaikan". Jika Anda tidak melakukan ini, setiap penambahan NuGet berikutnya akan gagal saat validasi NuGet untuk paket ini berjalan.
11. Di Visual Studio, pilih File | Save All.
12. Buka file CSPROJ untuk proyek ini di editor teks.
13. Di / Project / PropertyGroup * 1 (elemen PropertyGroup pertama dari Project), tambahkan baris berikut, atau ubah nilai elemen ini jika sudah ada:
    <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
14. Simpan file, lalu muat ulang proyek di Visual Studio.
15. Buka file app.config untuk proyek ini.
16. Temukan baris untuk System.Net.Http dan edit untuk mengarahkannya ke 4.0.0.0, bukan 4.1.0.0. Jadi temukan ini:

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" /> 
</dependentAssembly> 

Dan ubah menjadi ini:

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.0.0.0" /> 
</dependentAssembly> 

1. Buat ulang proyek. Jika Anda mendapatkan pengecualian saat menjalankan kode Azure Key Vault, satu atau beberapa file * .config di bin / debug atau direktori serupa belum diperbarui. Anda mungkin harus keluar dari Visual Studio untuk menghapusnya dan membangun kembali.

dluxfordhpf, terima kasih atas waktu Anda menjelaskan bagaimana Anda menyelesaikannya. Mengalihkan ke System.Net.Http 4.0 bekerja untuk saya di .net4.6.1, Tetapi masih sangat sulit untuk dipertahankan (ketergantungan nuget). Nantikan versi yang akan memperbaikinya.

Pengalihan dapat menyebabkan masalah jika orang menggunakan salah satu API baru yang ditambahkan di System.Net.Http 4.1.0.

khususnya membuat penggunaan klien Azure KeyVault menyakitkan bagi tim saya

@ChadNedzlek memiliki masalah yang sama dan dapat mengatasinya dengan meneruskan HttpClient yang dia buat sendiri ke konstruktor KeyVaultClient. Jika Anda tidak menggunakan WebRequestHandler, Anda akan terhindar dari masalah.

MISALNYA:

c# var handler = new HttpClientHandler(); // configure handler // eg: handler.ServerCertificateCustomValidationCallback = (message, cert, chain, errors) => errors == SslPolicyErrors.None; var client = new HttpClient(handler); var kvclient = new KeyVaultClient(async (authority, resource, scope) => "foo", client);

@davidsh Saya pikir Anda harus mengembalikan AllowPartiallyTrustedCallers pada System.Net.Http.dll. / cc @morganbr

@dluxfordhpf Terima kasih banyak atas langkah-langkahnya.
Ini bersifat sementara dan kami berharap segera diperbaiki, tetapi saya tetap dapat terus mengerjakan proyek ini!

@terrajobst Ini adalah masalah produksi yang memblokir. Ada ide kapan kita bisa memperbaiki NuGet? Terima kasih!

Baru saja mengalami ini sendiri. Akan luar biasa jika kita tidak jatuh ke neraka ketergantungan di .Net. Itu menuju ke sana.

EDIT: Diperbaiki dengan saran komentar sebelumnya untuk menggunakan sistem httpclient ??
new KeyVaultClient(GetAccessToken, new HttpClient(new HttpClientHandler()))
Itu sepertinya mengerti ...

Masalahnya hanya menjadi lebih buruk karena semakin banyak paket nuget dari Microsoft yang bergantung pada versi terbaru System.Net.Http. Saya mungkin bukan satu-satunya yang terus mengupgrade paket Microsoft nuget-nya ke versi pra-rilis terbaru. Misalnya paket yang tidak lagi berfungsi untuk saya di versi terbaru mereka:

Microsoft.IdentityModel.Clients.ActiveDirectory
Microsoft.TeamFoundationServer.Client
Microsoft.VisualStudio.Services.Client.
....

Saya masih tidak mengerti mengapa paket ini masih tersedia. @terrajobst @coolcsh bisakah kita menghapus / memperbaiki paket ini? Ini BENAR-BENAR menyebabkan masalah dengan lingkungan aplikasi yang kompleks. Membuang waktu beberapa jam mencoba untuk menjaga paket yang mengganggu agar tidak menyusup ke dalam build. Terima kasih!

Kami sedang melihat pengikatan ke System.Net.Http di NET Framework alih-alih hal yang rusak ini dari NuGet. Saya setuju, masalah ini konyol, dan sangat mahal untuk ditangani karena Anda harus menyinkronkan versi NuGet antar proyek, mencegah pembaruan pengikatan otomatis, dan memperbaiki / memeriksa app.config Anda. Yang mengejutkan saya adalah bahwa ini adalah perakitan yang banyak digunakan. Mungkin MS tidak terlalu peduli dengan KeyVault?

Ini juga digunakan oleh ActiveDirectory Nugget

Saya telah mengembalikan beberapa pustaka dari menargetkan .NET Standard karena ini dan masalah terkait di mana paket NuGet yang rusak hanya mengacaukan aplikasi yang menargetkan .NET Standard. Ini adalah keadaan yang menyedihkan.

Terima kasih telah mengajukan. Kami sedang menyelidiki ini secara aktif. Tetap disini.

Ini telah menjadi masalah yang signifikan bagi saya; kami menggunakan banyak paket nuget kami sendiri secara internal. Dan tampaknya nuget _tidak akan_ membiarkan bindingRedirect s itu saja. Setiap kali kita memperbarui salah satu paket internal kita, itu mengubah pengalihan kembali ke newVersion="4.1.0.0" . Adakah cara untuk menghentikannya dari melakukan itu, atau adakah perbaikan di cakrawala?

Ditemui saat menjalankan aplikasi melalui HTTPS, yang berfungsi dengan baik melalui HTTP. Tidak yakin apakah ada perbedaan signifikan lainnya.
Solusi untuk menyetel newversion="4.0.0.0" berhasil untuk saya.

Masih masalah di NETStandard 1.6.1. Mengapa?!

System.Net.Http 4.3.0 keluar. Seseorang mencoba?

@LoulG Ya, masih ada masalah yang saya khawatirkan.

Saya berbicara dengan @terrajobst di Twitter, dan dia mengatakan ini sebenarnya masalah yang lebih besar, dan mereka memiliki 10 orang yang mengerjakannya sekarang. Saya pribadi tidak yakin mengapa mereka tidak menarik versi paket ini yang menampilkan masalah, karena saya pikir untuk itulah manajemen paket. Tapi selanjutnya yang bisa kita lakukan pada saat ini adalah menunggu.

@LoulG sama di sini, saya telah memperbarui semua Paket Nuget saya, dengan rilis .net core 1.1 dan saya mendapat masalah ini

System.TypeLoadException: Aturan keamanan warisan dilanggar menurut jenis: 'System.Net.Http.WebRequestHandler'. Tipe turunan harus cocok dengan aksesibilitas keamanan tipe dasar atau kurang dapat diakses.

Pertama, saya pikir itu karena IdentityServer / IdentityServer3.AccessTokenValidation tetapi, dengan membaca masalah ini saya memahami situasi saya t_t, saya menghabiskan beberapa jam untuk mencoba menyelesaikannya

EDIT:
YA TUHAN,
Solusi dari pengaturan newversion = "4.0.0.0" juga berhasil untuk saya

Saya mencoba memperbarui ke 4.3 tetapi, masalah yang sama: (((

masalah yang sama di sini setelah meningkatkan

Masalah masih ada dengan 4.3.0.

@terrajobst dapatkah Anda memberikan pembaruan apa pun tentang masalah ini atau wawasan lebih lanjut tentang masalah lebih dalam yang dirujuk @robertmclaws ?

Ada alasan mengapa perbaikan ini berfungsi secara lokal, tetapi ketika diterapkan ke Layanan Cloud Azure, kesalahan tetap ada?

Terkadang memaketkan Azure dapat mengacaukan pengalihan pengikatan Anda, coba buka ritsleting cspkg dan lihat apa yang sebenarnya sedang diterapkan.

Ini adalah versi System.Net.Http.dll

Saya telah mengerjakan ini selama beberapa hari sekarang. Sangat senang menemukan perbaikan ini dan menangis saat menyebarkan ke Azure.

Bagaimana dengan file .config yang berisi pengalihan yang mengikat untuk proyek tersebut? Saya benar-benar mengharapkannya untuk tetap menerapkan versi perakitan yang rusak karena CopyLocal menjadi true dari paket nuget, tetapi pengalihan yang mengikat harus memastikan bahwa versi kerangka perakitan malah dimuat di dalam VM layanan cloud.

Ini!!! WTH?

<dependentAssembly> <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" /> </dependentAssembly>

Melihat kembali ke proyek saya, web.config juga telah kembali. Saya harus mengambil ini lagi besok pagi. Terima kasih untuk beberapa petunjuk!

Saya menemukan bahwa jika Anda menggunakan AutoGenerateBindingRedirects dan kemudian memodifikasi paket nuget apa pun untuk proyek tersebut, ini akan "memperbaiki" pengalihan yang sebelumnya dimodifikasi secara manual kembali ke versi yang rusak. Sangat membuat frustasi.

Tetapi sebagian dari masalahnya adalah, jika Anda TIDAK menggunakan AutoGenerateBindingRedirects saat Anda menambahkan paket baru, Anda mungkin mengalami masalah lain juga.

Saya telah berurusan dengan omong kosong ini selama lebih dari seminggu sekarang ketika harus menerapkan versi baru aplikasi kami. Yang terbaik yang bisa saya sarankan adalah biasakan memeriksa web.config Anda setiap kali Anda menerapkan.

Ya, Anda harus menonaktifkan pembaruan pengikatan melalui edit tangan di CSPROJ, dan kemudian memperbaiki pengalihan pengikatan .config, DAN mengkonfigurasi ulang NuGet di GUI untuk TIDAK memperbarui dependensi, dan KEMUDIAN Anda baik-baik saja. Ya, ini adalah PITA utama, saya terkejut sudah lama diproduksi. Tim saya telah mengutuknya secara teratur selama berbulan-bulan sekarang.

Sayangnya mengikuti hal di atas masih hanya memperbaiki lingkungan pengembang saya dan bukan prod biru. Saya memeriksa file pub terbaru dan web.config sudah diatur dengan benar bersama dengan dll saya yang diterbitkan menjadi versi yang digambarkan di atas. Sayangnya, masalah saya berkaitan dengan pustaka Pencarian Azure, jadi perbaikan ini terbukti menjanjikan. Ada ide lain di luar sana? Sedikit merugi. Terima kasih untuk bantuannya.

Mengapa ini lebih dari 2 bulan? Ini adalah masalah besar. Tolong perbaiki.

Ini benar-benar masalah stop-kapal, itu benar-benar perlu ditangani.

Demi f # $ @, perbaiki ini sudah. Ini kebodohan.

@suprduprmn Saya memperbarui dan mengkonsolidasi semua paket dan kemudian mengubahnya di semua file app.config dan web.config:

<bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.0.0.0" />

Hanya dengan begitu aplikasi web saya akan diluncurkan di Azure dan dapat melakukan panggilan https ke layanan Azure yang bergantung pada System.Net.Http. YMMV tapi semoga berhasil.

Dan @terrajobst ... adakah tempat yang layak di mana saya dapat secara resmi mengeluh karena mengabaikan masalah besar seperti ini? Aturan open source yang happy-go-lucky tidak berlaku di sini. Ini adalah barang Microsoft Showstopper 101 sekitar tahun 1995. Tidak mungkin "komunitas" dapat membantu. Anda harus memperbaikinya dan Anda harus menggunakan alat dan proses arsitek untuk memastikannya berhenti terjadi. Saya melihat hal-hal seperti ini di beberapa proyek Microsoft dan itu sama sekali tidak dapat diterima. Jelas ada celah besar dalam pengujian. Skenario dasar tidak perlu menginstal atau membangun bersih apalagi berfungsi dengan baik pada waktu proses.

Saya ingin meminta maaf atas waktu yang lama bagi XXXL untuk menanggapi masalah ini. Sudah 1 bulan sejak tanggapan terakhir dan masalah dibuka selama lebih dari 3 bulan. Saya setuju bahwa ini tidak dapat diterima untuk masalah berdampak tinggi seperti ini.

Itu menjadi perhatian saya pagi ini dan saya mencoba melakukan penggalian sejarah selama beberapa jam terakhir. Kabar baiknya adalah bahwa orang yang tepat sedang menyelidiki masalah ini selama beberapa minggu terakhir (mungkin lebih lama lagi, saya tidak memeriksa semua riwayatnya). Sayangnya, solusinya sangat rumit :( dan itulah mengapa kami belum memiliki jawaban atau ETA yang baik (meskipun itu bukan alasan kurangnya pembaruan dari pihak kami).
Ada beberapa solusi potensial, tetapi bahkan para ahli belum sepakat dan ada kerugian untuk masing-masing solusi tersebut.
Kami akan memulai sinkronisasi harian tentang masalah ini minggu depan, mencoba mendapatkan solusi untuk masalah tersebut secepat mungkin. Saya akan memposting pembaruan (mudah-mudahan dengan lebih banyak detail teknis) ketika kami memilikinya, setidaknya setiap minggu.

Sayangnya, inilah yang terbaik yang dapat saya lakukan pada saat ini (yaitu permintaan maaf yang tulus dan jaminan kami dan akan memperlakukannya dengan serius dan melakukan yang terbaik untuk memperbaikinya secepat mungkin). Jika ada yang punya saran alternatif, saya mendengarkan.

@ Karelz Saya tidak ingin mengalihkan tim dari benar-benar memperbaiki masalah sekarang, tetapi secara pribadi saya ingin mendengar analisis post-mortem tentang akar penyebab masalah ini dan bagaimana hal itu berhasil melalui QA. Hal ini menyebabkan sakit kepala besar dan saya pikir transparansi akan mendapatkan kepercayaan.

@jahmai Mengerti, saya juga tertarik dengan itu, tapi saya ingin fokus pada solusi dulu. Kemudian kita dapat menganalisis apa yang terjadi mengapa dan bagaimana mencegah kecelakaan seperti itu di masa depan.

Terima kasih atas tanggapannya. Saya pikir solusi terbaik saat ini adalah menonaktifkan paket apa pun yang tidak mengarah kembali ke System.Net.Http 4.0.0. Setidaknya ada 2 versi paket yang buruk. Bukankah itu tujuan pertama mendistribusikan barang-barang ini melalui NuGet?

pelukan @ ms-team

Selain itu, sebagai informasi saja, di antara masalah ini, masalah di sekitar HttpClient dirancang dengan sangat buruk, masalah seputar Microsoft.Security.Owin.Jwt rusak terhadap dependensi saat ini, dan status .NET Core ...

Ini adalah waktu yang sangat membuat frustrasi menjadi pengembang .NET sekarang. Setiap penerapan sekarang membutuhkan waktu 30 menit untuk memeriksa referensi pengikatan perakitan sehingga aplikasi saya tidak rusak dalam produksi. Ini bukan Microsoft yang saya perjuangkan begitu lama. Aku sayang kalian, dan aku sama sekali tidak ingin bersikap kasar ... Tapi rasanya seperti cinta yang kuat dibutuhkan untuk memulihkan kualitas status-quo.

Apapun yang harus dilakukan. Bahkan jika itu berarti mengirimkan 4.3.1 yang mereferensikan paket 4.0 lama. Tolong, lakukan segera.

Terima kasih teman-teman. FWIW, jika Anda perlu melakukan perubahan besar, lakukanlah. Kami tidak menyukai ini, tetapi kami telah hidup dengan rasa sakit selama beberapa bulan, dan sekarang setelah kami tahu Anda bertunangan, kami dapat menunggu beberapa saat lagi, bahkan jika kami harus membuat beberapa perubahan API.

Ada sesuatu yang tidak beres di sini. Saya telah mengirimkan aplikasi C # selama 15 tahun. Ironisnya karena abstraksi tingkat tinggi sedang dikirim oleh Microsoft, saya menghabiskan lebih banyak waktu untuk menggali lebih dalam ke internal yang sebelumnya tidak pernah saya khawatirkan. KAMU MELAKUKANNYA DENGAN SALAH.

Saya tidak cukup pintar untuk memahami mengapa mengembalikan bendera kepercayaan di perpustakaan ini adalah masalah besar dan saya juga tidak mengerti mengapa saya tidak memiliki kendali lebih atas itu dari aplikasi saya.

Jika saya ingin terkejut saat runtime oleh pustaka acak dan kesalahan yang disebabkan manajemen paket yang tidak ditangkap oleh compiler, saya akan menulis aplikasi saya di Ruby.

Pembaruan cepat:
Kami telah bertemu beberapa kali minggu ini. Kami bertukar pikiran tentang opsi dan menemukan pendanaan.
@CIPop sedang menangani masalah ini sebagai prioritas utama (pekerjaan dialihkan dari @davidsh yang akan menjadi OOF mulai minggu depan selama sisa tahun ini).

Status:

• Kami dapat mereproduksi repro asli @onovotny dan membuat repro kecil.
• Kami mengejar solusi [3] di bawah ini - memfokuskan pertanyaan terbuka yang tersisa, yaitu memvalidasi kelayakan teknis dari opsi tersebut.
• Kami mencari solusi paralel [2] di bawah ini - mencari pertanyaan terbukanya, yaitu menilai dampak solusi terhadap ekosistem.

Deskripsi masalah

• Kami mengirimkan System.Net.Http 4.3.0.0 "OOB" pada bulan Juni
  
  
  
  • Konten penting (untuk konteks ini): HttpCient, HttpClientHandler
  
  
  • Nilai pelanggan: Dukungan sertifikat, dukungan http2, tumpukan WinHttp di Desktop
  
  
  • Semua platform kecuali Desktop berfungsi dengan baik - untuk Desktop, permukaan API tidak memiliki SecurityAttributes untuk kode PartialTrust (APTCA = AllowP PartialTrustCodeAttribute)
  
  
  • Di Desktop, pustaka OOB mengesampingkan penggunaan System.Net.Http 4.0.0.0 yang merupakan bagian dari platform (dan memiliki APTCA)
  
  
• System.Net.WebRequestHandler 4.0.0.0 adalah bagian dari Desktop
  
  
  
  • Itu tergantung pada System.Net.Http dan memiliki APTCA, oleh karena itu membutuhkan System.Net.Http untuk memiliki APTCA
  
  
  • Ini menggunakan tipe internal dari System.Net.Http (yang memiliki InternalsVisibleTo)
  
  
  • Ini jenis warisan yang "membosankan" yang tidak kami inginkan di .NET Core
  
  
• Ada pustaka (paket 3+ NuGet dan aplikasi ASP.NET Core di Desktop) yang akan membawa (secara tidak langsung) OOB System.Net.Http 4.3.0.0 dan referensi ke System.Net.WebRequestHandler 4.0.0.0. Kombo mencegah aplikasi berjalan.

Solusi

1. [TIDAK DAPAT DITERIMA] Pengalihan pengikatan manual - Penurunan versi secara manual per aplikasi (melalui pengalihan pengikatan) System.Net.Http 4.3.0.0 ke 4.0.0.0 - sulit untuk memahami apa / di mana dan ini merupakan langkah manual per aplikasi
   
   
   
   • Catatan: Digunakan hari ini sebagai "solusi"
   
   
2. [CANDIDATE] Urungkan keputusan OOB - kirim ulang 4.3.1.0 sebagai pengalihan ke inbox Desktop 4.0.0.0.
   
   
   
   • Kelemahan: Kami akan merusak pelanggan yang bergantung pada fungsi baru
   
   
   • Pertanyaan terbuka: Akankah WCF atau pustaka NuGet di Desktop terpengaruh?
   
   
3. [CANDIDATE] Taburkan atribut Keamanan di System.Net.Http
   
   
   
   • Lakukan hanya untuk Desktop (gunakan #if), jangan menyebarkannya ke paket lain (kompilasi dengan referensi Desktop), tambahkan tes yang memaksanya untuk masa depan.
   
   
   • Kelemahan: Beberapa properti WebRequestHandler khusus untuk implementasi Desktop System.Net.Http tidak akan berfungsi (sesuai desain saat kami mengalihkan implementasi)
   
   
   • Catatan teknis: Metode asinkron harus SecurityTransparent (Batasan kompilator Roslyn), oleh karena itu metode tersebut tidak dapat memanggil (SecurityCritical) PInvokes - untuk setiap panggilan PInvoke tersebut harus ada metode pembungkus SecuritySafeCritical (agak jelek, tetapi langsung)
   
   
   • Pertanyaan terbuka: Bisakah kita membuat dependensi internal WebRequestHandler bekerja dengan System.Net.Http berbasis WinHttp baru?
   
   
4. [DITOLAK] OOB WebRequestHandler hanya di Desktop
   
   
   
   • Kelemahan: Mendorong masalah ke atas (beberapa perakitan APTCA bergantung padanya)
   
   
   • Kelemahan: Beberapa properti WebRequestHandler khusus untuk implementasi Desktop System.Net.Http tidak akan berfungsi (sesuai desain) - lihat [3] di atas
   
   
   • Kelemahan: Setiap orang harus menambahkan dependensi, atau memberi tahu NuGet untuk menginstal terbaru
   
   
5. [CANDIDATE] Bundel System.Net.WebRequestHandler.dll ke dalam paket System.Net.Http NuGet
   
   
   
   • 2 kelemahan sama seperti pada [4] di atas:
     
     
     
     
     
     1. Kelemahan: Mendorong masalah ke atas (beberapa perakitan APTCA bergantung padanya)
     
     
     
     2. Kelemahan: Beberapa properti WebRequestHandler khusus untuk implementasi Desktop System.Net.Http tidak akan berfungsi (sesuai desain) - lihat [3] di atas
     
     
     
   
   

Terima kasih atas info detailnya, kami menghargainya.

Bagaimana dengan kombinasi Opsi 2 dan pengiriman ulang 4.3 sebagai 5.0? Karena ini secara teknis merupakan perubahan yang merusak, Anda kemudian dapat mengirimkan OOB WebRequestHandler.dll untuk desktop sebagai v5.0 juga. Itu akan memungkinkan Anda mengimplementasikan kembali fungsionalitas di WinHttp, menghentikan properti yang tidak dipetakan, dan memberi semua orang jalan ke depan dengan cara yang semestinya diizinkan oleh SemVer. Upstream masih perlu memperbaiki kodenya juga, tetapi itu tidak terduga dalam rilis mayor, dan mereka juga dapat membatasi paket mereka untuk tidak menyertakan 5.0.

Maksud saya, saya mendapatkan ide untuk mengirim seluruh kelompok paket kerangka kerja dengan nomor versi yang sama, tetapi a) anjing itu sudah kacau ketika kalian mengirimkan semuanya sebagai 4.0 daripada mengikuti versi Desktop yang ada, dan b) yang sebenarnya perakitan versi sudah ada di semua tempat (System.Security.Claims 4.3 paket dikirimkan 4.0.2 dll, yang sangat mengganggu ketika harus membangun pengalihan yang mengikat). Jadi kerusakan sudah terjadi.

dotnet / corefx # 3 sepertinya satu-satunya solusi penyebab utama bagi saya.

@robertmclaws Kami tidak berpikir bahwa perubahan versi akan membuat perbedaan. Kebanyakan orang (pemilik aplikasi dan perpustakaan) biasanya hanya "menekan upgrade ke terbaru" pada paket mereka, mereka tidak peduli seberapa banyak versi berubah (minor vs. mayor). Jadi dampak kerusakannya akan persis sama.
Bahkan lebih buruk lagi bahwa efek "menghancurkan" hanya akan terlihat ketika Anda menggabungkan banyak hal. Itulah mengapa masalah ini lolos sejak awal - kami tidak memiliki pengujian untuk kombo itu (dan saya berpendapat tidak apa-apa - seseorang tidak dapat menguji semua kombinasi, tetapi kita dapat membahasnya dalam post-mortem nanti).

Saya tidak berpikir ada yang terlalu peduli tentang versi grup kerangka kerja secara keseluruhan. Sejujurnya, jika saya yakin ini akan membantu sebagian besar pelanggan, saya akan memilih hanya mengubah angkanya - saya hanya tidak percaya itu akan membantu hampir sama sekali. Itu hanya akan mengubah pesan kami menjadi "ya, Anda rusak - itulah yang dikatakan versi, Anda hanya tidak menyadari hal-hal apa yang Anda setujui saat mengambil versi", yang merupakan alasan IMO yang lemah.

Mengingat perbedaan pendapat, saya tertarik dengan apa yang dipikirkan orang lain: silakan gunakan suara positif / suara negatif pada posting ini:

• 👍 jika Anda setuju dengan saya, yaitu menurut Anda mengirimkan perubahan yang melanggar sebagai 5.0 tidak akan membuat perbedaan dan kebanyakan orang masih akan rusak, bingung, dan terpengaruh.
• 👎 jika Anda setuju dengan proposal @robertmclaws , yaitu menurut Anda mengirimkan perubahan yang melanggar sebagai 5.0 akan membantu orang memahami di awal bahwa mereka lebih baik menjauh dari paket, karena akan merusak kombo dengan pustaka lain dan akan mencegah gangguan yang tidak perlu bagi pengembang.

Untuk membuat versi perubahan yang melanggar, menurut saya 5.0 adalah ide yang bagus, tetapi saya tidak terlalu memikirkannya.

Saya masih sangat bingung tentang apa yang menyebabkan masalah ini pada awalnya
tempat. Kalian benar-benar membicarakan kepalaku.

Saya sangat peduli tentang pencocokan nomor versi, tetapi jika ada
untuk pergi agar masalah ini berhenti, saya akan menghadapinya.

Bukankah saya membaca artikel beberapa bulan yang lalu tentang bagaimana sebagian besar
Perpustakaan System.Net.Http sedang matahari terbenam untuk mendukung yang dibangun kembali?

Pada 15 Des 2016 15:18, "Karel Zikmund" [email protected] menulis:

@robertmclaws https://github.com/robertmclaws Kami tidak berpikir bahwa
perubahan versi akan membuat perbedaan. Kebanyakan orang (aplikasi dan perpustakaan
pemilik) biasanya hanya "tekan upgrade ke terbaru" pada paket mereka, mereka
tidak peduli seberapa banyak versi berubah (minor vs. mayor). Jadi melanggar
dampaknya akan persis sama.
Bahkan lebih buruk lagi bahwa efek "menghancurkan" hanya akan terlihat jika
Anda menggabungkan banyak hal. Itulah mengapa masalah ini lolos
tempat pertama - kami tidak memiliki pengujian untuk combo itu (dan saya akan berdebat
tidak apa-apa - seseorang tidak dapat menguji semua kombinasi, tetapi kita dapat membahasnya di
post-mortem nanti).

Saya tidak berpikir ada yang terlalu peduli tentang versi grup kerangka kerja secara keseluruhan
antara. Jujur saja, jika saya yakin ini akan membantu sebagian besar pelanggan, saya
akan memilih hanya mengubah angka - saya hanya tidak percaya itu akan
membantu hampir sama sekali. Itu hanya akan mengubah pesan kita menjadi "ya, kamu
rusak - itulah yang dikatakan versi itu, Anda hanya tidak menyadari seperti apa
hal-hal yang Anda setujui saat mengambil versi ", yang merupakan alasan IMO lumpuh.

Mengingat perbedaan pendapat, saya tertarik dengan pendapat orang lain:
silakan gunakan suara positif / suara negatif pada posting ini:

• 👍 jika Anda setuju dengan saya, yaitu menurut Anda pengiriman perubahan yang melanggar
  karena 5.0 tidak akan membuat perbedaan dan kebanyakan orang masih akan rusak,
  bingung dan terpengaruh.
• 👎 jika Anda setuju dengan @robertmclaws https://github.com/robertmclaws
  proposal, yaitu menurut Anda mengirimkan perubahan yang melanggar sebagai 5.0 akan membantu
  orang-orang memahami di awal bahwa mereka lebih suka menjauh dari paket,
  karena itu akan merusak combo dengan perpustakaan lain dan akan mencegah
  rasa sakit yang tidak perlu bagi pengembang.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267446604 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AAavtBRE24SlHsZHCYm5OhPbOGs6MfRzks5rIa68gaJpZM4JsdDX
.

Saya setuju. Saya memperoleh beberapa detail dari email sebelumnya hari ini, tetapi saya masih tidak yakin. Alangkah baiknya melihat deskripsi yang baik dari masalah internal sehingga kami memahami solusi yang diusulkan.

@ Karelz Saya menghargai apa yang Anda coba lakukan di sini, tetapi mengambil jajak pendapat tentang apa arti "versi 5.0" adalah membuang-buang waktu semua orang. Ini adalah sosialisasi GitHub, bukan rekayasa. Saya akan mengirimkan versi 5.0 HARI INI yang memperbaiki ini dan mengirimkan 6.0 ketika Anda mengetahui cara mengatur semua anotasi kecil Anda dengan benar dan / atau memfaktor ulang kode.

Pernyataan seperti "Kebanyakan orang (pemilik aplikasi dan perpustakaan) biasanya hanya menekan upgrade ke terbaru" tidak berguna. Begitulah cara Perl 6, Python 3, Rails 3 & 4, dan Node.js 1,2,3,4,5 & 6 berhasil memisahkan banyak hal. Jangan ikuti petunjuk itu.

@dluxfordhpf @ciel Sayangnya, hal ini sulit untuk dijelaskan. Semuanya berasal dari Keamanan Akses Kode "lama" yang tidak lagi direkomendasikan secara aktif untuk digunakan.

Berikut ringkasan dari apa tujuannya:
https://msdn.microsoft.com/en-us/library/ee191569 (v = vs.110) .aspx
https://msdn.microsoft.com/en-us/library/dd233102 (v = vs.110) .aspx

Masalah sebenarnya terkait dengan apa yang dikatakan @karelz dengan jenis satu tingkat transparansi keamanan (dengan cara berada di kerangka kerja desktop) yang mencoba berasal dari jenis yang memiliki sikap keamanan yang kurang ketat (karena atribut tidak ada di Versi OOB). Ini karena CAS sebagai konsep tidak ada di dalam apa pun selain desktop .net.

Dalam konteks dokumen di atas, lihat bagian ini tentang Aturan Warisan

Ini menjelaskan aturan yang diperlukan untuk pewarisan jenis di berbagai tingkat keamanan.

Terima kasih! Saya akrab dengan CAS; teknis luar biasa.

Mengingat semua perubahan nomor versi antara .NET Core, .NET Standard, et. Al. pada tahun lalu (dan mengirimkan kode baru versi 4.3 di NuGet yang berjalan pada 4.6.2, saya memahami bahwa Microsoft mungkin tidak menganggap bahwa nomor versi itu penting. Tetapi sebagai seseorang yang sendirian mengelola arsitektur aplikasi yang sangat kompleks, dan mengirimkan lebih dari 20 OSS NuGet paket, saya sepenuh hati tidak setuju.

Menekan "Perbarui Semua" tanpa memeriksa kompatibilitas adalah cara termudah di .NET untuk mengacaukan aplikasi Anda dan tidak mengetahuinya hingga runtime. Kepatuhan pada SemVer adalah satu-satunya cara untuk mempertahankan rasa kewarasan. Menambahkan versi utama mengomunikasikan bahwa ada sesuatu yang akan rusak. Ketika Anda memberi sinyal perubahan itu, Anda kemudian mendapatkan kebebasan untuk melakukan apa pun yang Anda inginkan untuk memperbaikinya.

Perbaikan yang diusulkan terdengar bagus bagi saya tetapi saya hanya ingin mengomentari matriks uji - penggunaan HttpClient di desktop. NET akan menjadi hal utama di masa mendatang. Kombo ini memang patut untuk diuji, padahal memang tidak semua kemungkinan bisa / harus diuji.

Ya, tes itu juga terdengar seperti copout bagi saya. Tambahkan 100 paket teratas ke proyek pengujian unit Anda dan pastikan omong kosong Anda masih berjalan. Sepertinya jenis rekayasa dasar yang biasa dilakukan Microsoft sebelum menyadari bahwa mereka dapat memecat penguji dan membiarkan "komunitas" menyelesaikan masalah ini. Itu hanya buang-buang waktu yang mengerikan dan membuat frustrasi.

Karena QA 'lama' yang menghadirkan Windows ME dan Vista lebih unggul.

Juga, saya yakin menghina mereka akan menyelesaikan pekerjaan lebih cepat.

Pada 16 Des 2016 7:46 AM, "chadwackerman" [email protected] menulis:

Ya, tes itu juga terdengar seperti copout bagi saya. Tambahkan 100 teratas
paket ke proyek pengujian unit Anda dan pastikan omong kosong Anda masih berjalan.
Sepertinya jenis rekayasa dasar yang biasa dilakukan Microsoft sebelumnya
menyadari bahwa mereka dapat memecat para penguji dan membiarkan "komunitas" menyelesaikan masalah ini
barang keluar sebagai gantinya. Itu hanya buang-buang waktu yang mengerikan dan membuat frustrasi.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267597137 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AAavtAUL3pmMiSRnFBe7DEa0y5AaZoVXks5rIpZIgaJpZM4JsdDX
.

Menemukan pemimpin tim tidak ada yang mengundang ke pesta liburan karena dia
memperlakukan orang seperti kotoran.

Pada 16 Des 2016 8:26 AM, "chadwackerman" [email protected] menulis:

Menyebut omong kosong, percaya atau tidak, tidak menyelesaikan pekerjaan lebih cepat.
Jika tidak, Anda memiliki manajer jutawan yang belum pernah menulis satu baris pun
kode dalam 10 tahun yang mengatakan "Wow hal Github ini benar-benar rapi. mari kita retas
emoji naik / turun suara dan adakan jajak pendapat jadi saya tidak perlu membuat keputusan. "
Seolah-olah itu akan menyelesaikan apa pun setelah kerja selama enam bulan
jam pertemuan triase secara internal. Ini sinyal sosial palsu dan
terus terang jenis yang biasa dipanggil insinyur bs yang menghasilkan kualitas
seperti roket Saturn V. Dan .NET yang merupakan kemasan bahasa terbaik
dan pustaka standar apa pun di ruang ini jauh sebelum semua ini online
kebodohan dimulai.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267604666 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AAavtEigDK5EqlA4LQVlxB_lfamMgHanks5rIp9-gaJpZM4JsdDX
.

Atau mungkin Anda menemukan orang yang belajar cara membuka blokir seluruh timnya dengan membuat Microsoft akhirnya bertindak atas masalah yang diabaikan selama berbulan-bulan.

Microsoft telah menduplikasi daftar bug dan prioritas secara internal. Github adalah sekelompok omong kosong sosial. Mereka tidak akan mengambil permintaan penarikan untuk masalah ini jadi ini berubah menjadi utas dukungan pelanggan. Para devs melakukan pekerjaan yang buruk di sini dan tidak apa-apa bagi mereka untuk mendengarnya.

Ada perbedaan mencolok antara developer yang mendengarnya dan menjadi seorang
bajingan yang tak tertahankan. Jika komentar yang menghina adalah satu-satunya cara Anda dapat menyampaikan a
titik, maka mungkin Anda harus tetap memarahi orang-orang Anda setidaknya
membayar untuk bertahan denganmu.

Pada 16 Des 2016 8:34 AM, "chadwackerman" [email protected] menulis:

Atau mungkin Anda menemukan orang yang belajar cara membuka blokir seluruh timnya
membuat Microsoft akhirnya bertindak atas masalah yang diabaikan selama berbulan-bulan.

Microsoft telah menduplikasi daftar bug dan prioritas secara internal.
Github adalah sekelompok omong kosong sosial. Mereka tidak akan menerima permintaan tarik
masalah ini jadi ini berubah menjadi utas dukungan pelanggan. Pengembang
melakukan pekerjaan buruk di sini dan tidak apa-apa bagi mereka untuk mendengarnya.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267606461 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AAavtHTdxym7pvR9KRomyIT14FVaILLFks5rIqF8gaJpZM4JsdDX
.

Saya akan menjawab hanya karena Microsoft menggunakan "urutkan berdasarkan nomor GitHub_of_comments " untuk membantu apa yang @karelz sebagai "mencari tahu pendanaan". Anda juga dapat menggunakan skala emoji GitHub untuk memvalidasi nilai sosial Anda.

Bung masuk dan berkata SemVer tidak penting. Itu tugas kami sebagai insinyur untuk menunjukkan betapa absurdnya hal itu. Ini adalah kasus klasik di mana kita membutuhkan manajer yang lebih senior yang memiliki pengalaman aktual, atau pria yang lebih junior yang benar-benar tahu bagaimana hal-hal berdampak pada dunia nyata. Manajer menengah yang berperan sebagai walikota di GitHub adalah masalah sebenarnya di sini. Sekarang silakan klik jempol ke bawah sehingga kita semua dapat melanjutkan hari kita, terima kasih.

Ya, bug ini telah tersedot, dan saya terkejut melihat jalur utama sev1 dirilis. Tetapi IMHO rasa sakit yang sebenarnya dari hal ini adalah karena desain NuGet: paket NuGet apa pun yang digunakan proyek harus direferensikan secara manual oleh semua konsumen proyek itu. Itu adalah duplikasi yang tidak perlu dan desain yang buruk, itu membuat Anda gagal. Wizard sinkronisasi tidak berguna jika desain dasarnya buruk. NUGET adalah alasan mengapa bug ini sangat menyakitkan. Kalau tidak, kita akan marah, meletakkan solusi buruk di Util, dan bisa melupakannya. Tapi sekarang kita harus berhati-hati dalam semua 18 proyek yang memakan waktu atau lebih, yang tumbuh setiap bulan. ITULAH mengapa bug ini sangat menyakitkan - karena NuGet, perbaikan tidak dapat diisolasi ke satu proyek, Anda harus menyentuh semuanya, dan terus melakukannya.

Juga, saya menggemakan sentimen bahwa Desktop / Windows .NET adalah yang penting. Saya senang mendengar tentang Microsoft .NET yang hadir di Linux, tetapi uangnya ada di Windows, di situlah kita seharusnya mendapatkan pengalaman terbaik, dan saya ingin yang berjalan terbaik.

Keluhan terus-menerus yang dimiliki tim saya adalah "mengapa kita harus mengunduh semua paket ini?" Kami membuat konsol atau proyek ASP.NET dan semua yang dibutuhkan ada di kotak. Anda membuat sesuatu yang lebih modern dan 5 miliar unduhan.

Oke, saya agak jauh. Terima kasih atas waktu dan perhatian Anda dan beri tahu saya jika kami dapat membantu Anda menguji / mengevaluasi / memeriksa dokumen untuk kesalahan ketik / apa pun yang Anda butuhkan, kami bersedia membantu.

Alasan mengapa masalah ini (dan dotnet / runtime # 17786) telah menyebabkan begitu banyak rasa sakit bagi kami adalah karena kami memindahkan layanan cloud kami dari peran web Azure ke layanan Fabric Layanan dan harus pindah ke netcore / netstandard, tetapi masih berjalan dalam kerangka penuh aplikasi.

Pada awalnya saya melakukan solusi pengalihan mengikat yang tampaknya berfungsi untuk sementara waktu, tetapi pengembang kami terus-menerus merusak sesuatu dengan secara tidak sengaja mengembalikan app.config, memperbarui paket nuget dan melawan AutoGenerateBindingRedirects (yang menonaktifkannya adalah mimpi buruknya sendiri).

Akhirnya, saya memecahkan masalah ini dengan memaksa penggunaan HttpClientHandler di mana-mana. Itu termasuk mengubah kode kita sendiri, mengangkat masalah di perpustakaan pihak ketiga dan bahkan menggunakan peretasan seperti refleksi dan menduplikasi kode pihak ketiga untuk mengatasi masalah tersebut.

Jadi apa pun solusinya, jika paket baru tidak mendukung HttpClient / HttpClientHandler yang lebih baru maka kami tidak akan menerimanya. Itu bukan masalah besar karena saat ini semuanya sedang berjalan. Namun, "perbaikan nyata" harus segera dilakukan, karena saya tidak ingin diblokir saat memperbarui lebih banyak paket pihak ke-3 yang mungkin akan memindahkan kode mereka ke standar bersih dan menyebabkan masalah ini.

@dluxfordhpf ... Alangkah baiknya melihat penjelasan yang baik tentang masalah internal sehingga kami memahami solusi yang diusulkan ...

Saya mencoba menjelaskan masalahnya di sini: https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198.
Singkatnya:

• Paket Http NuGet 4.1 / 4.3 "menimpa" Http 4.0 di .NET Framework, tetapi tidak memiliki atribut keamanan. Selain itu menggunakan komponen OS yang berbeda di bawah tenda (yaitu "perubahan besar" + berpotensi memecahkan kasus sudut (meskipun tidak secara langsung relevan dengan masalah ini, itu adalah tanda tas untuk masalah)).
• WebRequestHandler hanya bagian dari .NET Framework, tetapi bergantung pada Http 4.0 dan memerlukan atribut keamanan di Http.
• Setelah Anda mengambil ketergantungan pada Http 4.1 / 4.3 dari NuGet dan mengalihkan versi inbox 4.0 .NET Framework ke sana, Anda tidak dapat menggunakan WebRequestHandler.
• Untuk memperburuk keadaan, Http memiliki beberapa API baru yang merupakan bagian dari .NET Standard 1.6 dan beberapa komponen bergantung padanya. Jadi kita tidak bisa begitu saja memutar kembali ke versi lama.
• Dan tentu saja detailnya membuatnya semakin rumit.
• Menyatakan yang sudah jelas: Tidak ada "solusi yang tepat". Ini adalah masalah memilih salah satu yang berdampak lebih kecil secara keseluruhan.

@chadwackerman ... mengambil jajak pendapat tentang arti "versi 5.0" adalah pemborosan waktu semua orang. Ini adalah sosialisasi GitHub, bukan rekayasa.

Itu tidak bersosialisasi. Jika dilihat dari perolehan suara, terlihat tidak ada suara bulat tentang masalah tersebut. Jadi, bahkan jika Anda tidak mempercayai tim CoreFX (dengan pengalaman 10+ tahun dengan pelanggan .NET) yang mengatakan " orang tidak memperhatikan versi mayor seperti yang kita inginkan ", saya harap ini membantu untuk melihat bahwa bahkan beberapa MVP ( @onovotny) membagikan pendapat itu. Sementara MVP lain tidak setuju (@robertmclaws).

@chadwackerman ... Saya akan mengirimkan versi 5.0 HARI INI yang memperbaiki ini dan mengirimkan 6.0 ..

Ini adalah opsi [2] yang saya sebutkan di atas (dengan nomor versi berbeda). Itu adalah sesuatu yang sedang kita jelajahi secara paralel. Mengingat dampak dari solusi tersebut, tidak jelas " ya - itu jelas hal yang benar untuk dilakukan, ayo lakukan ".

@robertmclaws ... Microsoft mungkin tidak menganggap bahwa nomor versi itu penting ... Ketika Anda memberi sinyal perubahan itu, Anda kemudian mendapatkan kebebasan untuk melakukan apa pun yang Anda inginkan untuk memperbaikinya ...

Saya tidak mencoba mengatakan kami tidak percaya pada versi yang benar. Kami hanya percaya bahwa sebagian besar pengembang tidak peduli dan ingin semuanya selalu kompatibel sepenuhnya - yaitu kami tidak dapat melakukan apa pun yang kami inginkan bahkan dalam versi besar. Itu didasarkan pada pengalaman tim kami selama bertahun-tahun dengan layanan .NET dan pengiriman paket NuGet.

@gulbanana ... Combo ini memang patut untuk diuji, padahal memang tidak semua kemungkinan bisa / harus dicoba ...

Setuju, sekarang kita tahu itu penting kombo kita harus menambahkan cakupan untuk itu. Dan kita harus melihat area tersebut lebih banyak untuk melihat apakah kita kehilangan kombo serupa lainnya di sekitar paket Http NuGett.

@chadwackerman ... Tambahkan 100 paket teratas ke proyek pengujian unit Anda ...

Cukup lucu, itu mirip dengan yang saya usulkan setahun yang lalu ketika kami mengirimkan paket Meta yang buruk untuk UWP karena kurangnya cakupan pengujian yang tepat. Tidak semudah itu. Untuk menangkap bug yang menarik (seperti ini), Anda juga harus melatih kodenya. Seringkali Anda harus melatih kode dari kedua kombo dalam pengujian yang sama (tidak dalam kasus khusus ini). Secara keseluruhan sangat sulit di uji infra.
Jika Anda memiliki saran dan ide yang mungkin kami lewatkan, beri tahu kami - mari kita putar masalah baru untuk topik itu.

@chadwackerman ... dan biarkan "komunitas" menyelesaikan masalah ini ...

Kami (saya dapat berbicara untuk tim CoreFX dan CLR) TIDAK melakukan outsourcing pengujian produk ke komunitas melalui GitHub. Kami memegang standar tinggi pada kualitas barang yang kami kirim.

(hotkey tidak disengaja mengirim balasan sebelum saya menyelesaikannya ... untuk dilanjutkan ...)

@chadwackerman ... Microsoft telah menggandakan daftar bug dan prioritas secara internal ...

Setidaknya tidak benar pada tim CoreFX & CoreCLR - GitHub adalah basis data bug utama untuk semua .NET Core. Produk non-open source lainnya ("full" .NET Framework dan .NET Native) terutama menggunakan database bug internal.

@chadwellerman ... Mereka

Kami tidak akan mengambil permintaan penarikan yang tidak dapat menjawab / menjelaskan semua masalah di atas (termasuk yang tidak disetujui secara pribadi oleh orang yang mengirimkannya). Adakah proyek open source yang akan mengambil peretasan cepat tanpa memikirkan semua dampaknya? Mungkin jika 20% + pelanggannya berada di lantai ... itu tidak terjadi di sini (belum).

@chadwackerman ... Microsoft menggunakan "urutkan berdasarkan nomor GitHub_of_comments " untuk membantu apa yang @karelz dengan sopan sebagai "mencari tahu pendanaan". ...

Pertama, number_of_comments bukanlah metrik yang kami perhatikan (kecuali jika seseorang "secara manual" mengetahui bahwa metrik itu keluar dari atap). Dan itu pasti tidak ada hubungannya dengan "pendanaan".
Kami memperhatikan apa pun yang berdampak pada pelanggan - baik jumlah suara, atau ketidakpuasan pelanggan yang disuarakan (di GitHub, Twitter, komentar posting blog, di mana pun).
Bug ini masuk radar saya sebagai "ketidakpuasan pelanggan yang signifikan" (karyawan MS lain di utas ini mengangkatnya secara internal), itulah mengapa saya turun tangan.
Kami mendanai sebanyak yang kami bisa saat ini. Prioritas yang lebih tinggi hanya akan menjadi masalah keamanan atau 20% + pelanggan kami tidak punya solusi.
BTW: Melontarkan hinaan tidak akan membantu mempercepat atau memengaruhi pengambilan keputusan.

@dluxfordhpf ... tolong beri tahu saya jika kami dapat membantu Anda menguji / mengevaluasi / memeriksa dokumen untuk kesalahan ketik / apa pun yang Anda butuhkan, kami bersedia membantu ...

Terima kasih, kami menghargai tawaran Anda. Kami pasti akan menerima bantuan ketika kami memiliki bit siap (dan divalidasi pada repro yang kami miliki), untuk memvalidasi lebih banyak skenario ujung ke ujung. Kami ingin menghindari situasi ketika kami memperbaiki beberapa skenario ujung ke ujung, sementara membiarkan yang lain rusak dengan cara yang sama atau cara lain.

@jahmai ... tetapi

Terima kasih! Itu adalah contoh yang baik tentang mengklarifikasi dampak masalah pada pekerjaan harian dev yang perlu kita dengar dan pahami. Ini membantu kami memahami bahwa kombo dengan perkakas VS membuat ini menjadi mimpi buruk yang sebenarnya untuk dikerjakan. Kami akan mempertimbangkannya saat menyelesaikan rencana dan tanggal rilis (yang akan saya mulai segera setelah kami menyelesaikan solusinya).

@jahmai ... jika paket baru tidak mendukung HttpClient / HttpClientHandler yang lebih baru maka kami tidak akan menerimanya ...

Sekali lagi, umpan balik yang bagus untuk didengar. Kami masih mencoba untuk menyelesaikan seluruh perbaikan ujung ke ujung & cerita rilis, sebelum kami sepenuhnya membeli satu solusi. Melepaskan peretasan tanpa memahami dampaknya pada skenario lain (seperti skenario Anda) akan menjadi langkah putus asa dari kami - kami akan mempertimbangkannya hanya, jika kami tidak tahu cara memperbaikinya, atau jika perbaikan yang tepat sangat mahal. Kami belum ada di sana.

Mari kita bahas teknisnya mulai sekarang.

Pembaruan cepat:
Solusi [3] " Taburkan atribut Keamanan di System.Net.Http " seperti yang dijelaskan di atas tampaknya mahal (6w +), jadi kami memutar ulang detail implementasi internalnya: Kami sedang mempertimbangkan untuk menggunakan implementasi Http asli dari versi 4.0 paket + menerapkan 8 API baru di atasnya sebaik yang kami bisa (beberapa mungkin secara teknis merusak solusi). Dukungan http2 dan pernak-pernik "WinHttp stack" yang baru tidak akan tersedia secara default, siapa pun yang menginginkannya perlu memanggil konstruktor khusus (secara teknis melanggar perubahan, tapi mudah-mudahan tidak banyak orang yang bergantung pada barang baru 4.1 / 4.3 di bawah tenda) .
Biaya tampaknya jauh lebih rendah sejauh ini, tetapi kami masih mengejar dan menelan biaya 2 kerugian berakhir (API), sebelum kami menyelesaikan rencana akhir. Kami harus membuat beberapa keputusan kompatibilitas yang "menarik" setidaknya untuk 2 API, tetapi keputusan tersebut tidak boleh memperlambat waktu untuk merilis perbaikan.

BTW: Solusi [2] " Urungkan keputusan OOB " ternyata memiliki dampak lebih dari yang kami duga (misalnya, akan merusak .NET Standard 1.6, menciptakan lebih banyak kekacauan dan penjelasan jangka panjang). Kami menyimpannya sebagai pilihan terakhir saat ini, jika hal di atas ternyata terlalu mahal atau tidak masuk akal.

jika saat ini Anda melihat kasus-kasus edge seputar masalah ini, ini mungkin layak untuk dicoba:
https://github.com/gulbanana/repro-netstandard-httpclient

solusi ini menunjukkan bahwa saat ini di vs2017rc, menggunakan netfx dan hasil netstandard dalam bentrokan versi system.net.http. Saya tidak yakin bagaimana hubungannya dengan OOB.

Saya menghargai (dan terus terang mengagumi) keterusterangan @karelz di sini, tetapi saya akan membunyikan klakson versi untuk terakhir kalinya.

jika Anda tidak mempercayai tim CoreFX (dengan pengalaman 10+ tahun dengan pelanggan .NET) pendapat yang mengatakan "orang tidak memperhatikan versi utama" ... berdasarkan pengalaman tim kami selama bertahun-tahun dengan layanan dan pengiriman .NET NuGet paket ...

Saya tidak yakin tepatnya kesalahan logis mana ini, tetapi Anda tidak dapat mengklaim pemahaman tim berpengalaman yang mendalam tentang pembuatan versi di tengah-tengah masalah pembuatan versi besar-besaran seperti ini.

Mudah-mudahan kita setidaknya bisa setuju bahwa TIDAK menabrak nomor versi utama dan mengubah perubahan adalah yang terburuk dari semua dunia. Namun di sinilah kita. Dengan pembicaraan tentang "anggaran" dan "6+ minggu waktu pengembang" ... untuk memberikan beberapa atribut. Untuk sistem kepercayaan usang yang tidak pernah benar-benar berfungsi dan tidak saya gunakan. Karena masalah terabaikan di kompiler.

Amazon Web Services mengirimkan dukungan penuh .NET Core untuk semua layanan mereka musim panas lalu. Pembaruan terbaru mereka menurunkan standar dari standar 1,5 menjadi 1,3. Sementara itu, tim Azure bahkan tidak bisa menjalankan gumpalan.

Kalian mengirimkan bit-bit yang secara global merusak permintaan web https, secara diam-diam selama pembuatan dan keras saat runtime, dan masih belum memiliki rencana untuk menyelesaikannya empat bulan kemudian. Saya akan membatalkan ini untuk saat ini karena jelas Anda sedang mengerjakannya - tetapi jika masalah yang lebih besar di sini tidak membuat Anda terjaga di malam hari ...

Terima kasih banyak atas kejujuran dan penjelasan Anda.

@chadwackerman ... Anda tidak dapat mengklaim pemahaman tim berpengalaman yang mendalam tentang pembuatan versi di tengah masalah pembuatan versi yang sangat besar seperti ini. ... Mudah-mudahan kita setidaknya dapat setuju bahwa TIDAK menabrak nomor versi utama dan memiliki perubahan yang melanggar adalah yang terburuk dari semua dunia. Namun di sinilah kita. ...

Anda membuat 2 asumsi besar:

1. Asumsi: Perubahan melanggar diketahui (alias dipahami sebagai melanggar) sebelum pengiriman.
   
   
   
   • Itu tidak terjadi untuk masalah ini - seperti yang umum untuk kelas "perubahan yang tidak diinginkan". Ya, hal-hal terkadang lolos :(. Metrik penting adalah IMO: reaksi cepat (saya setuju kami tidak melakukannya dengan benar tentang masalah ini sampai sekarang) dan mengurangi / frekuensi rendah dari kesalahan seperti itu.
   
   
2. Asumsi: Pakar pembuatan versi mampu meninjau setiap perubahan (yang sebenarnya tidak) dan bahwa orang pada umumnya tidak pernah membuat kesalahan (sci-fi).
   
   
   
   • Dalam kasus khusus ini, paket API System.Net.Http (8 API baru untuk Desktop) telah ditinjau tingkat tinggi sebelum dikirim juga oleh pakar versi. Mereka memberikan saran dan panduan tentang pilihan. Sayangnya, tingkat pemecahan tidak dikenali oleh siapa pun (baik ahli bidang maupun ahli versi), oleh karena itu solusi yang dipilih menyebabkan masalah ini.
   
   

Saya juga ingin menunjukkan bahwa dengan mengabaikan pengalaman kami dalam pembuatan versi, pada dasarnya Anda mengatakan " jika Anda (tim .NET) pernah membuat kesalahan besar (bug ini), Anda tidak diizinkan menyebut diri Anda ahli bahkan dalam riwayat dan pelanggan masa lalu. pola (area terkait) ".
Itu palu besar IMO dan tidak realistis. Orang / tim terkadang membuat kesalahan (seperti ini). Itu tidak membuat mereka tidak layak menjadi ahli di daerah terdekat (atau bahkan di daerah tertentu). Kuncinya adalah jika mereka bisa belajar dari kesalahan mereka dan berbuat lebih baik di masa depan.

@chadwackerman ... Berbicara tentang "anggaran" dan "6+ minggu waktu pengembang" ... untuk memberikan beberapa atribut. ...

Biaya bukan dari "atribut slapping", itu bagian yang mudah. Bagian yang mahal adalah dari pertanyaan terbuka tentang opsi [3]:

https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198: Pertanyaan terbuka: Bisakah kita membuat dependensi internal WebRequestHandler bekerja dengan System.Net.Http berbasis WinHttp baru?

Ternyata, itu pekerjaan yang cukup banyak, dependensi internalnya terlalu buruk :(

Saya sangat menghargai semua diskusi tentang ini. Sungguh. Itu mengagumkan. Terima kasih telah terbuka tentang ini.

Namun, pada akhirnya, inilah masalah dotnet / corefx # 1: Kalian menulis ulang sebagian besar tumpukan. Bagian yang penting untuk hampir semua hal. Dan Anda bahkan tidak memiliki cakupan tes yang memadai. Seharusnya tidak membutuhkan ahli. Seharusnya memiliki kasus uji yang terdokumentasi dengan jelas yang ditulis pada saat WebRequestHandler ditulis (atau keputusan dibuat untuk tidak melakukan porting ke Core), dan seharusnya rusak saat kalian mulai menggunakannya.

Setelah> 5 tahun pengiriman barang terkait .NET 4.0, sebenarnya tidak ada alasan untuk tidak memiliki cakupan pengujian integrasi DI MANA SAJA yang akan menangkap ini. Jika Anda menemukan diri Anda membuat alasan untuk itu, Anda tidak menuntut keunggulan dari tim Anda.

Jika pernah ada:

• cakupan tes yang tepat
• proses QA yang tepat
• rilis beta yang tepat
• dan cara yang tepat untuk mengirimkan masalah ke tim tertentu yang bertanggung jawab atas paket tertentu

... ini tidak akan terjadi.

Jika tim:

• belum terlalu bertekad untuk mendidihkan laut dengan menulis ulang SETIAP ASPEK TUNGGAL .NET pada saat yang sama
• mengindahkan peringatan dari kami yang telah bersuara tentang hal ini sejak proyek ".NET 5 / MVC 6" dimulai

... ini tidak akan terjadi.

Ini adalah kombinasi dari kegagalan yang merusak .NET pada skala besar, pada skala yang tidak pernah saya ingat terjadi sebelumnya. Tetapi Anda juga telah merusak sebagian besar ekosistem, dan semakin sulit untuk diperbaiki.

Ada biaya _sangat nyata_ dan _signifikan_ untuk ini. Kami harus mematikan CI Server kami beberapa minggu yang lalu dan menerapkan secara manual, memverifikasi web.config secara manual setiap saat. Kami menerapkan setidaknya sekali sehari. Ratusan dolar seminggu dalam jam kerja tambahan, belum lagi penundaan karena harus menghabiskan waktu itu untuk melakukan sesuatu yang lain.

Sekali lagi, ini bahkan tidak memperhitungkan berjam-jam menangani kekurangan yang ada dalam arsitektur HttpClient: itu tidak membuang instance dengan benar, menjaga koneksi TCP tetap terbuka, dan menyimpan entri DNS terlalu lama.

Jadi, Anda akan menangkap beberapa kesalahan untuk ini. Dan memang sepatutnya begitu.

Dan berdasarkan seberapa "mahal" perbaikannya, saya harap Anda menempatkan tim macan dari beberapa orang terbaik Anda untuk memperbaikinya dengan benar, dan tidak meletakkannya di pundak satu orang.

... Pemukulan akan berlanjut sampai moral meningkat.

Biarkan mereka memperbaiki kesalahan yang mereka akui dan tidak terikat dalam kebijaksanaan.

Agar kami jelas, saya tidak mencoba untuk mengalahkan kuda mati dengan posting terakhir saya. Tetapi saya telah melihat terlalu banyak alasan dari Microsoft akhir-akhir ini. "Memberi nama itu sulit." "Pembuatan versi sulit." "Orang-orang membuat kesalahan." Ini adalah mentalitas kelemahan, dan bukan tim yang berjuang untuk mencapai keunggulan. Saya sangat mengagumi @karelz karena datang ke sini dan mendiskusikannya. Tetapi setiap karyawan MSFT harus berhenti membenarkan apa yang terjadi, dan membiarkan orang-orang melampiaskannya tanpa merasa perlu menghabiskan waktu untuk mengoreksi catatan. Ini bukan pengecualian super-edge-case ketika Anda menggunakan DateTime atau sesuatu. Ini adalah upaya kolosal karena lebih dari satu orang tidak menuntut kesempurnaan dalam pekerjaannya, dan harus diperlakukan seperti itu. Satu-satunya tanggapan yang valid adalah: "Kami berhasil. Kami merusak .NET. Kami tidak akan beristirahat sampai diperbaiki." Karena itu akan menjadi respon 5 tahun yang lalu saat Gu menjalankan pertunjukan.

Saya bersimpati kepada @karelz yang baru saja mengambil posisinya setelah sekian lama bekerja di .NET. Dan dia tentunya tidak harus membela timnya. Saya tidak menyalahkan para pekerja di sini; ini jelas merupakan masalah manajemen.

Tapi mungkin seharusnya tidak mengejutkan untuk melihat logika melingkar dan jenis pembicaraan ganda yang tersebar luas di lapisan tertentu dari manajemen Microsoft tidak berjalan dengan baik di depan pelanggan dunia nyata yang benar-benar menggunakan barang tersebut.

Di .NET Core Microsoft SQL Server kehilangan kemampuan untuk menulis nilai unsigned. Sekali lagi masalah terabaikan yang ada di bagian atas situs UserVoice sejak 2014. Perusahaan tidak memiliki kemewahan untuk mengubah skema database mereka (terutama sesuatu yang tweaky seperti unsigned) karena beberapa manajer program tidak dapat masuk ke halaman yang sama setelah tiga tahun. Sementara itu Redis dan SQLite (apa pun itu) berfungsi dengan baik, dan Scott Hanselman mengguncang demo pameran dagang seolah hal ini benar-benar berfungsi. Jelas ada jurang yang semakin lebar antara realitas internal dan eksternal di sini dan isu-isu tersebut perlu dilampiaskan (dengan sopan).

Penamaan itu sulit. Pembuatan versi itu sulit. Microsoft memiliki perspektif unik, di mana mereka berurusan dengan pelanggan dari semua jenis industri, mulai dari yang paling baru hingga yang paling akhir. Konsep untuk pendekatan pengembangan yang tampak "jelas" dalam game asing di sistem CRM. Bagaimana Anda mendekati masalah, apa yang penting dan apa yang tidak penting, berbeda-beda. Dan kemudian Anda menambahkan kemajuan teknologi, pendekatan berbeda untuk masalah: DAO vs ADO.NET vs LINQ vs EF untuk menggunakan perbandingan umum yang mudah. Akhirnya, persaingan di ranah server Internet, model perangkat keras baru dengan tablet siap pakai, dan virus Balmer. Cara berpikir yang benar-benar baru dan memodelkan masalah dengan berbagai keterbatasan dan keunggulan.

Pada satu titik saya bekerja untuk… perusahaan terkenal yang besar. Satu grup produk merilis produk dengan komponen bersama yang diperbarui, yang menafsirkan tumpukan panggilannya secara berbeda bergantung pada cara inisialisasi. Mereka tidak pernah mengujinya dengan produk kami, dan itu membuat produk kami meledak setiap saat. Jelas, tapi mereka tetap mengirimkannya. Kami menyebutnya insiden "tembakan persahabatan".

Saya melewatkan bug sekali di mana jika kami menginstal ke drive D, saat uninstall dalam kondisi tertentu produk dapat… menghapus semua file di HD. Kami harus membakar CD pres seharga $ 40k.

Orang tidak sempurna dan kami memang membuat kesalahan. Menyalahkan, bagaimanapun, adalah konsep yang tidak berguna. Itu membuat kita merasa kuat melalui konsep destruktif seperti rasa malu dan penghinaan. Kerendahan hati dan pengampunan lebih kuat. Begitulah cara kita berbuat lebih baik, mempelajari cara-cara yang lebih baik, dan terkadang hanya mengapa sesuatu itu penting.

Ya, masalahnya membuat saya marah juga, tetapi itu sedang diperbaiki. Dan tahukah Anda - masalah open source seperti ini merana selama beberapa dekade sebelum mengganggu bahkan mencoba. Coba saja Kerberos sistem Linux atau lihat GSSAPI. InitializeSecurityContext / AcceptSecurityContext jauh lebih mudah. Uang itu penting.

Pada satu titik saya bekerja untuk… perusahaan terkenal yang besar. Satu grup produk merilis produk dengan komponen bersama yang diperbarui, yang menafsirkan tumpukan panggilannya secara berbeda bergantung pada cara inisialisasi. Mereka tidak pernah mengujinya dengan produk kami, dan itu membuat produk kami meledak setiap saat. Jelas, tapi mereka tetap mengirimkannya. Kami menyebutnya insiden "tembakan persahabatan".

Itu adalah dua produk yang berbeda. .NET adalah produk tunggal. Dan saya tidak mencoba menyalahkan siapa pun. Saya menyalahkan prosesnya. Rasanya karena Microsoft menggunakan OSS, mereka membuang proses yang membantu mereka mengirimkan kerangka kerja pengembangan paling stabil dalam sejarah ke luar jendela. Saya merasa seperti ini akan ketahuan jika dikirim dalam .NET 4.6.3 daripada di NuGet.

Transisi ceroboh ke OSS tentu saja tidak membantu. Saya tidak menyalahkan OSS tetapi Microsoft tampaknya bangga membuat semua kesalahan yang jelas.

Saya menggunakan kata-kata seperti "kualitas" untuk mendeskripsikan perangkat lunak, tetapi sekarang mereka menggunakan kata-kata seperti "keterlibatan". Menjalankan kompilator berinstrumen yang menelepon rumah lebih dari dua puluh kali sehari karena saya harus mengedit file .config secara manual bukanlah "keterlibatan tambahan." Tapi inilah mitos seluruh internet hari ini.

Pertimbangkan tim BashOnWindows yang memutuskan untuk memiliki sekelompok orang yang tidak memiliki pengalaman Linux menulis shim kode pengguna Linux secara langsung di GitHub. Pekerjaan ini adalah latihan teknik dasar tetapi membosankan, dan sama sekali tidak ada alasan untuk melibatkan umpan balik komunitas untuk prioritas fitur. Tapi mereka pergi.

Enam bulan setelah itu, "komunitas" harus memberi tahu mereka bahwa mereka tidak dapat menangani file yang berakhir dalam satu periode. Ini bukan rekayasa perangkat lunak; ini semacam latihan pemasaran yang aneh. Manajer yang tersirat dalam skema berhak mendapatkan Umpan Balik. Dan beberapa di antaranya mungkin tidak enak didengar.

Edit untuk menambahkan: kesepakatan serupa dengan bencana Bash. Mengirimkan bit yang rusak secara langsung, hubungan aneh dengan komponen lain (hanya dapat diinstal sebagai bagian dari Pembaruan Windows), dan tentu saja Scott Hanselman entah bagaimana melakukan demo langsung meskipun faktanya ia tidak dapat menjalankan tar apalagi kompiler.

Beberapa retorika di sini bernada "masa lalu yang indah" dari Microsoft, yang ironis karena semua perubahan yang kita saksikan sekarang adalah tanggapan langsung terhadap permintaan pelanggan agar Microsoft berkembang.

Kami muak dengan aturan closed source dan draconian reverse engineering (de-compiling), jadi kami mendapat sumber referensi dan sekarang open source.

Kami muak dengan bug .net Framework yang memengaruhi setiap aplikasi yang diinstal pada mesin dan membutuhkan waktu lama untuk memperbaikinya serta memerlukan distribusi perusahaan dan departemen TI untuk memenuhi syarat setiap pembaruan versi .net Framework sebelum itu terjadi, jadi sekarang kami bergerak menuju mengirimkan paket nuget dengan aplikasi kami sehingga kami dapat mendorong perbaikan segera setelah tersedia.

Kami muak dengan Microsoft Connect yang mematikan setiap bug lain karena "berfungsi seperti yang dirancang" atau membutuhkan waktu 6 bulan bahkan untuk menjadwalkan rilis, jadi sekarang kami memiliki proyek Github yang dikelola lebih dekat oleh tim yang benar-benar menulis kode, dan keseluruhan komunitas dapat dengan mudah memberikan 2c mereka pada setiap item pekerjaan yang diangkat komunitas.

Kami muak dengan Microsoft yang mengambil setiap ide bagus di komunitas dan membuat tiruan kepemilikan yang tidak berfungsi dengan baik dengan alat non-Microsoft, jadi sekarang kami bisa menggunakan NPM, Gulp, NodeJS, dll.

Kami muak dengan C # yang hanya dapat digunakan untuk Windows, dan proyek seperti Mono berjuang untuk tetap setara, sementara harus mengatasi bug atau kurangnya fungsionalitas dengan #ifdef di mana-mana, jadi sekarang kami memiliki Xamarin yang mendorong pengembangan Mono dengan sumber referensi dan memungkinkan kami untuk mengkodekan bahasa C # terbaru dan berbagi basis kode yang sama di .net, UWP, iOS, Android dan netcore.

Semua ini terjadi sekaligus karena memang demikian. Kami tidak akan menunggu Microsoft untuk mengejar ketinggalan sementara itu mengirimkan fungsionalitas stabil yang sempurna yang hanya menyelesaikan setengah masalah kami pada waktu tertentu.

Masalah saya bukanlah bahwa semua perubahan ini terjadi sekaligus. Juga tidak ada masalah seperti ini yang muncul. Masalah sebenarnya bagi saya adalah bahwa _ butuh waktu berbulan-bulan sampai masalah ini dikenali sebagai masalah besar _ dan _ bahkan butuh waktu

Tiga minggu dan tidak ada pembaruan. Selamat Tahun Baru semuanya.

Edit untuk menambahkan kutipan ini dari @karelz karena

Saya akan memposting pembaruan (mudah-mudahan dengan lebih banyak detail teknis) ketika kami memilikinya, setidaknya setiap minggu.

@chadwackerman yang serius, apakah Anda mengerti bahwa sikap buruk Anda tidak akan membantu masalah ini diperbaiki lebih cepat? Dan selain itu, Anda membodohi diri sendiri di sini. Harap tingkatkan nada Anda.

Nada apa Dia membuat pernyataan, yang bermanfaat karena akurat, lalu mengucapkan Selamat Tahun Baru kepada semua orang. Jika Anda menganggapnya negatif, itu masalah Anda.

Dan terkait pernyataan pertama itu: ini adalah masalah utama yang tidak muncul hingga runtime. Lima tahun lalu ScottGu atau Rob Howard akan memiliki tim dalam 24-7 ini sampai perbaikan dikirim. Sekarang hanya "Anda tahu, kami akan membahasnya."

Anda tahu apa yang akan membuat orang bahagia? Perbaiki masalahnya. Jika tidak, ada beberapa pelanggan yang kesal di luar sana, dan beberapa dari mereka ada di utas ini. Mereka berhak untuk marah. Jadi temukan hal lain yang bisa dilakukan dengan kemarahan Anda, @pollax. Anda belum memberikan kontribusi apa pun yang berarti pada utas ini, dan tidak ada yang mengurapi Anda sebagai Polisi Pikiran GitHub. Anda juga belum menyia-nyiakan> $ 5K uang perusahaan Anda untuk masalah ini.

Ok, mungkin saya membaca terlalu banyak dan karena nada yang dia gunakan dalam komentar sebelumnya, saya membaca yang terakhir ini dengan nada yang sedikit ironis. Maaf soal itu.
Tentang masalah tersebut; Aku mendengarmu. Saya sendiri bermasalah dengan itu (jika tidak, saya tidak akan mengamati masalah ini begitu dekat) jadi tolong jangan membuat asumsi tentang apa yang telah / belum saya buang dalam hal uang / sumber daya untuk ini. Tetapi sebagai pengembang, saya tahu bahwa hal terburuk adalah melihat seseorang menatap Anda saat mencoba memperbaiki masalah besar.

Saya setuju dengan pembacaan sarkasme Anda dan setuju, itu tidak produktif. Saya juga setuju dengan perasaan "kapan itu akan diperbaiki". Sayangnya masalah CAT1 jalur utama ini tidak diperhatikan sampai banyak orang menjadi cukup vokal tentangnya. Saya berharap ada perbaikan proses secara internal untuk menyelesaikan ini; itu akan menyebalkan bagi kita semua jika satu-satunya cara kita bisa memperbaikinya adalah melalui kata-kata makian.

Saya juga mendapatkan laporan tentang hal ini terjadi pada kerangka penuh dengan paket nuget Exceptionless kami. Ada perbaikan atau solusi yang solid?

Saya juga mendapatkan ASP.NET Core hosting mandiri ini dari Layanan Windows yang menjalankan kerangka kerja penuh 4.6.2. ketergantungan NETStandard.Library 1.6.1 memaksa saya untuk menggunakan System.Net.Http 4.3.0.

ketergantungan NETStandard.Library 1.6.1 memaksa saya untuk menggunakan System.Net.Http 4.3.0.

dan ini adalah masalah terbesar saya dengan seluruh situasi ini

semakin banyak paket yang mengambil ketergantungan pada meta-paket, memaksa saya untuk meningkatkan setiap ketergantungan yang saya miliki (atau berjuang keras untuk menurunkan / mengabaikan yang spesifik)

ini bertentangan dengan janji sebelumnya tentang "padu padankan" dari dependensi sistem

Saya harus menurunkan sistem saya ke 4.5.2 dari 4.6.1 (& kehilangan waktu yang signifikan), karena setiap paket kedua membawa .net 1.6 dan System.Net.Http yang bermasalah

Jika ini hanya paket pihak ke-3, yah, biarlah, saya bisa mengelilinginya, mengganggu pengelola untuk menggunakan dependensi yang lebih terperinci, tetapi sebagian besar deps saya berasal dari MS, dan saya mengharapkan MS menggunakan dependensi granular, bukan cukup masukkan .net 1.6 ke dalam file nuget

Saya berencana mengirim pembaruan untuk beberapa hari terakhir, jadi ini dia:

Pekerjaan @CIPop didahului oleh masalah keamanan. Karyanya diambil oleh @davidsh. @davidsh berencana untuk mengirimkan PR awal minggu ini (yaitu setiap hari sekarang).

Berikut detail rencana & status eksekusi kami:

Paket tingkat tinggi:
A.Ganti WinHttpHandler dengan HttpClientHandler di net46 build dari CoreFX
B. Menerapkan 8 API baru di HttpClientHandler yang kami perkenalkan di paket 4.1.0.0 OOB

Rencana eksekusi:

EDIT 2017/1/12 - rencana eksekusi dipindahkan ke pos paling atas https://github.com/dotnet/corefx/issues/11100#issue -173058293

@niemyjski Ada perbaikan atau

Ada solusi untuk menurunkan versi paket yang melanggar ke 4.0.0.0 (lihat https://github.com/dotnet/corefx/issues/11100#issuecomment-246469893), sayangnya sesuai komentar di atas, setiap pengeditan pada dependensi NuGet akan mengembalikannya - itulah alasan utama mengapa masalah ini sangat menyakitkan.

Saya berharap ada perbaikan proses secara internal untuk menyelesaikan ini; itu akan menyebalkan bagi kita semua jika satu-satunya cara kita bisa memperbaikinya adalah melalui kata-kata makian.

Saya punya beberapa ide (dan pertanyaan) tentang perbaikan proses di sini, untuk mencegah masalah penting yang berdampak penting di masa depan tidak diperhatikan begitu lama. Namun, saya sengaja menunda diskusi itu SETELAH kami mengirimkan perbaikan.

Woot !!!

Selamat guys

Terima kasih atas pembaruannya. PlatformNotSupported akan lebih baik daripada tidak sama sekali karena ini adalah aplikasi baru yang tidak diandalkan oleh perangkat lunak lama.

Kedengarannya seperti pasca-perbaikan, penyatuan melalui pengalihan mengikat masih akan diperlukan, tetapi pengalihan ke yang lebih baru daripada perakitan yang lebih lama, nuget mana yang dapat menghasilkan dengan benar?

Sekarang PR dotnet / corefx # 15036 diperiksa, masalah ini akan hilang wrt net46. System.Net.Http.dll sekarang menggunakan tumpukan HTTP bawaan dari .NET Framework. Ini berarti ia memiliki kompatibilitas 100% dengan WebRequestHandler.

Silakan coba paket terbaru di umpan dev MyGet. Anda akan ingin menggunakan paket System.Net.Http.dll bawaan terbaru yang saat ini adalah:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

versi 4.4.0-beta-24913-02.

Anda dapat menggunakan paket umpan dev melalui mengubah umpan sumber paket NuGet baik dengan alat baris perintah atau Visual Studio.

Instruksi:

Garis komando:
Tambahkan yang berikut ini di nuget.config, di bawahelemen:

<add key="myget.org dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />

Studio visual:
Di VS, Tools-> Options-> Nuget Package Manager-> Package Sources -> Add, di bawah Source, gunakan url ini, https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Dalam kedua kasus tersebut, pastikan Anda mencantumkan umpan dev MyGet sebagai umpan pertama dalam daftar.

Dan untuk meringkas perbaikan dalam dotnet / corefx # 15036, kami mendapatkan 100% app-compat dengan permukaan API .NET Framework System.Net.Http 4.0 asli dan 100% app-compat saat menggunakan WebRequestHandler .

Dalam hal tingkat dukungan untuk properti baru yang ditambahkan ke HttpClientHandler (yang merupakan bagian dari .NET Core 1.1 dan seterusnya), berikut ini merangkum perilaku yang diharapkan dari properti baru ini saat berjalan di target 'net46' :

1) CheckCertificateRevocationList bool publik
Melempar PlatformNotSupportedException

2) Sertifikat Klien X509CertificateCollection publik
Diterapkan

3) publik ICredentials DefaultProxyCredentials
Diterapkan

4) MaxConnectionsPerServer int publik
Diimplementasikan terhadap logika ServicePoint

5) MaxResponseHeadersLength int publik
Diterapkan

6) IDictionary publikProperti
Diterapkan

7) Fungsi publikServerCertificateCustomValidationCallback
Diimplementasikan kecuali parameter pertama selalu null karena ketidakmampuan saat ini untuk memetakan internal HttpWebRequest menjadi HttpRequestMessage

8) SslProtocols SslProtocols publik
Melempar PlatformNotSupportedException

Woo hoo! Terima kasih teman-teman!

Adakah yang mendapat kesempatan untuk memvalidasi bit @davidsh ? Kami sangat menyambut baik beberapa validasi ujung-ke-ujung pada skenario 7-ish yang diisyaratkan di utas ini.

Kami sejauh ini dapat memvalidasi repro sederhana @onovotny . Akan sangat bagus untuk mendapatkan beberapa konfirmasi lebih lanjut tentang repro yang tidak kami miliki secara lokal. Terima kasih!

Setelah kami memilikinya, kami akan beralih ke port perubahan ke 1.1 cabang dan merilis sebuah patch - mudah-mudahan minggu depan.

Saya akan menyelesaikan beberapa tes minggu ini. Saya baru saja ditarik ke eskalasi jadi saya tidak bisa mulai selama 1-2 hari, dengan perkiraan.

@dluxford terima kasih! Hargai bantuan Anda.

Saya baru saja menginstal 4.4.0-beta-24913-02 ke dalam proyek saya. Tampaknya membantu kasus saya.

Kasus: Meng-hosting sendiri ASP.NET Core dari Layanan Windows yang menjalankan kerangka kerja penuh 4.6.2. ketergantungan NETStandard.Library 1.6.1 memaksa saya untuk menggunakan System.Net.Http 4.3.0.

Menurut pengalaman saya, umpan myget sangat lambat. Butuh beberapa menit untuk menginstal System.Net.Http 4.4.0-beta-24913-02
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 82079ms
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 93813ms

Terima kasih @ annemartijn0 untuk konfirmasi dan

Saat ini diperlukan lima hingga tujuh menit agar halaman ini memberikan hasil:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Mengapa Microsoft mengalihkan infrastruktur penting ke perusahaan kecil yang teduh dan situs kecil yang bodoh ini? Anda benar-benar memilih untuk menyematkan bisnis Anda DAN bisnis saya di sebuah perusahaan di Belgia bernama Tech Tomato?

Bagaimanapun ... Saya sudah memiliki umpan myget tetapi tidak menarik ke bawah perpustakaan ini sampai setelah saya me-restart Visual Studio, mengklik tombol "update" yang terkubur dalam dialog di suatu tempat, lalu memulai ulang Visual Studio untuk kedua kalinya. Saya sedang mengetik ini saat Visual Studio 2015 mencoba memulihkan paket saya.

Pembaruan: Visual Studio masih berputar tetapi penyegaran halaman myget saya akhirnya muncul. Ini menunjukkan mungkin selusin unduhan sehari dari versi perpustakaan ini. Sementara Visual Studio meringkasnya sebagai "System.Net.Http - 75.8K download." Saya selalu berasumsi bahwa statistik ini memberi tahu saya hal yang salah, tetapi inilah contoh bagus mengapa itu bukan yang saya inginkan. Setidaknya beri tahu saya status versi saat ini versus ringkasan jadi saya tidak secara tidak sengaja menjadi penguji alfa tanpa secara eksplisit memilih ke dalam kegilaan selama momen absurd dalam sejarah NET.

5 jam kemudian dan saya masih tidak dapat mencoba tambalan ini:

Attempting to gather dependency information for package 'System.Net.Http.4.4.0-beta-24913-02'
with respect to project '...', targeting '.NETFramework,Version=v4.6.1'

Lima menit kemudian...

Package 'System.Net.Http 4.4.0-beta-24913-02' is not found in the following primary source(s):
'https://dotnet.myget.org/F/dotnet-core/api/v3/index.json'. Please verify all your online package
sources are available (OR) package id, version are specified correctly.

.NET adalah api ban.

Mudah- mudahan ada

.NET bukanlah api ban, sekarang. Tentu, ada banyak keju yang dipindahkan dan banyak bagian yang bergerak dan hal-hal yang bisa (dan memang) salah. Tapi ada banyak orang yang melakukan hal-hal hebat dengan bit RC dan RTM dirilis. Saya pribadi memutuskan untuk menggunakan barang-barang rilis publik saja - bahkan BETA atau RC lagi. Jadi ekspektasi saya adalah: lebih sedikit masalah tetapi harus menunggu lebih lama. Jadi jika Anda menemukan beberapa hal ini benar-benar membuat frustrasi bagi Anda - mungkin tunggu sebentar lagi untuk beberapa pekerjaan dev ini untuk mencapai status RTM.

Pekerjaan tim corefx (dan yang lainnya di dunia .NET-core) sangat bagus dan sambutan yang sangat baik sehubungan dengan penggunaan github / open-and-transparent, dibandingkan dengan bad-ole-Balmer-day, jadi mari semua mencoba dan tetap positif dan membantu para pemelihara repo. Semua orang di sini adalah manusia dan semuanya hanya mencoba membuat dunia menjadi tempat yang lebih baik: satu byte pada satu waktu.

@chadwackerman Sepertinya feed myget menderita sekarang. Saya tidak 100% yakin bagaimana myget bekerja, tapi menurut saya jika Anda memiliki host khusus ("dotnet.myget.org") maka feed sebenarnya disewa dan memiliki batasan QOS.

Pergi di sini menunjukkan paket itu ada, tetapi butuh beberapa saat untuk muncul: https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

@ PureKrome Saya mantan manajer pengembang Microsoft yang diminta untuk memeriksa versi ini (lihat di atas). Setelah secara pribadi melaporkan bug ini secara internal karena tidak ada seorang pun di tim .NET yang menyadarinya. Dan sekarang mereka tidak bisa mengirimiku biner sialan.

Saya tahu ban terbakar ketika saya melihatnya. Saya biasa menyisihkannya untuk Microsoft untuk mencari nafkah.

@chadwackerman Saya dapat memahami kekecewaan Anda terhadap masalah feed. Namun, penamaan nama ('situs kecil yang bodoh' dan 'perusahaan kecil yang teduh') tidak sesuai.
Tech Tomato didirikan / dijalankan oleh individu yang memenuhi syarat: @maartenba , penerima MVP oleh atasan Anda sebelumnya, dan @xavierdecoster , karyawan MS saat ini; di negara (yang saya pilih) yang mendorong inovasi. Nama perusahaan hampir tidak relevan dan bahwa perusahaan didirikan di Belgia menunjukkan bahwa tim .NET Core mencari solusi di luar Redmond, WA.
Saya menantikan kontribusi konstruktif Anda untuk membantu menyelesaikan masalah ini.

Konten diedit oleh moderator

Laporan Kode Etik telah dikirimkan terhadap beberapa komentar di utas ini dan sebagai hasilnya kami telah menghapus beberapa materi yang dinilai telah melanggar kode tersebut. Jika Anda memiliki pertanyaan atau kekhawatiran tentang itu, silakan kirim email ke [email protected].

@chadwackerman posisi Anda sebelumnya di perusahaan tidak memberikan Anda hak untuk menampar siapa pun atau terlibat dalam pemanggilan nama. Selain itu, sebagian besar 'kontribusi' Anda ke utas ini tidak hanya tidak konstruktif tetapi juga kecil, kekanak-kanakan, dan di luar topik. Tolong troll di tempat lain.

Halo semuanya - Martin dari .NET Foundation di sini, ingin menjelaskan hal ini .

Saya sangat menghargai bahwa masalah asli yang diangkat oleh utas ini membuat frustrasi dan orang-orang menginginkannya diperbaiki. Saya juga memahami beberapa kekhawatiran yang lebih luas seputar kualitas dan penyampaian serta kekuatan perasaan secara umum. Tim sedang bekerja untuk menyelesaikan masalah ini, mereka akan terus memberi tahu orang-orang terbaru.

Sementara itu, jaga agar nada bicara tetap profesional dan jangan memberikan komentar yang dapat dianggap sebagai serangan pribadi terhadap orang lain. Saya sengaja mengurangi pengeditan yang dilakukan karena saya ingin mempertahankan beberapa kekuatan perasaan dan tidak terlalu membersihkan, tapi tolong jaga agar semuanya tetap sopan.

Adakah orang lain yang mencoba menghubungi Tech Tomato? Tidak ada tanggapan atas pertanyaan saya.

Inilah tampilannya jika Anda mencoba melakukan pekerjaan sebenarnya dengan memilah-milah peringatan build yang aneh setelah menambahkan feed:

Attempting to gather dependency information for package
'System.Net.Http.4.4.0-beta-24913-02' targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 1.55 min

Attempting to gather dependency information for package 
'Microsoft.Extensions.Configuration.Json.1.1.0' targeting '.NETFramework,Version=v4.6.1' 
Gathering dependency information took 2.2 min

... dan seterusnya.

Dan tautan ini masih membutuhkan 5+ menit untuk menampilkan halaman:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Bahwa ini a) belum diperbaiki b) diabaikan oleh komunitas dan c) ditoleransi oleh tim .NET sebagai bagian dari pengembangan sehari-hari berfungsi untuk memperkuat kelemahan yang jelas dalam proses, perkakas, budaya dan manajemen yang menyebabkan bug ini mulai dengan - ditambah bug itu sendiri diabaikan selama berbulan-bulan sampai saya secara pribadi meningkatkannya secara internal.

Saya menantikan bedah mayat yang dijanjikan @karelz .

Hai Chad,

Waktu buka halaman itu adalah sesuatu yang kami lihat. Waktu pemulihan NuGet tidak normal. Jika memungkinkan, dapatkah Anda menghubungi kami (MyGet) melalui dukungan di MyGet.org dengan menyebutkan versi NuGet.exe Anda yang digunakan serta pelacakan dengan sakelar -Verbosity Detailed yang diaktifkan? Ini pasti akan membantu kami dalam menentukan masalah kinerja.

Terima kasih!

Package Manager Console Host Versi 3.5.0.1996

Saya akan melihat mendapatkan log dari baris perintah saat Visual Studio berubah dari rock solid menjadi tidak stabil setelah saya menambahkan feed myget.org. Dan begitu terjadi kesalahan saat menarik paket, semuanya akan berakhir.

ps @ karelz : ban api.

Dapatkah Anda mencoba baris perintah ini menggunakan NuGet.exe terbaru (setiap malam) dari www.nuget.org/downloads?

Perintah yang tepat: NuGet.exe menginstal System.Net.Http -Version 4.4.0-beta-24913-02 -Verbosity Detailed

Ini juga harus mengeluarkan semua tindakan unduhan menengah. Terima kasih!

@maartenba :

Pada link yang Anda kirim, "terbaru" mengarah ke https://dist.nuget.org/win-x86-commandline/latest/nuget.exe. Itu adalah versi yang sudah saya miliki, jadi menurut saya itu bukan versi malam hari.

Saya mengunduh paket nightly NuGet.CommandLine.4.0.0-rtm-2254.nupkg, menjalankan instalasi nuget.exe di atasnya, dan gagal mencoba menarik file dari myget.org. FYI: 1,5 detik untuk mengembalikan 404 dari dotnet.myget.org.

Jika ini bukan cara yang benar untuk menginstal nightly build atau paket lokal, harap informasikan. Anda dapat mengirimi saya email dengan nama pengguna ini di gmail jika Anda lebih suka menggunakan offline ini.

Masih senang membantu tapi ... wow. Hal-hal yang benar-benar harus bergerak ke arah kesederhanaan, bukan saya memecahkan masalah host paket sekunder untuk host paket utama menggunakan setetes pengelola paket setiap malam yang, meskipun menggunakan versi 4.0.0-rtm, entah bagaimana memiliki lima metode manual yang berbeda untuk memperbarui dirinya sendiri di halaman distribusinya, yang masing-masing memerlukan intervensi pengguna secara manual.

ps @ karelz ... oh, sudahlah. :)

Sepenuhnya setuju, tetapi log akan sangat membantu dalam mencari tahu di mana letak bottleneck (apakah host paket sekunder, klien itu sendiri, node CDN gila, sinar kosmik, ...). Akan menghubungi Anda secara offline untuk mengetahui apakah kami dapat menemukan jawabannya. Sangat menghargai bantuan Anda dalam hal ini.

Saya menyadari bahwa myget.org cukup lambat, tetapi saya berhasil menginstal paket yang dimaksud dalam waktu yang "wajar" (di jaringan Wi-Fi publik).

OK https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms
Installing System.Net.Http 4.4.0-beta-24913-02.

Kami pasti harus melihat kelambatan myget.org secara keseluruhan, tetapi mungkin di luar cakupan masalah ini - lagipula ini bukan skenario pelanggan biasa. @maartenba di mana tempat terbaik untuk membahasnya?
Di sini (pada masalah khusus ini), mari kita fokus bagaimana membuka blokir validasi ujung-ke-ujung, misalnya dengan menggunakan beberapa solusi kreatif.
Saya juga ingin tahu apakah orang lain telah diblokir begitu parah seperti @chadwackerman , atau apakah pengalaman @chadwackerman sangat buruk, dibandingkan dengan yang lain.

@chadwackerman mengingat bahwa tujuan utama di sini adalah untuk memvalidasi skenario end-to-end, saya ingin tahu apakah Anda dapat memberikan langkah-langkah skenario Anda? Orang lain di sini (yang tidak begitu buruk diblokir oleh penggunaan myget.org seperti Anda) dapat menyelesaikan validasi dalam kasus seperti itu. Itu akan mengurangi rasa sakit Anda dan membuang waktu di sisi Anda. Tentu saja, dengan asumsi itu bisa dilakukan dan bisa dilakukan dengan murah-ish dari pihak Anda.

Alternatif terakhir, yang ingin saya hindari, adalah melewatkan validasi skenario Anda sepenuhnya - jika kami mendapatkan beberapa skenario end-to-end lainnya yang divalidasi, kami mungkin baik-baik saja (dengan asumsi skenario terburuk di mana @maartenba tidak akan dapat memecahkan masalah pengalaman myget.org Anda yang sangat buruk :().

@karelz menjadikan ini offline dengan Chad, akan melaporkan kembali ke sini setelah kami mengetahui apa yang terjadi.

Fakta latar belakang:

• Umpan myget.org digunakan oleh build harian, CI, dev-workflow, dll. Jadi, feed tersebut sering dipalu setiap hari. Tidak satu pun dari masalah kinerja ini yang terwujud dalam skenario tersebut (ketika terjadi di masa lalu kami menanganinya, karena masalah tersebut memengaruhi alur kerja pengembang kami - kami membuat waktu sinkronisasi 30-60 menit menjadi <5 menit dalam beberapa bulan terakhir). Pemahaman saya adalah bahwa sangat jarang bagi siapa pun di tim NET atau dalam komunitas untuk menggunakan umpan myget di VS - yang IMO menjelaskan mengapa kinerja buruk tidak diperhatikan dalam skenario itu.
• Masalah ini disampaikan kepada saya oleh rekan kerja di utas ini pada 2016/12/9 - itulah mengapa saya bergabung dengan diskusi di sini. Saya tidak mengetahui adanya eskalasi internal lainnya. Mengingat bahwa saya terus mendorong masalah ini secara internal ke berbagai tim (hampir setiap hari), saya rasa saya mengetahui semua peristiwa yang terkait dengan masalah ini.

@ Karelz Ya, saya

Saya telah memverifikasi bahwa MyGet.org tidak berfungsi dengan baik dari beberapa komputer teman di Pantai Timur dan Barat. Milik saya adalah instalasi bersih Visual Studio 2015 baru-baru ini, tidak ada add-in, pasti tidak ada ReSharper. Umpan balik pengguna dan penanganan galat di Visual Studio buruk. Bahkan di sini pengguna lain melaporkan kelambatan serupa. Saya akan menghentikan ini sekarang untuk membebaskan utas tetapi jangan berpura-pura bahwa MyGet tidak macet dan seluruh sistem pengemasan NuGet (dan kemampuan NuGet untuk memperbarui dirinya sendiri) tidak sedikit pun berbau karet terbakar dan juga bukan faktor penyebab bug ini. Keduanya awalnya sebagai bagian dari akar masalah dan bahkan hari ini sebagai bagian dari mencoba untuk menguji dan mengirimkan perbaikan.

Tidak yakin apakah kami harus terus mendiskusikan ini di utas ini atau membuka utas lain untuk itu. Pokoknya: laporan status!

Kami berhubungan dengan @chadwackerman melalui email - terima kasih Chad atas log yang Anda kirim!

Pada "kelambatan" - preliminary profiling memberi tahu kita bahwa hal ini disebabkan oleh jumlah versi paket dan dampak dari fakta tersebut pada ukuran download untuk data protokol. Misalnya, beberapa paket memerlukan 4 MB data JSON untuk diunduh dan diurai untuk mengumpulkan metadata. Hal ini menyebabkan lonjakan penggunaan memori yang besar di klien NuGet dan kebutuhan untuk mem-parsing muatan kapal data JSON - pasti ada ruang untuk perbaikan di sana meskipun nightlies 4.0.0 dari klien tampaknya berperilaku lebih baik.

Di sisi MyGet, kami akan menerapkan paging untuk gumpalan protokol ini untuk mengurangi ukuran unduhan pada protokol. Mungkin butuh waktu seminggu untuk ditayangkan. Kami juga akan membuat profil server dan klien pada permintaan ini dan melihat apakah ada ruang untuk pengoptimalan di kedua sisi.

Kami juga ingin mempercepat waktu muat halaman tersebut (tetapi itu sekunder, menginstal / memulihkan pekerjaan dengan cepat adalah prioritas).

Setelah berjam-jam eksperimen saya dapat memutakhirkan ke System.Net.Http 4.4.0-beta-24913-01 tanpa merusak Visual Studio. Saya kemudian mencoba memutakhirkan dari 24913-01 ke 24913-02 dan mendapatkan kesalahan yang tepat alih-alih macet.

Ini tahun 2017 dan memperbarui build malam dari komponen inti HTTP untuk seluruh sistem dari "build Senin" menjadi "build Selasa" membutuhkan lebih dari lima menit waktu jam dinding pada 8-Core i7 dan membutuhkan lebih dari 4GB RAM.

Proyek yang dimaksud adalah webjob (aplikasi baris perintah yang diganti mereknya) yang terdiri dari 27 baris kode.

Menariknya, @karelz menyatakan bahwa ini berfungsi dengan baik untuk seluruh tim .NET dan dia tidak memiliki masalah sama sekali untuk menyedot biner bahkan saat dengan santai menyesap latte dari Starbucks lokal.

Saya berhasil menginstal paket yang dimaksud dalam waktu yang "wajar" (di jaringan Wi-Fi publik).
https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms

Berikut beberapa fakta alternatif:

Mencoba mengumpulkan informasi ketergantungan untuk paket 'System.Net.Http.4.4.0-beta-24913-02' sehubungan dengan proyek 'webjob', menargetkan '.NETFramework, Version = v4.6.1'
Mengumpulkan informasi ketergantungan membutuhkan waktu 4,22 menit
Mencoba menyelesaikan dependensi untuk paket 'System.Net.Http.4.4.0-beta-24913-02' dengan DependencyBehavior 'Terendah'
Menyelesaikan tindakan untuk menginstal paket 'System.Net.Http.4.4.0-beta-24913-02'
Tindakan terselesaikan untuk menginstal paket 'System.Net.Http.4.4.0-beta-24913-02'
System.OutOfMemoryException: Pengecualian tipe 'System.OutOfMemoryException' dilempar.
di Newtonsoft.Json.Linq.JContainer.ReadContentFrom (JsonReader r)
di Newtonsoft.Json.Linq.JContainer.ReadTokenFrom (pembaca JsonReader)
di Newtonsoft.Json.Linq.JObject.Load (pembaca JsonReader)
di NuGet.Protocol.HttpSource. <> c.b__15_0 (Aliran arus)

Ya, bisakah kalian pindahkan masalah MyGet / NuGet ini ke edisi baru? Ini tidak ada hubungannya dengan masalah aslinya.

@onovotny - Anda dapat mempertimbangkan untuk membuka kembali masalah Anda. Masalah ini sekarang sangat panjang, jadi kegunaan masalah telah dikurangi.

@richlander alih-alih mengawasi utas, apakah Anda akan mencoba menginstal perbaikan dan melaporkan kembali jika ini menyelesaikan masalah khusus Anda? Semua orang tampaknya diblokir oleh masalah penting ini namun orang lebih suka bermain pingpong GitHub daripada melakukan pekerjaan sebenarnya untuk menguji perbaikan.

Uji semua ~ 7 skenario ujung ke ujung yang dilaporkan oleh komunitas (mintalah bantuan dari komunitas, berikan langkah-langkah untuk menggunakan paket master di myget)

Apa sajakah 7 skenario itu? Bisakah semua orang membantu?

@richlander Saya akan dengan senang hati membuka kembali masalah, apakah Anda hanya ingin saya mengkloning masalah ini dengan pembaruan @karelz ? Tidak yakin apa yang ditanyakan.

Usecase saya bekerja dengan Azure Storage API, yang terakhir berfungsi di 4.0.1-rc2-24027. Sepertinya ini berfungsi sekarang. Saya hanya melakukan tes cepat, karena butuh sekitar 20 menit untuk memperbarui semua paket dalam proyek saya dari MyGet.

@onovotny Jangan membukanya kembali. Kami mendapatkan momentum di sini dan kami hanya berjarak beberapa inci dari setidaknya sebagian resolusi. Utas ini sangat banyak bagi siapa pun yang baru bergabung sekarang, tetapi seperti masalah lama yang belum terselesaikan yang mengungkapkan masalah yang lebih dalam, harus begitu. GitHub menyebalkan untuk hal-hal seperti ini.

Saya memverifikasi bahwa biner baru berfungsi dengan kompatibel pada satu aplikasi lokal. Tidak mengherankan. Saya kemudian mencoba untuk memotong dan menempelkan ketergantungan tersebut ke proyek pekerjaan web saya dan saya tidak dapat membuatnya berfungsi di Azure. Webjob dimuat dengan baik tetapi gagal saat dipicu, tidak dapat memuat System.Net.Http. Ini jelas salah saya dan saya tahu cara untuk memperbaikinya. Tapi saya cukup kembali ke tempat saya saat bug ini pertama kali dibuka: remaps pengikatan tweaky dan ketika saya menyentuh NuGet semua kacau, saya membuang banyak waktu, dan proyek saya melewati semua tes secara lokal namun putus saat runtime saat penerapan .

Jadi skenario kami adalah:

1. Paket dependen (Raven.Database) menggunakan WebRequestHandler, yang rusak saat runtime seperti yang dilaporkan dalam masalah ini.
2. Kode kami menggunakan tipe dan properti HttpClientHandler baru.

Sebelumnya saya mencoba perbaikan pengalihan yang mengikat tetapi itu menyebabkan perselisihan, saya kemudian akhirnya menggunakan peretasan (injeksi refleksi, menduplikasi dan memodifikasi kode pihak ketiga) untuk mengatasi masalah tersebut.

Saya telah memperbarui ke versi beta dan menghapus semua kode peretasan, dan semuanya (aplikasi kami, ujung ke ujung, dari browser ke database) tampaknya berfungsi secara lokal! Saya belum mencoba kode pada platform Azure jadi saya akan mengonfirmasi kembali setelah selesai, tetapi saya menganggap kemajuan yang signifikan ini.

Juga, ketika memperbarui paket saya merasa lumayan untuk menggunakan Konsol Manajer Paket Visual Studio dan menggunakan perintah ini untuk memperbarui paket (daripada menambahkan konfigurasi feed lain dan kemudian menggunakan UI, yang sangat menyakitkan):

Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core

Ini membutuhkan 6 menit 53 detik untuk memperbarui 20 proyek.

Perhatikan bahwa semua proyek kami memiliki pengalihan pengikatan berikut yang dihasilkan secara otomatis, saya tidak perlu mengutak-atik pengalihan pengikatan sama sekali:

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
      </dependentAssembly>
    </assemblyBinding>

Hampir waktunya untuk tos!

@jahmai Ketika saya menggunakan baris perintah itu tidak memperbarui referensi saya dari 4.0 ke 4.2 atau menambahkan tanda salinan yang diperlukan. Pastikan itu diatur untuk System.Net.Http dan dependensi dan itu harus berfungsi dengan baik di Azure.

Skenario kami adalah ketergantungan langsung pada tipe di System.Net.Http.
Saya menguji Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core pada satu proyek dan sejauh ini tampaknya berhasil dengan baik. Itu kabar yang sangat bagus.
Perbarui Lupa menyebutkan bahwa pengalihan yang mengikat dari 4.0.0.0 ke 4.2.0.0 diterapkan secara otomatis.

Mengenai masalah Nuget / MyGet, saya mendapatkan output berikut untuk proyek tunggal ini:

Mengumpulkan informasi ketergantungan membutuhkan waktu 37,47 detik
Pelaksanaan aksi nuget memakan waktu 35,15 detik
Waktu Berlalu: 00: 01: 14.7537429

Perhatikan bahwa saya berada di zona waktu UTC +01: 00, tidak tahu kapan MyGet mendapatkan lalu lintas terbanyak.

@pollax Terima kasih. Kami menemukan masalah (lihat komentar terakhir saya di atas) - kombinasi klien + server. Bekerja untuk membuatnya lebih baik.

Saya dapat mengonfirmasi menggunakan pustaka System.Net.Http beta dari MyGet berfungsi untuk skenario saya:

• .NET 4.6 aplikasi konsol dengan ketergantungan pada perpustakaan yang menggunakan System.Net.Http

Diperlukan waktu sekitar 90 detik untuk mengunduh paket nuget dari MyGet dan bindingRedirect di app.config diterapkan dengan benar.

Saya senang membantu menguji lebih banyak skenario jika telah dijelaskan di suatu tempat.

Efek samping yang menarik: menambahkan 4.4.0-beta dari pustaka .NET khusus Windows menghentikan penerapan aplikasi .NET Core di Linux.

"dotnet restore" di-hardcode menjadi 60 detik waktu pengambilan paket. Dan tidak ada tanda untuk memilih hanya platform tertentu seperti dukungan "dotnet publish". Jadi untuk pustaka lintas platform, simpul pekerja Linux kecil Anda mengunduh banyak binari Windows secara tidak perlu - kemudian waktu habis dan gagal saat menyentuh MyGet. Yang mengherankan, masalah kehabisan memori yang membuat Visual Studio crash pada mesin 32GB tidak memengaruhi pekerja Linux 0,75 GB karena malah menukar hingga mati.

Ya, saya mencatat ini di tempat lain. Dan ya, ini berhubungan dengan bug ini meskipun Anda belum melihatnya.

Terima kasih semuanya membantu kami memverifikasi skenario! Sejauh ini kami mendapat 5 konfirmasi - lihat daftar terperinci dengan tautan di pos paling atas. Saya menganggap validasi cukup baik untuk pindah ke tahap berikutnya.

• [4.a.ii] Saya masih mengejar analisis NuGet.
• [5.a] Saya akan meminta @davidsh untuk mempersiapkan PR terhadap rilis / cabang 1.1.0.

• [5.b] Saya sedang mempersiapkan proses untuk rilis (kami memerlukan persetujuan setingkat direktur, tetapi mengingat dampaknya pada pelanggan, saya tidak mengharapkan adanya penolakan).

• Saya sedang mempersiapkan info resmi tentang rilis patch - mencantumkan semua perubahan teknis yang merusak dan solusi (terima kasih kepada @davidsh untuk datanya).

Jika ada yang menemukan kekhawatiran apa pun untuk sementara (terkait dengan masalah khusus ini), harap katakan secepatnya. Semoga saja.

@onovotny - Tampaknya masalah ini sedang berkembang, jadi mari kita lanjutkan dengan masalah ini. Senang rasanya melihat orang membuat kemajuan positif.

@ Karelz Anda dapat memeriksa skenario saya yang menyertakan baris perintah 4.6 (pekerjaan web Azure) dengan ketergantungan ServiceBus dan aplikasi 4.6 dengan ketergantungan pada Azure Batch. Juga aplikasi ketiga dengan ketergantungan pada AWS dan Dropbox yang sebelumnya saya pindahkan ke .NET Core hanya untuk melepaskan diri dari masalah ini (saya menarik versi lama untuk diuji hari ini).

Masalah pemulihan dotnet dihidupkan kembali di https://github.com/NuGet/Home/issues/2534 , saluran belakang tetap Kontributor Kovenan, ban ditendang di https://github.com/Azure/azure-storage-net/issues/372 , MyGet log terkirim, log performa tambahan diminta di https://github.com/dotnet/cli/issues/5328 , dan saya membeli sekantong besar popcorn untuk diskusi postmortem.

Terima kasih @chadwackerman atas bantuan dan konfirmasinya! Maaf atas masalah yang Anda temui dalam perjalanan.
Saya telah memperbarui postingan teratas.

Dari daftar saya di atas:

Saya sedang mempersiapkan info resmi tentang rilis patch - mencantumkan semua perubahan teknis yang merusak dan solusi (terima kasih kepada @davidsh untuk datanya).

Saya telah menambahkan info ke posting paling atas - lihat bagian "Dampak perubahan - Perubahan yang melanggar" untuk daftar perubahan teknis yang melanggar (4), masing-masing dengan solusi.

Library NuGet yang terpengaruh oleh perubahan teknis (dijelaskan dalam posting paling atas) - untungnya "hanya" 4 library NuGet yang menggunakan salah satu API baru ini:

System.Private.ServiceModel_4.3.0

• https://www.nuget.org/packages/System.Private.ServiceModel/
• Penulis: dotnetframework
• Unduhan: 11K (versi terbaru) / 800K (total)
• Deskripsi: Paket implementasi internal tidak dimaksudkan untuk konsumsi langsung. Harap tidak merujuk secara langsung. Menyediakan implementasi paket System.ServiceModel.
• Catatan:
• Status: Paket tidak terpengaruh - @zhenlan @mconnew dari tim WCF mengonfirmasi bahwa mereka menggunakan properti hanya di build .NET Core. Di Desktop, mereka kembali ke binari Desktop bawaan.

Konsul_0.7.2.1

• https://www.nuget.org/packages/Consul/
• Nama: Konsul
• Penulis: https://www.nuget.org/profiles/highlyunavailable
• Unduhan: 500 (versi terbaru) / 65K (total)
• Deskripsi: https://github.com/PlayFab/consuldotnet/blob/master/CHANGELOG.md
• Catatan:
  
  
  
  • 2 penggunaan: https://github.com/PlayFab/consuldotnet/search?utf8=%E2%9C%93&q=ServerCertificateCustomValidationCallback
  
  
  • Masalah diajukan di GitHub: https://github.com/PlayFab/consuldotnet/issues/79
  
  
  • Email dikirim ke penulis melalui nuget.org
  
  
• Status: Paket tidak terpengaruh (Masalah GitHub https://github.com/PlayFab/consuldotnet/issues/79 ditutup)

Octopus.Client_4.6.1

• https://www.nuget.org/packages/Octopus.Client/
• Penulis:
  
  
  
  • https://www.nuget.org/profiles/paulstovell
  
  
  • https://www.nuget.org/profiles/OctopusDeploy
  
  
• Unduhan: 250 (versi terbaru) / 55K (total)
• Deskripsi: Tidak ada
• Catatan:
  
  
  
  • Masalah diajukan di GitHub: https://github.com/OctopusDeploy/OctopusClients/issues/121
  
  
  • Email dikirim ke alias dukungan: [email protected]
  
  
  • Email dikirim ke penulis melalui nugget.org
  
  
• Status: Paket tidak terpengaruh (detail dalam masalah GitHub https://github.com/OctopusDeploy/OctopusClients/issues/121)

Geotab.Checkmate.ObjectModel_5.7.1701

• https://www.nuget.org/packages/Geotab.Checkmate.ObjectModel/
• Nama: SDK Geotab
• Penulis: https://www.nuget.org/profiles/neilcawse
• Unduhan: 150 (versi terbaru) / 10K (total)
• Deskripsi:
  
  
  
  • Perpustakaan SDK untuk mengakses database pelanggan MyGeotab
  
  
  • Lihat daftar lengkap perubahannya di https://my.geotab.com/sdk/default.html#/whatsNew
  
  
• Catatan:
  
  
  
  • Email dikirim ke penulis (CEO geotab.com) melalui nugget.org
  
  
• Status: Pemilik dihubungi, menunggu tanggapan

Maaf atas ketidaknyamanan untuk semua pembuat paket yang terpengaruh.

Pada Visual Studio / NuGet crash / swapping di Linux: alasannya adalah cara kerja protokol NuGet. Saya telah mendokumentasikan temuan dalam masalah ini: https://github.com/NuGet/Home/issues/4448

Di sisi MyGet, kami akan menerapkan perubahan setelah akhir pekan (saat ini dalam pengujian, ETA dalam produksi Senin 7 Februari) yang mengurangi sisi server ini.

Perbaikan di sisi MyGet sedang live. Seharusnya berfungsi dengan baik di Visual Studio. Saat menggunakan NuGet.exe, pastikan untuk menggunakan NuGet.exe yang disematkan di https://dotnet.myget.org/F/nuget-build/api/v2/package/NuGet.CommandLine (4,0 malam) - 3.5 tampaknya gagal menentukan dependensi (tetapi tidak selalu). Bug dicatat: https://github.com/NuGet/Home/issues/4512

Terima kasih telah menyelam lebih dalam di @maartenba ini. Jangan pernah meremehkan dampak yang bahkan dapat ditimbulkan oleh perbaikan perkakas kecil!

Menarik bahwa seluruh tim .NET bisa kehilangan Visual Studio dan masalah NuGet.

Saya pernah meminta ruangan dengan 80+ pengembang Microsoft untuk mengangkat tangan mereka jika ada yang mengalami masalah dalam mengatur breakpoint di debugger. Saya punya dua tangan. Kompilator mengubah format simbol, Anda tidak dapat membangun proyek tanpa kompilator terbaru, tetapi debugger belum memperbarui.

Selama berbulan-bulan tidak ada yang bisa menetapkan breakpoint. Pada dua platform Anda bahkan tidak bisa mendapatkan jejak tumpukan! Saya dipanggil ke lab build pada pukul 1 pagi karena saya satu-satunya orang di sekitar, mendapatkan layar yang penuh dengan perakitan untuk prosesor yang belum pernah saya lihat dokumennya, menarik backtrace dan debugger menabrak debugger.

Ketika Anda mengubah format proyek saat Anda mengubah kode yang mem-parsing format proyek saat Anda melakukan dogfood versi baru manajer paket yang dihubungkan ke versi baru Visual Studio - hal-hal seperti ini hasil. Manusia hanya bisa menghadapi begitu banyak perubahan sekaligus dan inilah mengapa para dev terus menjatuhkan bola kemana-mana. Kami dan mereka!

Jika seseorang menginginkan skrip PowerShell sederhana untuk memperbaiki bindingRedirect di semua app.config, ini dia. Mungkin ini bukan solusi terbaik tetapi sekarang saya memiliki proyek dengan banyak sub-proyek webjobs dan itu benar-benar membuat frustrasi secara manual mengubah semua pengikatan file setelah memperbarui beberapa paket.

param(
    [string]$SourceDirectory,
    [string]$Package,
    [string]$OldVersion,
    [string]$NewVersion
)

Write-Host "Start fixing all app.config"

[array]$files = get-childitem $sourceDirectory -Include app.config App.config -Recurse | select -expand FullName
foreach ($file in $files)
{
    Write-Host $file
    $xml = [xml](Get-Content $file)
    $daNodes = $xml.configuration.runtime.assemblyBinding.dependentAssembly
    foreach($node in $daNodes)
    {
        if($node.assemblyIdentity.name -eq $package)
        {
            $updateNode = $node.bindingRedirect
            $updateNode.oldVersion = $OldVersion
            $updateNode.newVersion =$NewVersion
        }
    }
    $xml.Save($file)
}

Write-Host "Done"`

Contoh penggunaan:
./scripts/FixAppConfig.ps1 -SourceDirectory "--project-path--" -Package "System.Net.Http" -OldVersion "0.0.0.0-4.3.0.0" -NewVersion "4.0.0.0"

Kapan ini go public lagi? :)

Perubahan kami masuk ke cabang rilis / 1.1.0 pada hari Selasa - versi paket 4.3.1. Semua paket di cabang telah diubah ke stabil kemarin (upaya independen, tetapi membantu kami juga :)).
@davidsh akan melakukan tes kewarasan pada myget feed (ETA: hari ini), kemudian kami akan meminta validasi terakhir di sini oleh komunitas (ETA: hari ini, EOD). Setelah kami memiliki validasi akhir pada build itu, kami akan mengirimkan paket ke NuGet. Harapan saya kurang dari seminggu.

Kami mengalami keterlambatan dalam kemajuan dan komunikasi, karena kami harus meyakinkan pihak kapal, mengapa ini yang terbaik dan satu-satunya perbaikan.
Selain itu, kami sedang mempersiapkan rencana (berdasarkan umpan balik ruang pengiriman) untuk menghentikan pengiriman paket di luar larangan ini sepenuhnya dalam .NET Standard 2.0 dan meneruskan semua fungsionalitas ke kerangka kerja Desktop dalam kotak (fungsionalitas .NET Core tidak akan tersentuh) - yaitu tidak diperlukan pengalihan pengalihan jika Anda menargetkan .NET Standard 2.0. Setelah saya memiliki detail tentang dampak pada semua skenario, saya akan memperbarui utas ini (dalam 1-2 minggu).

Itu kabar baik, dan akan membuat netstandard2.0 lebih mudah digunakan.

@davidsh memverifikasi paket 4.3.1 dari cabang rilis (peringatan: myget sangat lambat untuknya - 5 menit)
Berikut langkah-langkah untuk memvalidasi:

Silakan coba paket terbaru di umpan dev MyGet. Anda akan ingin menggunakan build STABLE (bukan Prarilis) terbaru dari paket System.Net.Http.dll - 4.3.1 :
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Anda dapat menggunakan paket umpan dev melalui mengubah umpan sumber paket NuGet baik dengan alat baris perintah atau Visual Studio.

Instruksi:

Garis komando:
Tambahkan yang berikut ini di nuget.config, di bawahelemen:

<add key="myget.org dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />

Studio visual:
Di VS, Tools-> Options-> Nuget Package Manager-> Package Sources -> Add, di bawah Source, gunakan url ini, https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Dalam kedua kasus tersebut, pastikan Anda mencantumkan umpan dev MyGet sebagai umpan pertama dalam daftar.

[EDIT]
Harapkan pengalihan binding ke 4.1.1.0 di file konfigurasi Anda:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

Saya telah memperbarui 'Rencana eksekusi' posting teratas dengan langkah-langkah selanjutnya:

• 5.c Validasi akhir / terakhir dari (sebagian besar) ~ 7 skenario ujung-ke-ujung - orang-orang yang membantu sebelumnya (atau siapa pun), dapatkah Anda membalas setelah Anda memverifikasi dengan deskripsi singkat skenario? Terima kasih! (kita hampir sampai)
  
  
  
  • cc: @ annemartijn0 @karelkrivanek @jahmai @pollax @MikeGoldsmith @chadwackerman @dluxfordhpf @onovotny
  
  
• 5.d Publikasikan paket di myget.org

Mencoba memverifikasi tetapi saya mendapatkan kesalahan saat mencoba menginstal paket itu.

Ketika saya melakukan validasi, saya melakukannya dengan proyek baru.

Saya menduga bahwa kesalahan yang Anda dapatkan dengan "Gagal memperbarui pengalihan pengikatan" disebabkan oleh penurunan versi dalam versi paket dan perakitan. Proyek Anda saat ini tampaknya didasarkan pada paket dari cabang [master]. System.Net.Http.4.4. * Adalah penomoran paket dari cabang [master] (bagian dari pra-rilis untuk .NET Core 2.0). Ini memiliki versi perakitan untuk System.Net.Http yaitu 4.2. *.

Paket System.Net.Http versi 4.3.1 adalah paket STABIL (bukan pra-rilis) dan dibuat dari cabang layanan .NET Core 1.1 (kompatibel dengan rilis layanan .NET Core 1.1.1). Ini berisi biner dll System.Net.Http dengan versi perakitan yang berbeda.

Saya pikir bug yang Anda temukan adalah ketika Visual Studio / NuGet mencoba menulis ulang pengalihan pengikatan Anda untuk versi perakitan yang diubah dari System.Net.Http.

Jadi, Anda dapat mencoba membuat solusi / proyek baru yang segar. Atau mungkin hapus pengalihan pengikatan Anda dan kemudian mengembalikannya.

FYI. Log saya dari penginstalan paket:

Attempting to gather dependency information for package 'System.Net.Http.4.3.1' with respect to project 'Net46HttpTest3', targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 4.27 min
Attempting to resolve dependencies for package 'System.Net.Http.4.3.1' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'System.Net.Http.4.3.1'
Resolved actions to install package 'System.Net.Http.4.3.1'
Retrieving package 'System.Security.Cryptography.Encoding 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.Primitives 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.Algorithms 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.X509Certificates 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Net.Http 4.3.1' from 'CoreFx Dev Feed'.
  GET https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.3.1
Adding package 'System.Security.Cryptography.Encoding.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Encoding.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
  OK https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.3.1 302ms
Installing System.Net.Http 4.3.1.
Added package 'System.Security.Cryptography.Encoding.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Encoding 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.Primitives.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Primitives.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Primitives.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Primitives 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.Algorithms.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Algorithms.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Algorithms.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Algorithms 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.X509Certificates.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.X509Certificates.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.X509Certificates.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.X509Certificates 4.3.0' to Net46HttpTest3
Adding package 'System.Net.Http.4.3.1' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Net.Http.4.3.1' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Net.Http.4.3.1' to 'packages.config'
Successfully installed 'System.Net.Http 4.3.1' to Net46HttpTest3
Executing nuget actions took 2.41 sec
========== Finished ==========
Time Elapsed: 00:06:40.8451462

Hm, saya bingung saat mengujinya. Saya memperbarui ke 4.3.1 dan mendapatkan pengalihan pengikatan berikut di web.config saya.

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

Diharapkan?
Mungkin saya melewatkan sesuatu sebelumnya di utas, atau mungkin ini adalah salah satu dari versi paket yang membingungkan vs situasi kesalahan versi dll.
Saya juga mencopot paket, menghapus pengalihan pengikatan dan kemudian menginstal ulang dan saya mendapatkan hasil yang sama.

Membangun dan menjalankan Works On My Machine ™ ️.

Kebetulan saya tidak begitu yakin mengapa versi ini turun dari 4.4 menjadi 4.3.1 tapi oke.

Versi turun dalam penomoran karena versi 4.4 akan menjadi yang terbaru tetapi masih pra-rilis dan akan dikirim sebagai bagian dari .NET Core 2.0. @karelz meminta orang-orang untuk menguji paket itu terlebih dahulu karena perbaikannya ada terlebih dahulu.

Paket 4.3. * Didasarkan pada RTM .NET Core 1.1. Dan akan ada rilis servis untuk itu. Jadi, paket yang diperbarui berdasarkan basis kode tersebut adalah 4.3.1 untuk System.Net.Http (karena paket .NET Core 1.0 adalah 4.3.0 untuk System.Net.Http.

Mungkin saya melewatkan sesuatu sebelumnya di utas, atau mungkin ini adalah salah satu dari versi paket yang membingungkan vs situasi kesalahan versi dll.

Ya, ini membingungkan. Versi paket NuGet tidak sama dengan versi rakitan .NET dari biner.

Untuk paket System.Net.Http 4.3.1 NuGet, itu memang berisi biner System.Net.Http yang memiliki versi perakitan 4.1.1.0. Jadi, Anda mendapatkan hasil yang benar.

Terima kasih @pollax untuk validasi skenario ujung-ke-ujung Anda (posting teratas diperbarui).
Menunggu beberapa validasi lagi , sebelum kami dapat mengirimkannya sebagai perbaikan terakhir di nuget.org ... hampir selesai ...

Saya mohon maaf karena kami melewatkan pengalihan yang mengikat dalam instruksi (saya tidak menyadari kami secara otomatis menabrak versi perakitan karena potensi GAC, tetapi itu masuk akal).
Juga maaf karena myget memaksa Anda masuk ke semua paket dari myget - Saya menindaklanjuti dengan orang-orang secara internal untuk mengetahui apakah kami memiliki langkah-langkah untuk mengambil hanya satu paket dari myget. Setidaknya untuk verifikasi di masa mendatang.

@davidsh bisakah Anda mengoordinasikan validasi ujung-ke-ujung selama saya OOF? Setelah kami memiliki ~ 3 validasi, silakan tanya @leecow / @weshaggard untuk mempublikasikan paket tersebut di nuget.org. Terima kasih!

Hai teman-teman,

Sedikit keluar dari topik tetapi saya hanya ingin memberikan teriakan kepada tim di sini. Masalah ini sangat aktif dan responsnya terkadang bermusuhan. Terlepas dari permusuhan, saya merasa tim pengembang di sini menanganinya dengan kelas.

Terima kasih atas dukungan teman-teman dan pertahankan kerja yang baik. Terjadi kesalahan. Terima kasih telah memperbaikinya, saya mengerti ini membutuhkan waktu.

Berikut konfirmasi lain bahwa versi baru memperbaiki masalah.

Kami menggunakan KeyVault, beralih ke 4.3.1 memperbaiki masalah.

Hai, Saya mengalami masalah ini dengan SignalR. Tetapi bagaimana cara mendapatkan System.Net.Http 4.3.1? Saya hanya melihat 4.3.0 in
https://www.nuget.org/packages/System.Net.Http/

Ups, pesan terlewat tentang CoreFx - https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Ini memperbaiki masalah SignalR saya.

Seperti dicatat oleh orang lain, umpannya sangat lambat. Adakah peluang untuk mendapatkan 4.3.1 ke saluran nuget normal? Itu Sab jam 1:30 siang dan whoa .... (8 menit menunggu deps)

Mencoba mengumpulkan informasi ketergantungan untuk paket 'System.Net.Http.4.3.1' sehubungan dengan proyek 'Translate \ Kumquat.Translate.Tests', targeting '.NETFramework, Version = v4.6'
Mengumpulkan informasi ketergantungan membutuhkan waktu 5,85 menit
Mencoba menyelesaikan dependensi untuk paket 'System.Net.Http.4.3.1' dengan DependencyBehavior 'Terendah'
Satu atau lebih batasan ketergantungan paket yang belum terselesaikan terdeteksi di file packages.config yang ada. Semua batasan ketergantungan harus diselesaikan untuk menambah atau memperbarui paket. Jika paket ini sedang diperbarui, pesan ini dapat diabaikan, jika bukan kesalahan berikut mungkin memblokir operasi paket saat ini: 'System.Net.Http 4.3.0'
Menyelesaikan informasi ketergantungan membutuhkan waktu 0 ms
Menyelesaikan tindakan untuk menginstal paket 'System.Net.Http.4.3.1'
Tindakan terselesaikan untuk menginstal paket 'System.Net.Http.4.3.1'

Mencoba mengumpulkan informasi ketergantungan untuk paket 'System.Net.Http.4.3.1' sehubungan dengan proyek 'Dict \ Kumquat.Dict.CE.Tests', menargetkan '.NETFramework, Version = v4.6'
Mengumpulkan informasi ketergantungan membutuhkan waktu 3,84 menit
Mencoba menyelesaikan dependensi untuk paket 'System.Net.Http.4.3.1' dengan DependencyBehavior 'Terendah'
Satu atau lebih batasan ketergantungan paket yang belum terselesaikan terdeteksi di file packages.config yang ada. Semua batasan ketergantungan harus diselesaikan untuk menambah atau memperbarui paket. Jika paket ini sedang diperbarui, pesan ini dapat diabaikan, jika bukan kesalahan berikut mungkin memblokir operasi paket saat ini: 'System.Net.Http 4.3.0'
Menyelesaikan informasi ketergantungan membutuhkan waktu 0 ms
Menyelesaikan tindakan untuk menginstal paket 'System.Net.Http.4.3.1'
Tindakan terselesaikan untuk menginstal paket 'System.Net.Http.4.3.1'

Skenario @karelz Azure Storage API divalidasi ulang dengan versi 4.3.1 dari MyGet.

Maaf karena tidak menanggapi lebih awal.

Ketergantungan pengumpulan https://github.com/NuGet/Home/issues/4448

Saya pikir itu. Adakah ETA untuk memasukkannya ke nuget.org?

@davidsh Hai David, apakah ini minggu 4.3.1 membuatnya menjadi nuget? Saya memiliki proyek yang cukup kompleks dan rasanya waktu tunggu harus menyesuaikan dengan jumlah paket dalam proyek tersebut. Tetap saja, memperbaiki lebih baik daripada tidak sama sekali. Saya kira saya bisa menyalin nupkg di suatu tempat.

Mencoba mengumpulkan informasi ketergantungan untuk paket 'Kumquat.Translate.8.6.2' sehubungan dengan proyek 'qi', menargetkan '.NETFramework, Version = v4.6'
Mengumpulkan informasi ketergantungan membutuhkan waktu 8,76 menit

Terakhir 8,76 menit.

@davidsh Ini baru saja muncul di milis OwlMQ. Saya dapat melaporkan bahwa paket yang diperbarui menyelesaikannya.

Terima kasih banyak kepada tim yang telah maju dalam hal ini. Pekerjaan luar biasa!

Terima kasih atas semua validasi paket.

Paket System.Net.Http 4.3.1 telah dipromosikan ke NuGet.org.

https://www.nuget.org/packages/System.Net.Http/4.3.1

Hm, sangat aneh - klien RavenDB sekarang mengeluh tidak dapat menemukan rakitan 4.1.1

EDIT: Caveat - Acme.Core referensi RavenDB.Client dan Acme.Main referensi Acme.Core. VS2015 tidak akan menyalin System.Net.Http sebagai ketergantungan tetapi pengalihan mengikat ada -> boom. Apakah ini perilaku yang diharapkan? Perbaikan yang cukup sederhana tentunya ...

Menutup masalah sebagai sudah diperbaiki. Terima kasih @davidsh dan @CIPop atas pekerjaan mereka di sini!
Terima kasih semuanya atas kesabaran mereka. Dan kami mohon maaf atas keterlambatan ini. Langkah selanjutnya: bedah mayat (seperti yang dijanjikan) - tolong beri saya ~ 2 minggu untuk mengetahui semua detail sejarah di sekitar sini ...

@georgiosd dapatkah Anda mengajukan masalah baru dan memberikan laporannya? (idealnya dimulai dengan proyek baru)

@karelz terima kasih!

FYI:

• Saya memperbarui posting paling atas dengan daftar skenario terverifikasi (kalau-kalau itu diperlukan di masa depan) dan menautkan ke paket.
• Untuk masa depan, saya berencana untuk melihat langkah-langkah untuk menggunakan hanya paket tertentu dari myget alih-alih seluruh umpan, untuk mengatasi masalah mendapatkan semuanya sebagai yang terbaru (dan juga masalah kelambatan). Mari berharap kita tidak membutuhkannya secepat itu.

@karelz pertanyaan singkat: di mana kita bisa menemukan info tentang bedah mayat, bila sudah selesai. Di utas ini _atau_ utas / tempat lain?

@ PureKrome Saya pasti akan memperbarui utas ini - lebih mudah bagi semua orang yang sudah tertarik untuk mendapatkan notifikasi. Juga tujuan saya bukan untuk mengecilkan post-mortem dan menyembunyikannya dari orang-orang.
Saya kemungkinan besar akan membuat masalah baru untuk diskusi meskipun (seperti yang saya harapkan) ;-).
Pada tingkat tinggi, saya berencana untuk meliput:

1. Bagaimana masalah ini lolos ke rilis? Bagaimana cara mencegah situasi seperti itu di masa depan?
2. Mengapa perlu waktu 6 bulan untuk memperbaikinya? Mengapa tidak diperlakukan / dikomunikasikan sebagai masalah berdampak tinggi sebelumnya? Bagaimana mengenali dan bereaksi terhadap masalah berdampak tinggi lebih dini di masa depan?
3. Masalah lain (mis. Komunikasi secara keseluruhan)

Juga, jika kami menemukan sesuatu yang rusak / tidak bekerja dengan benar dengan 4.3.1 (mis. @Georgiosd temukan di atas ), kami harus menyebutkannya di sini untuk kesadaran, tetapi ambil detail ke masalah terpisah untuk diskusi / tindak lanjut yang lebih mudah.

Terima kasih @karelz (dan Tim MS). Saya akan tetap berlangganan utas ini. 👍

Terus berjuang dalam pertarungan yang bagus, tim! 💯

Saya juga harus berterima kasih kepada @ chadwackerman2

Selamat untuk semuanya sekali lagi karena telah menyelesaikan salah satu bug paling mengganggu dalam sejarah .NET :)

@ Karelz senang melakukannya, tetapi saya bertanya-tanya apakah ini adalah perilaku yang diharapkan?

@georgiosd Saya tidak tahu - akan lebih mudah untuk membahasnya dalam masalah terpisah ;-) (termasuk menarik ahli yang tepat)

Terima kasih telah mendorong pekerjaan ini, @karelz

Saya tahu saya terlambat dengan pemeriksaan mayat di sini, maaf.
Saya tidak lupa, saya hanya belum melakukannya karena prioritas yang lebih tinggi (perencanaan / pelacakan 2.0, melihat lebih dalam masalah pengalihan pengikatan yang muncul di sini juga - dotnet / runtime # 17770)
Saya akan berusaha keras menyelesaikan bedah mayat dalam 1-2 minggu ke depan.

Hai, Bagus semua yang terlibat dalam menyelesaikan ini. Tidak dapat mengatakan saya memahami semua mur dan baut tetapi satu hal yang masih tidak saya mengerti adalah mengapa ini hanya terjadi ketika kami meningkatkan solusi kami dari VS 2015 Pembaruan 3 ke VS 2017. Solusi yang dimaksud adalah serangkaian proyek ASP.Net Core yang menargetkan .net framework 4.6. Masalah dipicu oleh penggunaan Azure KeyVaultClient kami.

Terima kasih, Donal

Hai @ karelz ,

FileNotFoundException: Tidak dapat memuat file atau perakitan 'System.Net.Http, Versi = 4.1.1.0, Budaya = netral, PublicKeyToken = b03f5f7f11d50a3a'. Sistem tidak dapat menemukan berkas yang dicari.

Di sini .csproj saya

netcoreapp1.1

$ (PackageTargetFallback); portable-net45 + win8 + wp8 + wpa81;

aspnet-IbmVcaCore-5aa05652-04e7-4a42-9fd6-8dbc1c8b98fe

@parismiguel menyesal mendengarnya :(. Apakah Anda memiliki bindingRedirects dari 4.0.0.0 ke 4.1.1.0 di aplikasi Anda?

<dependentAssembly> 
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" /> 
</dependentAssembly> 

Kami sedang mencari cara untuk membuat kisah bindingRedirects lebih lancar: https://github.com/dotnet/corefx/issues/9846#issuecomment -287941109

PEMBARUAN: Melihat kesalahan Anda, tampaknya masalahnya adalah versi 4.1.1.0 Anda tidak ditemukan. Dapatkah Anda memeriksa direktori aplikasi Anda jika versi perakitan yang benar benar-benar ada?

@karelz itu cepat, terima kasih banyak! Saya telah melihat hal bindingRedirects di posting sebelumnya tetapi saya tidak yakin di mana harus meletakkannya ... Saya telah mencoba di dalam .csproj saya tetapi saya mendapat kesalahan (dilampirkan sebagai .txt) Mengenai versi 4.1.1.0 I ' Saya tidak yakin untuk mengikuti ... Bukankah saya seharusnya meningkatkannya ke 4.3.1?

IbmVcaCore.csproj.txt

Binding redirect masuk ke file app.config atau web.config Anda:

Lihat ini untuk detailnya:
https://msdn.microsoft.com/en-us/library/7wd6ex19 (v = vs.110) .aspx

Hai @davidsh , terima kasih atas bantuan Anda!
Proyek saya tidak memiliki file-file itu ... ini adalah proyek NET Core yang dibangun menggunakan template Visul Studio 2017 ... apa yang saya lewatkan?

Re: 4.3.1 vs. 4.1.1 - 4.3.1 adalah versi paket NuGet, 4.1.1.0 adalah versi rakitan (ildasm / ILSpy / VS akan menunjukkannya kepada Anda).
Versi NuGet vs. assembly agak membingungkan dan sulit untuk menghubungkan yang mana. Itu ada di daftar saya untuk melihat lebih dalam jika kita dapat menghubungkan titik-titik melalui dokumentasi (misalnya di halaman NuGet).

Jika Anda menggunakan .NET Core, Anda tidak memerlukan bindingRedirects dan terlebih lagi, masalah ini TIDAK memengaruhi Anda sama sekali. Masalah ini khusus untuk Desktop (= .NET Framework).
Paket 4.3.1 NuGet hanya memodifikasi rakitan Desktopnya, bukan rakitan .NET Core.

Jika Anda masih mengalami masalah, laporkan bug baru dan beri tag saya di sana. Masalah ini diledakkan ke cukup banyak orang (karena berdampak besar), masalah Anda tidak terkait dengannya (setidaknya terlihat seperti itu), jadi mari bersikap baik terhadap notifikasi / kotak masuk GH semua orang.

Kepada semua orang : Saya telah membuat edisi baru dotnet / corefx # 17522 untuk melacak mayat yang saya janjikan.
Sayangnya, saya belum membuat banyak kemajuan ke arahnya :( ... tetapi setidaknya semua orang yang tertarik dapat mulai mengikuti masalah itu dan menghindari potensi gangguan pada masalah ini (mencoba membantu orang-orang fokus pada apa yang mereka minati).

@ karelz terima kasih, saya akan mengikuti instruksi Anda dan memposting di pelacak masalah baru Anda. Salam.

@parismiguel bukan pada edisi baru yang saya buat, harap buat yang baru. Yang saya buat (# 17522) adalah untuk analisis post-mortem mengapa masalah ini (# 11100) butuh waktu lama untuk diselesaikan.

terima kasih @karelz dan permintaan maaf saya yang tulus karena telah mengacaukan topik ini .... berharap mendapatkan bantuan di topik baru seperti yang diinstruksikan. Salam hangat,

Sepertinya saya telah mengalami ini melalui badai yang sempurna.

Saya menggunakan pratinjau Azure Functions dengan kombinasi Azure Key Vault (2.0.6) dan Octopus Client (4.15.3).

Saya telah mencoba mengupgrade ke System.Net.Http menjadi 4.3.2 namun masih gagal ketika mencoba menggunakan Key Vault .

Ada tips?

@karel_jogja

Bisakah Anda memastikan bahwa assembly dari paket 4.3.2 nuget benar-benar digunakan saat runtime? (sudah diperbaiki di 4.3.1)