Runtime: Pertanyaan: Dukungan serialisasi maju dari .Net Core 1.0

https://github.com/dotnet/corefx/blob/2b15de70c1cf9f585c4878a722de4dbe42b4940b/Documentation/project-docs/porting.md#binary -serialization

Hai @joshfree , sayangnya itu adalah dokumen yang menyebabkan kebingungan. Di luar saran di sana, JSON.NET melakukan serialisasi json, protobuf-net melakukan serialisasi biner, dan datacontractserializer melakukan serialisasi xml. Masalahnya, jika saya ingin melakukan serialisasi biner. Meskipun protobuf-net adalah pustaka yang bagus, itu terbatas. Dari Protobuf-nets repo, jenis yang didukung adalah:
kelas khusus yang:
ditandai sebagai kontrak data
memiliki konstruktor tanpa parameter
untuk Silverlight: bersifat publik
banyak primitif umum dll
array dimensi tunggal: T []
Daftar / IList
Kamus / IDictionary
semua jenis yang mengimplementasikan IEnumerable dan memiliki metode Add (T)
Di masa lalu ini baik-baik saja karena binaryformatter selalu ada, tetapi ini tidak akan menjadi masalahnya lagi? Apa cara serialisasi biner yang disarankan untuk jenis yang tidak didukung oleh protobuf-net? Bangun sendiri?
Saya masih sangat pemula di semua teknologi ini jadi saya mungkin benar-benar kehilangan poin pada sesuatu.

Juga, tidak satupun dari mereka yang dapat diandalkan untuk membuat serial pengecualian (dan menyimpan semua data yang relevan), seperti yang diperlukan misalnya dalam komputasi terdistribusi (Azure ...).

@cdrnet poin adalah poin mencuat besar untuk orang-orang seperti Orleans guys IIRC.

Hai @SamuelCox , sesuai petunjuk porting @joshfree , kami (tim serialisasi) tidak berencana menghadirkan serializer biner ke .NET Core. Tanpa remote .NET dan konsep AppDomain di .NET Core, serializer biner jauh lebih berguna. Harap pertimbangkan serializers lain di .NET Core seperti DataContractSerializer (DCS), DataContractJsonSerializer (DCJS) dan XmlSerializer, yang telah dan akan terus didukung di .NET Core. Tentu saja, Anda juga dapat mempertimbangkan pembuat serial pihak ketiga yang dibangun di atas .NET Core. Mungkin saya harus mengajukan pertanyaan - apakah Anda secara khusus mencari serializer yang memiliki muatan serialisasi biner (jika ya, mengapa) atau apakah Anda hanya mencari serializer yang dapat membuat serial / deserialisasi jenis yang Anda pedulikan? Kami telah berusaha keras untuk mendukung serialisasi sebagian besar jenis .NET dengan DCS, DCJS dan XmlSerializer. Jangan ragu untuk memberi tahu kami jika Anda mengalami masalah tertentu yang tidak dapat dilakukan oleh serializer ini.

@cdrnet dan @ RichiCoder1 , terima kasih atas tanggapan Anda. Ada masalah terbuka dotnet / coreclr # 2715 untuk diskusi serialisasi pengecualian. Tolong tambahkan tanggapan Anda di sana. Saya setuju bahwa penting untuk dapat membuat serial pengecualian dalam sistem terdistribusi. Saat ini, tanpa ISerializable di .NET Core, kami tidak dapat membuat serial pengecualian seperti yang kami lakukan dalam framework .NET penuh.

Hai @zhenlan , saya mungkin seharusnya menyebutkan awalnya, alasan utama saya menginginkan binaryformatter adalah untuk (de) membuat serial pengecualian, dan kelas khusus yang berisi pengecualian.

Kasus penggunaan utama adalah sistem terdistribusi, membuat serialisasi beberapa objek ke array byte sehingga saya dapat mengirimkannya melalui tcp / ip. Saya menyadari itu mungkin lebih umum untuk membuat serial objek ke JSON melalui JSON.NET misalnya, mengubah string itu menjadi array byte, mengirimkannya melalui tcp / ip dan membalikkan seluruh proses sekali di ujung yang lain. Tapi itu memiliki lebih banyak overhead daripada hanya membuat serial ke array byte dan deserialisasi dari array byte ke objek yang Anda inginkan.

