Runtime: 質問：.Net Core1.0以降のシリアル化のサポート

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

こんにちは@joshfree 、はい、残念ながらそれが混乱を引き起こした文書でした。 そこでの提案のうち、JSON.NETはjsonシリアル化を行い、protobuf-netはバイナリシリアル化を行い、datacontractserializerはxmlシリアル化を行います。 それに関する問題は、バイナリシリアル化を実行したい場合です。 protobuf-netは優れたライブラリですが、限られています。 Protobuf-netsリポジトリから、サポートされているタイプは次のとおりです。
次のようなカスタムクラス：
データ契約としてマークされています
パラメータのないコンストラクタを持っている
Silverlightの場合：公開されています
多くの一般的なプリミティブなど
一次元配列：T []
リスト/ IList
辞書/ IDictionary
IEnumerableを実装し、Add（T）メソッドを持つ任意のタイプ
過去には、binaryformatterが常に存在していたため、これは問題ありませんでしたが、これはもはや当てはまりませんか？ protobuf-netによるサポートされていないタイプのバイナリシリアル化の推奨される方法は何ですか？ 自分で構築しますか？
私はまだこれらのテクノロジーのすべてにかなりの初心者なので、何かの要点を完全に見逃しているかもしれません。

また、分散コンピューティング（Azure ...）などの必要に応じて、例外を確実にシリアル化（および関連するすべてのデータを保持）することはできません。

@cdrnetポイントは、Orleansの男IIRCのような男にとって大きなこだわりです。

こんにちは@SamuelCox 、移植ガイダンス@joshfreeが指摘したように、私たち（シリアル化チーム）はバイナリ

@cdrnetと@ RichiCoder1 、フィードバックをありがとう。 例外のシリアル化の議論については、未解決の問題dotnet / coreclr＃2715がありました。 そこにフィードバックを追加してください。 分散システムで例外をシリアル化できることが重要であることに同意します。 現在、.NET CoreでISerializableがないと、完全な.NETFrameworkのように例外をシリアル化することはできません。

こんにちは@zhenlan 、私はおそらく最初に言及すべき

主な使用例は分散システムで、オブジェクトをバイト配列にシリアル化して、tcp / ipで送信できるようにします。 たとえば、JSON.NETを介してオブジェクトをJSONにシリアル化し、その文字列をバイト配列に変換し、tcp / ipを介して送信し、もう一方の端でプロセス全体を逆にすることがおそらくより一般的であると思います。 ただし、これには、バイト配列にシリアル化して、バイト配列から目的のオブジェクトに逆シリアル化するよりもはるかに多くのオーバーヘッドがあります。

明確化してくれた@SamuelCoxに感謝します。 私はあなたの懸念を今理解していると思います。 バイナリシリアル化は緊密なシステムです。 XmlやJSONなど、他のよりオープンな標準ベースのシリアル化を検討することをお勧めします。 現在は必要ないかもしれませんが、将来、異なるプラットフォーム間または異なるプログラミング言語/スクリプトでシリアル化をサポートする必要がある場合に備えて、柔軟性が向上します。 データの大きさはわかりませんが、ペイロードのサイズが本当に懸念される場合は、データ圧縮を検討できます。これは、現在多くのサーバーに組み込まれている機能です。

私は何よりもパフォーマンスのオーバーヘッドについて考えていました。 オブジェクトからバイナリに直接シリアル化および逆シリアル化するのに比べて、多くの無駄な操作のようです。 少なくとも説明を受けたので、これを閉じることができてうれしいと思います。 ここで開かれている4.6とコア1.0の間にはまだギャップがあると思いますが、その理由は理解しています。

会話に少し遅れましたが、ここに私の2セントがあります：

BinaryFormatterのユーティリティが.NETリモーティングとAppDomainsに限定されていると考えるのは間違いだと思います。 （廃止された）BinaryFormatterを新しい対応するものと区別するのは、クロージャー、サブタイプ、循環グラフなど、よりエキゾチックな.NETオブジェクトをシリアル化するその純粋な機能です。 現在のスレッドにリストされている他のシリアライザーは、これらすべてを実行できません。 PrajnaやMobius（別名SparkCLR）などのMicrosoftプロジェクトを含む、多くの最先端の分散フレームワークが機能するためにBinaryFormatterに依存しているのは偶然ではありません。 これは.NETの世界に限ったことではありません。Sparkはクロージャーのシリアル化に古くて遅いJavaバイナリシリアライザーを使用しています。