Terima kasih @SamuelCox untuk klarifikasinya. Saya rasa saya memahami kekhawatiran Anda sekarang. Serialisasi biner adalah sistem tertutup. Saya akan merekomendasikan Anda untuk mempertimbangkan serialisasi berbasis standar yang lebih terbuka lainnya seperti Xml atau JSON. Anda mungkin tidak membutuhkannya hari ini, tetapi ini memberi Anda lebih banyak fleksibilitas jika Anda perlu mendukung serialisasi antara platform yang berbeda atau dengan bahasa / skrip pemrograman yang berbeda di masa mendatang. Tidak yakin seberapa besar data Anda nantinya, tetapi jika ukuran payload benar-benar mengkhawatirkan, Anda dapat mempertimbangkan kompresi data, yang merupakan fitur bawaan untuk banyak server saat ini.

Saya lebih memikirkan kinerja overhead, daripada apa pun. Sepertinya banyak operasi yang terbuang percuma dibandingkan dengan serialisasi dan deserialisasi langsung dari objek ke biner dan sebaliknya. Saya rasa saya senang menutup ini sekarang karena setidaknya saya telah menerima klarifikasi. Saya masih berpikir ada celah antara 4.6 dan inti 1.0 yang dibuka di sini, tapi saya mengerti mengapa.

Agak terlambat untuk percakapan, tapi ini dua sen saya:

Saya pikir itu akan menjadi kesalahan untuk percaya bahwa utilitas BinaryFormatter terbatas pada remote .NET dan AppDomains. Apa yang membedakan BinaryFormatter (usang) dari yang lebih baru adalah kemampuannya untuk membuat serialisasi objek .NET yang lebih eksotis, termasuk closure, subtipe, dan grafik siklik. Tidak ada serializers lain yang tercantum di utas saat ini yang mampu melakukan semua ini. Bukan kebetulan bahwa banyak kerangka kerja terdistribusi mutakhir, termasuk proyek Microsoft seperti Prajna dan Mobius (alias SparkCLR) mengandalkan BinaryFormatter untuk berfungsi. Ini tidak eksklusif untuk dunia .NET: Spark menggunakan serializer biner Java lama dan lambat untuk penutupan serialisasi.

Ada serializer (format non-biner) lain yang mereplikasi kapabilitas BinaryFormatter, termasuk library FsPickler kita sendiri yang digunakan oleh framework mbrace. Namun, CoreCLR telah menghentikan banyak API kunci, sejauh yang saya percaya port perpustakaan ke CoreCLR adalah upaya yang tidak praktis.

Dari perspektif bisnis, akan sangat bagus untuk melihat CoreCLR menjadi pesaing lintas platform yang layak untuk JVM dalam komputasi terdistribusi / domain data besar. Ini tidak dapat terjadi tanpa platform yang menawarkan dukungan serialisasi yang andal untuk POCO dan penutupan (biner atau lainnya).

Apakah Anda ingin orang benar-benar menggunakan .NET Core atau ini hanya membuang-buang waktu seperti Silverlight? Jika Anda ingin orang benar-benar menggunakan .NET Core, buat itu berfungsi. Jika orang membutuhkan serialisasi, buatlah - tidak ada basa-basi! Inilah orang-orang yang benar-benar menggunakan produk Anda, dan pendapat mereka jauh lebih berharga daripada kebijaksanaan kolektif setiap karyawan Microsoft. Anda lihat orang-orang ini, tidak seperti Microsoft, sebenarnya membangun hal-hal penting misi di .NET dan jika Anda ingin .NET Core menjadi apa pun, Anda harus berhenti merusak kegunaannya. Tidak ada yang meminta Anda untuk membuang .NET untuk melakukan penulisan ulang penuh, Anda bisa saja memindahkan kerangka .NET penuh dari waktu ke waktu. Anda pasti sudah selesai sekarang.

Lihat juga https://github.com/dotnet/coreclr/issues/2715

fwiw, CSLA .NET mengandalkan serialisasi fidelitas penuh karena bertumpu pada konsep objek seluler.

Ketika Silverlight hadir dan tidak memiliki BinaryFormatter atau NetDataContractSerializer, _and_ memiliki semua batasan refleksi yang buruk, kami akhirnya menerapkan serializer kami sendiri yang menggunakan refleksi minimal dan tidak bergantung pada BF atau NDCS.

Di dunia pasca-Silverlight, masalahnya tetap ada, karena BF / NDCS tidak tersedia secara andal di UWP, WinRT, .NET Core, dll.

Jadi saya pikir ada argumen yang harus dibuat bahwa serializer full-fidelity _should_ ada, tetapi itu hanya benar-benar berguna (setidaknya imo) jika ada di semua berbagai inkarnasi .NET.

@rockfordlhotka @opinionmachine @eiriktsarpalis Senang mendengar lebih banyak orang merasakan hal yang sama, meskipun saya merasa akan lebih produktif jika dikatakan sedikit lebih sopan @opinionmachine , tetapi masing-masing kepada mereka sendiri. Saat masalah ini ditutup, saya membayangkan tim corefx tidak lagi memantaunya. Saya menyarankan Anda untuk meluruskan kekhawatiran Anda pada dotnet / coreclr # 2715 seperti yang disebutkan oleh @forki

Saya harus setuju bahwa menghapus serialisasi (serta appdomains) adalah ide yang buruk. Saya benar-benar tidak berpikir keputusan itu dipikirkan dengan baik.

Namun apa yang benar-benar membuat saya pergi adalah MS tidak merilis kode yang diperlukan untuk mendukung appdomains, dll dan menyerahkannya kepada komunitas untuk melakukan apa yang mereka inginkan.

Mengingat bahwa coreclr seharusnya menjadi versi "server" dari .net, banyak fitur server yang tertinggal.

Contoh kasus: diputuskan untuk meninggalkan StackTrace / StackFrame dari corefx karena "disalahgunakan" oleh beberapa pengembang, dan karena itu jarang digunakan (menurut MS). Saya percaya mereka sadar akan hal itu (setelah satu ton reaksi) tapi maksud saya benarkah? Siapa yang memikirkan hal ini?

Untuk apa nilainya, saya sebenarnya sangat senang dengan .net core dan berpikir ini adalah langkah maju yang bagus untuk .net, peningkatan kinerjanya brilian, masih memiliki hampir semua fitur yang saya pedulikan, dan ini lintas platform. Ini benar-benar satu-satunya masalah yang saya miliki dengannya. Ada banyak manfaat untuk menjatuhkan fitur jika sesuai, lihat saja seberapa suksesnya perjalanan dengan pendekatan minimalisnya. Bukan berarti saya mengatakan .net harus sesedikit mungkin, itu akan konyol, saya pribadi tidak setuju dengan desain minimalis, TAPI yang ingin saya katakan adalah MS tidak boleh difitnah karena menjatuhkan fitur tertentu.

@SamuelCox , terima kasih! :-)

Dan untuk mengulangi, API hilang dari .NET Core karena berbagai alasan. Beberapa dari celah ini dapat diperbaiki dengan mudah (dan kami memperbaikinya); beberapa lebih sulit untuk diperbaiki. Tetapi kami ingin mendengar dari Anda tentang masalah yang Anda hadapi (seperti rangkaian utas tentang serialisasi ini) dan kami ingin menemukan cara untuk membuka blokir skenario Anda.

Serialisasi biner dari grafik objek arbitrer, di seluruh versi kerangka tunggal itu sulit; melintasi kerangka kerja yang berbeda bahkan lebih sulit. Dan yang saya maksud dengan 'keras' bukan berarti sulit bagi kita untuk melakukan pekerjaan. Maksud saya, hal itu memiliki implikasi yang menjangkau cukup jauh untuk tujuan lain dari platform (tujuan yang menurut saya kita semua sama): keamanan, kinerja, keandalan.

Json.NET + TypeNameHandling.All + PreserveReferencesHandling.All + MemberSerialization.Fields membawa Anda hampir ke sana. Tidak ada FormatterServices.GetUninitializedObject, jadi konstruktor harus tersedia.

Tidak ada FormatterServices.GetUninitializedObject