mbraceフレームワークで使用される独自のFsPicklerライブラリなど、BinaryFormatterの機能を複製する他の（非バイナリ形式の）シリアライザーがあります。 ただし、CoreCLRは多くの主要なAPIを非推奨にしており、ライブラリをCoreCLRに移植することは非現実的な試みであると私は信じています。

ビジネスの観点からは、CoreCLRが分散コンピューティング/ビッグデータドメインでJVMの実行可能なクロスプラットフォームの競争相手になるのを見るのは素晴らしいことです。 これは、POCOとクロージャ（バイナリまたはその他）の信頼性の高いシリアル化サポートを提供するプラットフォームなしでは発生しません。

peopeに実際に.NETCoreを使用させたいですか、それともSilverlightのように時間の無駄ですか？ 人々に実際に.NETCoreを使用してもらいたい場合は、それを機能させます。 シリアル化が必要な場合は、それを構築してください-バックトークはありません！ これらは実際にあなたの製品を使用している人々であり、彼らの意見はすべてのマイクロソフト従業員の集合的な知恵よりもはるかに価値があります。 これらの人々は、Microsoftとは異なり、実際には.NET上でミッションクリティカルなものを構築していることがわかります。.NETCoreを何かにしたい場合は、その有用性を損なうのをやめなければなりません。 完全な書き換えを行うために.NETを捨てるように求められた人は誰もいませんでした。時間の経過とともに、完全な.NETフレームワークを移植することができたはずです。 あなたはもう終わっていただろう。

https://github.com/dotnet/coreclr/issues/2715も参照して

fwiw、 CSLA .NETは、モバイルオブジェクトの概念に基づいているため、完全に忠実なシリアル化に依存しています。

Silverlightが登場し、BinaryFormatterまたはNetDataContractSerializerがなかったとき、_and_にはこれらの厄介な反射制限がすべてあり、最小限の反射を使用し、BFまたはNDCSに依存しない独自のシリアライザーを実装することになりました。

BF / NDCSはUWP、WinRT、.NET Coreなどで確実に利用できないため、Silverlight以降の世界では問題が残ります。

したがって、完全忠実なシリアライザーが存在する必要があるという議論があると思いますが、それが.NETのさまざまな化身すべてに存在する場合にのみ、実際に役立ちます（少なくともimo）。

@rockfordlhotka @opinionmachine @eiriktsarpalisもっと多くの人が同じように感じるのを聞いてうれしいですが、もう少し丁寧に@opinionmachineと言われたらもっと生産的になると思いますが、それぞれが独自のものです。 この問題は解決されたので、corefxチームはもはやそれを監視していないと思います。 @forkiが述べているように、 正すことをお勧めします

シリアル化（およびアプリドメイン）を削除することはひどい考えだったことに同意する必要があります。 決定がよく考えられていたとは本当に思いません。

しかし、本当に私を動かしているのは、MSがappdomainsなどをサポートするために必要なコードをリリースせず、コミュニティに任せて、彼らが何をするかを実行したことです。

coreclrが.netの「サーバー」バージョンであると想定されていることを考えると、多くのサーバー機能がフロアに残されていました。

適切な例：StackTrace / StackFrameは、一部の開発者によって「誤用」され、ほとんど使用されなかったため（MSによると）、corefxから除外することが決定されました。 私は彼らが（たくさんの反発の後で）それについて彼らの感覚に達したと信じています、しかし私は本当に意味しますか？ 誰がこのことを考えますか？

価値のあることとして、私は実際に.netコアに本当に満足しており、.netにとって大きな前進だと思います。パフォーマンスの向上は素晴らしく、私が気にかけている機能のほとんどすべてを備えており、クロスプラットフォームです。 これは本当に私が抱えている唯一の問題です。 必要に応じて機能を削除することには多くの価値があります。最小限のアプローチで成功したかどうかを確認してください。 .netが行くのと同じくらいミニマルであるべきだと言っているわけではありません、それはばかげているでしょう、私はミニマルなデザインに個人的に同意しません、しかし私が言おうとしているのはMSが特定の機能を落とすことで非難されるべきではないということです。

@SamuelCox 、ありがとう！ :-)