Ini adalah masalah inti yang saya pikir - kerangka kerja serialisasi berbasis refleksi eksternal dapat membantu Anda, tetapi API khusus ini harus ada di sana untuk memungkinkan kerangka kerja ini ditulis. Rekomendasi saya kepada tim CoreCLR adalah menambahkan kembali API ini.

Pada titik tertentu komunitas .NET (komersial atau lainnya) harus berhenti bergantung pada Microsoft yang selalu memegang tangan mereka. Jika ada kebutuhan yang begitu masif untuk hal ini, dan sudah cukup lama diketahui bahwa tidak ada, lalu mengapa belum ada kegiatan masyarakat untuk memberikan alternatif? Json.NET adalah alternatif komunitas dan kami menggunakannya sepanjang waktu. Heck kode sumber bahkan tersedia di sumber referensi

Tampaknya berhasil untuk platform lain dan saya yakin berhasil dengan baik di NET .. menurut saya, ini adalah peluang utama untuk membuat proyek (yang tampaknya ada permintaan) dan dapatkan di awal mengisi kekosongan itu dengan alternatif komunitas

Kami ingin @thecodejunkie , tetapi kami masih memerlukan waktu proses untuk mengekspos API yang sesuai agar hal ini terjadi.

FYI: ini berfungsi pada .NET Core: Type appDomainType = Type.GetType("System.AppDomain"); . Dan ya, ini memungkinkan Anda melakukan banyak hal ....

Hanya untuk mengatakan bahwa kami telah meningkatkan respons server ujung depan kami sebesar 30%, mengurangi dari 12 inti pada beban maksimum menjadi 2 inti pada beban maksimum, menurunkan ukuran cache redis dari 1,7Gb menjadi 350Mb secara keseluruhan mengurangi hosting Azure kami sebesar 20% (bit lebih sungguh)

Anda dapat menebaknya BinaryFormatter!

Kami menggunakan netdatacontractserializer

Saya datang ke sini mencari jawaban untuk .Net 4.6.1 menjadi jauh lebih lambat dengan BinaryFormatter.

Pemahaman saya bahwa API ini akan kembali (serialisasi). Meskipun tidak ideal dan memiliki beberapa masalah tentang menjadi rapuh, setidaknya itu harus memungkinkan kode yang ada untuk terus berjalan.

Ada juga nilai dalam mendesain serializer objek sederhana lainnya untuk kerangka inti, yang juga ringan tetapi lebih tangguh untuk lintas mesin dan kemungkinan masalah lintas versi.

Ada juga masalah keamanan selain kerapuhan.

@blowdart WRT security, maksud Anda hal-hal seperti ini https://blog.scrt.ch/2016/05/12/net-serialiception/?

Ya, itulah hal yang seperti itu. Semua format serialisasi yang menyertakan tipe di dalamnya berbahaya, seperti yang ditemukan Java tahun ini. Saya sangat senang ketika kami menghentikan serialisasi biner karena kami menghapus seluruh kelas kerentanan.

@migueldeicaza @blowdart @SamuelCox
Serializers diperlukan tidak hanya untuk mengirim sesuatu, tetapi bahkan dalam proses.
Serializers biner, jika dilakukan dengan benar, mengungguli seluruh heap objek asli secara bersamaan saat menyimpan 10 juta objek dalam proses.
Lihat ini:
https://www.infoq.com/articles/Big-Memory-Part-2

API serialisasi mutlak diperlukan untuk pemrograman cluster yang waras.
Sangat tidak nyaman untuk melakukan teleportasi instance objek CLR -> teks -> CLR, ini adalah overhead yang sangat besar.
Mungkin ini bukan kesalahan untuk mengeluarkan BinaryFormatter, karena SANGAT lambat dan datagram sangat besar, tetapi
itu adalah satu-satunya serializer di pasaran selain NFX.Slim yang mendukung semantik serialisasi CLR penuh.
Lihat grafik kecepatan dan ukuran terperinci:
http://aumcode.github.io/serbench/

Dapat dialihkan dengan keluarga [OnSer / Deser] TIDAK masuk akal untuk teleportasi dalam platform.
Itu tidak wajib, seperti di NET lama. Mengapa tidak menyimpannya.
Setidaknya mendukungnya dalam koleksi yang kompleks (yaitu Kamus), itu tidak sulit sama sekali.