繰り返しになりますが、APIは多くの理由で.NETCoreにありません。 これらのギャップのいくつかは簡単に修正できます（そして私たちはそれらを修正しています）。 修正が難しいものもあります。 しかし、私たちはあなたが直面している問題（シリアル化に関するこのスレッドのセット全体のような）についてあなたから聞きたいので、あなたのシナリオのブロックを解除する方法を見つけたいと思います。

単一のフレームワークのバージョン間での任意のオブジェクトグラフのバイナリシリアル化は困難です。 異なるフレームワーク間でさらに困難です。 そして、「難しい」とは、私たちが仕事をするのが難しいという意味ではありません。つまり、プラットフォームの他の目標（私たち全員が共有していると思う目標）、つまりセキュリティ、パフォーマンス、信頼性にかなりの影響を及ぼしているということです。

Json.NET + TypeNameHandling.All + PreserveReferencesHandling.All + MemberSerialization.Fieldsを使用すると、ほぼすべての場所にアクセスできます。 FormatterServices.GetUninitializedObjectはありませんが、コンストラクターが使用可能である必要があります。

FormatterServices.GetUninitializedObjectはありません

これが私が考える中心的な問題です。外部リフレクションベースのシリアル化フレームワークは長い道のりを歩むことができますが、これらのフレームワークを記述できるようにするには、この特定のAPIが必要です。 CoreCLRチームへの私の推奨事項は、このAPIをに戻すことです。

ある時点で、.NETコミュニティ（商用またはその他）は、Microsoftが常に手を握っていることに依存することをやめなければならないでしょう。 これには非常に大きな要件があり、利用できないことがかなり前から知られている場合、代替手段を提供するためのコミュニティ活動がなかったのはなぜですか？ Json.NETはコミュニティの代替手段であり、私たちは常にそれを使用しています。 ソースコードはリファレンスソースでも入手できます。

他のプラットフォームでもうまくいくようで、.NETでもうまくいくと確信しています。私の見方では、これはプロジェクトを作成する絶好の機会です（需要があるようです）。その空白をコミュニティの代替案で埋める早い段階で

@thecodejunkieしたいのですが、これを実現するには、ランタイムで適切なAPIを公開する必要があります。

参考：これは.NET Coreで動作します： Type appDomainType = Type.GetType("System.AppDomain"); 。 そして、はい、それはあなたにたくさんのことをさせましょう....

フロントエンドサーバーの応答性が30％向上し、最大負荷時の12コアから最大負荷時の2コアに減少し、redisキャッシュサイズが1.7Gbから350Mbに減少し、Azureホスティングが全体で20％（ビット）減少したと言っても過言ではありません。もっと本当に）

あなたはそれをBinaryFormatterだと思いました！

netdatacontractserializerを使用していました

BinaryFormatterでは.Net4.6.1の速度が非常に遅いという答えを探してここに来ました。

これらのAPIが戻ってくる（シリアル化）ことは私の理解です。 これは理想的ではなく、脆弱であることにいくつかの問題がありますが、少なくとも既存のコードを実行し続けることができるはずです。

コアフレームワーク用の別の単純なオブジェクトシリアライザーを設計することにも価値があります。これも軽量ですが、クロスマシンおよび潜在的にクロスバージョンの問題に対してより回復力があります。

脆弱性に加えてセキュリティの問題もあります。

@blowdart WRTセキュリティ、 https： //blog.scrt.ch/2016/05/12/net-serialiception/のような意味ですか？

うん、そういうことだ。 Javaが今年発見しているように、その中に型を含むシリアル化フォーマットは危険です。 クラス全体の脆弱性を削除したため、バイナリシリアル化を削除したときは非常に満足していました。

@migueldeicaza @blowdart @SamuelCox
シリアライザーは、送信するだけでなく、処理中にも必要です。
バイナリシリアライザーは、適切に実行されると、処理中の数千万のオブジェクトを格納する場合に、ネイティブオブジェクトヒープ全体を完全に上回ります。
これを参照してください：
https://www.infoq.com/articles/Big-Memory-Part-2

シリアル化APIは、正常なクラスタープログラミングに絶対に必要です。
オブジェクトインスタンスCLR->テキスト-> CLRをテレポートすることは非常に不便であり、大きなオーバーヘッドです。
BinaryFormatterは非常に遅く、データグラムが巨大であるため、削除するのは間違いではないかもしれませんが、
これは、完全なCLRシリアル化セマンティクスをサポートするNFX.Slim以外の市場で唯一のシリアライザーでした。
詳細な速度とサイズのチャートを参照してください。
http://aumcode.github.io/serbench/

[OnSer / Deser]ファミリーでISerializableは、プラットフォーム内のテレポーテーションに非常に意味があります。
古いNETのように、必須ではありません。 保管してみませんか。
少なくとも複雑なコレクション（つまり辞書）でそれをサポートします、それはまったく難しいことではありません。

全員にJSONを使用させることは、バイナリシリアライザー（BinaryFormatterではない）よりも時間がかかるため、絶対に悪い考えです。
誰もがビジネスロジックのないTwitterのようなアプリを構築しているように見えますか？

@itadapterには、選択問題があります。それは、JSON.Netが町で唯一のシリアル化ゲームではないということです。 MsgPack、Protobuf、およびMicrosoft独自のBondもあります。 （編集：2番目のリンクはProtobufを呼び出します）。 Jsonだけが選択肢ではありません。 ただし、興味深いセマンティクス（例外）を使用して.Netオブジェクトをシリアル化することにはまだ大きな問題があります。

@ RichiCoder1
はい、もちろん。 以下のグラフに示されているように、つまりJILは最速のJSONセリライザーですが、テキストベースのシリアライザーはいずれもバイナリのものに触れることができません。 Protobufは、真のポリモーフィズムと複雑なグラフをサポートできないことを犠牲にして、非常に高速です。

私が言っているのは：

• バイナリシリアライザーは、特に数値データが多い場合に、ビジネスドメインオブジェクトに対して常にパフォーマンスが向上します。
• シリアライザーは、一般に、システム間でデータを移動するためだけでなく、ビッグメモリアプローチが示すようにプロセス内でも必要です。 これは一般的なアプローチではありませんが、実用的な意味があります（つまり、キャッシュとメモリ内のソーシャルグラフトラバーサル）
• 「テレポート」は、正直言って失敗したMSRemotingに似たテクニックです。 一般に、正しく実行された場合（恐ろしい複雑さなしで）のリモート処理は、クラスターシステムで非常に役立ちます。 私たちは常にこのアプローチを使用しており、ネイティブオブジェクトを使用するとプログラミングがはるかに簡単になります-DOMAINオブジェクトを取得して、そのまま別のメソッドに送信できる場合は、このマシンまたはラック内の隣接するマシンにあります

人気のあるシリアライザーを示す「TypicalPerson」のベンチマーク：
http://aumcode.github.io/serbench/Specimens_Typical_Person/web/overview-charts.htm

このスレッドの誰かが気付いていない場合に備えて、ISerializableなどを含むバイナリシリアライザーがcorefxで利用可能になっています
https://github.com/dotnet/corefx/tree/master/src/System.Runtime.Serialization.Formatters

@zhenlan私が想定している.NetStandard2.0作業の一部ですか？

@ RichiCoder1はい、正解です。

@zhenlanは素晴らしいです！

@zhenlanStandardのプレビューで使用可能なSerializable属性が見つからないようです。 私はそれを見逃していますか？

@justinhelgersonそれはそこにあるはずです。

アナウンスのブログ投稿の指示に従って、2.0 Preview1 SDKをインストールしましたか？

.NET Coreプロジェクトを作成した後、クラスライブラリを作成した場合は.csprojファイルに<TargetFramework>netstandard2.0</TargetFramework>が含まれ、コンソールアプリを作成した場合は<TargetFramework>netcoreapp2.0</TargetFramework>が含まれていることを確認できますか？

ところで、このスレッドの多くの人々はバイナリシリアライザーに興味を持っているので、.NET Core2.0の[Serializable]の縮小についてのdotnet / corefx＃19119での議論に興味があるかもしれません。 ご意見がございましたら、そちらまでお知らせください。

@zhenlan迅速な対応ありがとうございます。 NuGetを介してプレビューをインストールしましたが、.csprojファイルを手動で更新しませんでした。 それがトリックでした！ スケールバックについて読み、ユースケースに影響する場合は入力を提供します。

@justinhelgerson 、スケールバックの変更はプレビュー1にはありません（まだ作業中です！）が、デイリービルドまたは将来のプレビューですぐに試すことができるはずです。