Membuat semua orang menggunakan JSON -adalah ide yang sangat buruk karena kali ini lebih lambat dari serializer biner (bukan BinaryFormatter).
Sepertinya semua orang membangun aplikasi mirip Twitter tanpa logika bisnis?

@itadapter memang memiliki satu nit untuk dipilih, yaitu JSON.Net bukan satu-satunya game serialisasi di kota. Ada juga MsgPack, Protobuf, dan Bond milik Microsoft sendiri. (Sunting: tautan kedua Anda memanggil Protobuf). Json bukan satu-satunya pilihan. Namun, masih ada masalah besar dari serialisasi objek .Net dengan semantik menarik (Pengecualian).

@ Richi
Ya tentu saja. Seperti yang terlihat pada grafik di bawah ini, yaitu JIL adalah serilizer JSON tercepat, namun tidak ada serializer berbasis teks yang dapat menyentuh, yang biner. Protobuf sangat cepat dengan mengorbankan ketidakmampuannya untuk mendukung polimorfisme sejati dan grafik kompleks.

Yang saya katakan adalah:

• Binary Serializers selalu lebih baik untuk objek domain bisnis, terutama bila Anda memiliki banyak data numerik
• Serializers, secara umum diperlukan TIDAK HANYA untuk memindahkan data antar sistem, tetapi bahkan di dalam proses seperti yang ditunjukkan oleh pendekatan Big Memory. Ini bukan pendekatan biasa, tetapi sangat masuk akal (mis. Cache dan traversal grafik sosial dalam memori)
• "Teleportasi" adalah teknik yang mirip dengan MS Remoting, yang sejujurnya gagal. Remoting secara umum bila dilakukan dengan benar (tanpa kerumitan yang mengerikan) SANGAT SANGAT berguna dalam sistem cluster. Kami menggunakan pendekatan ini sepanjang waktu dan pemrograman JAUH lebih mudah dengan objek asli - saat Anda dapat mengambil objek DOMAIN dan mengirimnya ke metode lain sebagaimana adanya, baik itu di mesin ini atau yang berdekatan di rak

Tolok ukur "Orang Biasa", menampilkan serializer populer:
http://aumcode.github.io/serbench/Specimens_Typical_Person/web/overview-charts.htm

Untuk berjaga-jaga jika ada orang di utas ini yang tidak menyadarinya, serializer biner termasuk ISerializable dll. Telah tersedia di corefx
https://github.com/dotnet/corefx/tree/master/src/System.Runtime.Serialization.Formatters

@zhenlan Bagian dari pekerjaan .NetStandard2.0 yang saya asumsikan?

@ RichiCoder1 Ya, benar.

@zhenlan sangat bagus!

@zhenlan Sepertinya saya tidak dapat menemukan Atribut Serializable yang tersedia di pratinjau Standar. Apakah saya baru saja melewatkannya?

@justinhelgerson seharusnya ada di sana.

Apakah Anda menginstal 2.0 Preview1 SDK seperti yang diperintahkan dalam posting blog pengumuman ?

Setelah Anda membuat proyek Inti .NET, dapatkah Anda memastikan file .csproj memiliki <TargetFramework>netstandard2.0</TargetFramework> jika Anda membuat Perpustakaan Kelas atau <TargetFramework>netcoreapp2.0</TargetFramework> jika Anda membuat Aplikasi Konsol?

BTW, karena banyak orang di utas ini tertarik dengan serializer biner, Anda mungkin tertarik dengan diskusi di dotnet / corefx # 19119, yaitu tentang penskalaan kembali [Serializable] untuk .NET Core 2.0. Beri tahu kami di sana jika Anda memiliki umpan balik.

@zhenlan Terima kasih banyak atas tanggapan cepat Anda. Saya telah menginstal pratinjau melalui NuGet tetapi saya tidak memperbarui file .csproj saya secara manual. Itu berhasil! Saya akan membaca tentang penskalaan kembali dan memberikan masukan jika itu akan memengaruhi kasus penggunaan kami.

@justinhelgerson , perubahan skala kembali tidak ada di Pratinjau 1 (kami masih mengerjakannya!), tetapi Anda dapat mencobanya dengan build harian atau pratinjau mendatang dalam waktu dekat.