Runtime: .NET Core3.0でのJSONの未来

これは素晴らしい。 私はすべて、json解析をより速く、より少なく割り当てることを望んでいます。

新しいjsonapisがサポートするjson.netの機能についての議論はありますか？ もしあれば、頭に浮かぶ2つの主要な機能は、プロパティの名前変更/ケーシングとnullプロパティの無視だと思います。

新しいjsonapisがサポートするjson.netの機能についての議論はありますか？

はい。 CoreFxに移行することを早い段階で考えました。 これは、通常どおりオープンで設計および構築される機能になります。 さらに、人気のあるJSONライブラリの多くの作成者に連絡を取り、この発表の初期ドラフトをレビューするように招待しました。 私の希望は、プラットフォーム用の堅固なJSONコンポーネントを作成すると同時に、その上にあるエコシステム（ASP.NET Coreなど）をプラグイン可能にして他のコンポーネントを許可できるようにすることです。 最終的には、消費者ごとに目標が異なり、異なるライブラリをプラグインできるということは、アプリに最適なコスト/メリットを持つコンポーネントを柔軟に選択できることを意味します。

ねえ@terrajobst。 新しいJSONはnetstandardAPIサーフェスとして表示されますか、それとも今のところCoreに統合されていますか？

ねえ@terrajobst。 新しいJSONはnetstandardAPIサーフェスとして表示されますか、それとも今のところCoreに統合されていますか？

はい、問題はそれがキャッチできるリリーストレインだけです。 2.1は早すぎる可能性があります。

したがって、フレームワークに組み込まれたJSON解析ビットは、v3.0がRTMに移行したときに利用可能になる予定です。または、ASP.NET Coreの統合APIのみが完了し（実装は1つだけ-JSON.NET）、で交換可能になります。後日？

3.0の計画は次のとおりです。

1. 組み込みの高性能JSONAPI。 低レベルのリーダー/ライター、 Streamベースのリーダー/ライター、およびシリアライザー。
2. ASP.NET Coreは、JSONコンポーネントにプラグインできます。

3.0のASP.NETのテンプレートが何を使用するかについては自由形式の質問があります。 忠実度に応じて、我々は彼らがJson.NET統合パッケージで引っ張っている可能性があります3.0で提供することができます。 ただし、目標は、デフォルトで組み込みのものにのみ依存するのに十分な忠実度とパリティを提供することです。

ありがとう-それは物事を片付けるのに役立ちます。 👍

そして、いくつかの追加の質問！

統合パッケージを使用する場合、ASP.NET Coreパイプライン全体で使用されますか、それとも一部の場所でのみ使用されますか？
Kestrelは常に内部のリーダー/ライターを使用すると思います。

Apiの人間工学は次のようになりますか？

• 組み込みの機能セットを拡張する場合にのみ、統合を提供します。
• 統合パッケージを常に提供しますが、1つは組み込みで、低レベルのリーダー/ライターを高レベルの機能に統合します。

この新しいパーサーがappSettings.jsonなどのすべての組み込みJSONに使用されると仮定すると、コメントのサポートを早期に要求できますか？

ありがとう。

これは素晴らしいニュースです！ 簡単な質問：このライブラリはどのパッケージに依存しますか？

生産顧客によってテストされたホイールを再発明するのはなぜですか？ Json.Netに問題がある場合は、オープンソースとしてPRを送信してください。

Json.NETの問題は、Microsoftが所有していないため、交換する必要があることだと思います。 ああ、でも、DataContractJsonSerializerと呼ばれるものがすでにSystem.Runtime.Serializationにあります。 それを使用できますか、それとも新しいAPI、DIYをコーディングするのがとても楽しいので、避けられませんか？

私がこれにあまり満足していない理由は、Json.NetがF＃DiscriminatedUnionsなどのすでにエッジケースをサポートしているためです。 特にうまくいきませんが、開発者がそれと一緒に暮らせるレベルです。 代わりに、新しいAPIは通常、ASP.NETWebサイトのユースケース以外のものを忘れます。

@markrendleコメントを許可するためのオプトイン設定がJsonReader（進行中の作業）にあります。 構成システムは、デフォルトでその設定を有効にする可能性があります。

@Thorium実際にOPを読みましたか？ JSON.NETを使用しない理由と、JSON.NETが引き続きアドインパッケージで正式にサポートされる理由を説明します。

@ JamesNK😄

@ ThoriumJson.NETがなくなることはありません。 あなたは何も失っていません。 これは、単純で高性能なシナリオのもう1つのオプションです。

@ ThoriumJson.NETがなくなることはありません。 あなたは何も失っていません。 これは、単純で高性能なシナリオのもう1つのオプションです。

Jsonはどのように下位互換性を生成しますか？

たとえば、バックグラウンドでJson.NETを使用しているSignalRを使用しています。 さて、F＃で識別された共用体は同様の構造にシリアル化されるので、サーバーの現在のSignalRライブラリとは異なる方法で構造をシリアル化するために、新しいAzure Signalr Service（バックプレーン）がランタイム例外をスローする問題と戦うことはありませんか？

他の人が新しいAPIをすぐに手に入れてくれることを願っています。 あなたを見て、 @ AzureCosmosDB ;-)

JObjectのようなクラスを含めて動的をサポートすることを計画していますか、それともこの機能の範囲外ですか？

このライブラリの1つを確認することをお勧めします。

• https://github.com/kevin-montrose/Jilまたは
• https://github.com/neuecc/Utf8Json

これは、インスピレーションを得るための本当に良い方法かもしれません。

DataContractJsonSerializerは、この新しいリーダー/ライターを内部で使用しますか？

私は多くの人気のあるJSONライブラリの作成者に連絡を取り、この発表の初期ドラフトをレビューするように招待しました。 私の希望は、プラットフォーム用の堅固なJSONコンポーネントを作成すると同時に、その上にあるエコシステム（ASP.NET Coreなど）をプラグイン可能にして他のコンポーネントを許可できるようにすることです。

JSON.NETに次いで2番目に人気のあるJSONライブラリ-Span上に構築されるようにすでにいるServiceStack.Textに理由はありますか？API 除外されましたか？ ServiceStack.Textシリアライザーは、.NETのより多くのプラットフォームでの実行を

MITライセンスの高性能https://github.com/neuecc/Utf8Jsonを確認する価値があるかもしれません

これは間違いなく私たちが必要としているものです...メインクラス名の私の提案は、「 Json 」を使用するだけです。

@terrajobstこれがいつ起こるのだろうと思っていました...

JSON.Netが抽象化ではなく直接の依存関係として追加された理由を常に疑問に思っていました（.Netエコシステムの事実上のJSONパッケージであると考えても）。

ただし、JSONのみの抽象化を追加することは、どういうわけかあなたの足元にあると思います。 オルレアンのIExternalSerializerのようなMicrosoft.Extensions.Serialization形の_serializer_抽象化がより効果的だと思います...

makeがJSONのみである特別な理由はありますか？ 他のタイプのシリアライザーを接続できる他のケースもあります...

@galvesribeiro IOutputFormatter / IInputFormatter ？

@ yaakov-hはそれらに気づいていませんでした...彼らでしたか？

@galvesribeiro AspNetCore： https ： //docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc.formatters.iinputformatter ？ aspnetcore- 2.1

オーケー...今は理にかなっています。 では、この_new_ JSONのみの抽象化がどこで機能するのでしょうか？

この事業を開始するという決定は、System.String（UTF-16 String）の非効率性についての証拠でもあります。
asp.netとjsonライブラリ間のすべてのjson処理を抽象化する新しいJSONフックは、最初にutf-8文字列BaseTypeを作成するタスクに取り組むと、大幅に見栄えが良くなると思います。
->たぶんSystem.Utf8Stringを作成します

ええ... @ migueldeicazaが少し前にいつか.Netにutf8文字列を使用させると言ったことを覚えています😄

@ jges42 @galvesribeiro Utf8Stringを追加する提案は、 https：//github.com/dotnet/corefx/issues/30503です。 .Net Core3.0でも計画されているようです。

これらの新しいJSONAPIには、 Utf8Stringとchar / string両方に専用のコードパスがありますか、それとも最適化には現状の反転が含まれるので、UTF-8以外のものはすべて代わりにそれにトランスコードする必要がありますか？ （ stringのネイティブUCS-2 UTF-16はほとんどなく、それでも適応/説明する必要があるため、これは必ずしも莫大なコストを伴うわけではありません。私はただ、 APIサーフェス。Kestrelをより効率的にするためにこれを行うことは合理的です。設計がKestrelよりも多くのクライアントを考慮していることを願っています。）

@galvesribeiro
実はあなたは良い点を挙げていると思います。 効率的なシリアル化フレームワークの作成と効率的なJsonデコーダー/エンコーダーの作成は2種類の問題だと思います。 構造体をSerializableとしてマークする方法がいくつかあることは知っていますが、JsonSerializationで使用されるのを見たことがありません。

RustのSerdeプロジェクトは、問題を2つの問題に分割することにより、実際には優れたコンセプトを持っています。

1. シリアル化/逆シリアル化（C＃のインターフェイスに類似した特性）これは、このインターフェイスから継承するすべてのタイプがシリアル化/逆シリアル化できることを意味します
2. Serializer / Deserializerは、フォーマット固有の実装です。

型は、手動で、またはこれらの特性の実装を実行するために必要なコードを生成するマクロ（コンパイラプラグインの形式と見なすことができます）によって、シリアル化/逆シリアル化を実装できます。 タイプにそれらのトレイトを実装しない子タイプが含まれている場合、コンパイル時にも警告が表示されます。 これは、サポートされている任意の形式で一部のデータオブジェクトを記述し、（逆）シリアル化できることを意味するため、全体的に優れた概念です。 この方法でフォーマットを書くのははるかに簡単です。

Serdeの方法がすべてC＃で機能するとは思いません。これは、一部のデータ構造にとって重要になる可能性のあるタイプ固有の属性を実際には提供していないためです。 したがって、これにはいくつかの作業が必要です。 また、AoTコンパイルを考慮することは、一部のプロジェクト（WASM）にとって非常に重要になります。AoTコンパイルもそれとうまく機能するはずです。

より明確にするためのSerdeドキュメントへのリンクは次のとおりです（概念を表示するには、下の4つの特性をクリックしてください）。
https://docs.serde.rs

@mythz ServiceStack.TextのライセンスはいくつかのFOSS例外を除いてAGPLです-それはおそらく人々がプロプライエタリソフトウェアでそれを使用することを妨げるでしょう。 また、マイクロソフトの従業員がそれに触れるには法的な許可が必要であり、ソースを見た従業員は他のJSONライブラリや関連テクノロジでの作業を禁じられる可能性があると思います。

@ poizan42 ServiceStack.Textは、OSSとクローズドソースの商用プロジェクトの両方で無料で使用できるOSS /商用ライセンスの両方でデュアルライセンスされています。 ただし、MSが独自の実装を開発しているため、ソースコードライセンスは関係ありません。

MSは「エコシステム」と協力して「プラグ可能な」JSONシリアライザーAPIを開発していると主張しました。これは、10年近く活発に開発されているServiceStackが、それを維持することができた数少ない独立した.NETソフトウェアスイートの1つである場合です。 JSON.NETに次ぐ2番目に人気のあるJSONシリアライザーと、どのMSよりも多くのプラットフォームで実行される2番目に人気のあるアクティブに開発されたWebフレームワーク（MS以外）を維持する、MS外の独立した健全なコミュニティを独自に維持します。 Webフレームワークは、主にこれらの変更の影響を受ける「エコシステム」の一部とは見なされません。それらが参照している「エコシステム」とは何か、なぜ除外されているのか、他の何人が除外されているのか興味があります。 「エコシステム」の一部とは見なされません。

私はこのすべての恨みを理解していません。 Asp.netは、json.netの特定のバージョンを使用することを強制しました。 彼らはそれを変更しているので、あなたが望むJSONパーサーを選ぶことができます（またはそれを混ぜることができます）、そしてデフォルトの1つのOOBがあります。 ServiceStackは、この変更に満足し、この開発がどのように見落とされていたかについてただ泣き言を言うのではなく、この開発を監視してフィードバックを提供する必要があります。これは、優れたコミュニティ精神を育む効果的な方法となることはめったにありません。 私は個人的に多くの.netチームメンバーを知っており、彼らが悪意を持っているつもりはなかったと確信しています。 彼らは皆、OSSとコミュニティ活動の大きな支持者です。
個人的には、GPLから派生したライセンスは、私にとっては大きな自動ではありません。 私と私の顧客のためのApacheまたはMIT、または私たちは先に進みます。 不思議なデュアルライセンスはありません。

Asp.netは、json.netの特定のバージョンを使用することを強制しました

いいえ。 どうして？

私はこのすべての恨みを理解していません。

出向！

JSON.Netをダウンロードせずに、選択したシリアライザーを最終的に使用できるようになることを個人的に嬉しく思いますが、ASP.Netにはライブラリへのハードリファレンスがあるため、出荷する必要があります。

（恥知らずなプラグ：https：//github.com/gregsdennis/Manatee.Json）

@dotMorten

私はこのすべての恨みを理解していません。

あなたは私のコメントを読んだり理解したりしていないからです。 独自の説明を作成するのではなく、私のコメントに直接返信するようにしてください（つまり、引用機能を使用してください）。

彼らはそれを変更しているので、あなたが望むJSONパーサーを選ぶことができます（またはそれを混ぜることができます）

したがって、魔法の「ミックス」のように、既存の.NETシリアライザーが直接プラグイン/プラグアウトして内部のカスタマイズ可能性オプションにミックスできる最適なAPIとプラグイン可能性オプションを自動的に選択します。同じで、すべてがすべてのシリアライザーで機能しますか？ その場合、APIが固まる前に、コラボレーションや統合テストは必要ありません。 あるいは、シリアライザーの実装はさまざまな違いや意見で微妙に異なり、すべてが機能するだけでなく、すべてのカスタマイズオプションが正確に実装されるわけではなく、ワイヤー形式が同じになることはなく、実現することもできません。異なる実装間の完全な相互運用。 あなたが見ている「プラグイン可能性」は大きな違いを生み、それは私たちがしなければならない書き直しの量と、既存の実装とこの新しい実装をサポートできるかどうかを決定することができます。

ServiceStackはこの変更に満足し、この開発を監視してフィードバックを提供する必要があります。

これを行う機会は与えられていません（またはまだ方法を知っています）が、私がどのように感じるべきかを教えてくれてありがとう。 それぞれの強度を評価する前に、ライブラリの機能、相互運用性、互換性を評価したいと思います。 おそらくそれは素晴らしいことであり、両方の実装をサポートするのは簡単ですが、異なるシリアライザー実装との相互運用の経験から、非互換性とコーナーケース、および異なるシリアル化固有の実装と機能への依存に満ちています。 私の予測では、JSON.NETとデフォルトのimplの間の相互運用は、それが設計目標であり、テスト対象であるため素晴らしいものになるでしょうが、他のシリアライザーはそれほど幸運ではないでしょう。

それがどのように見過ごされてきたかについてただ泣き言を言うのではなく、それは良いコミュニティ精神を育むための効果的な方法であることはめったにありません。

彼らが「エコシステム」と共同でこれを開発したという彼らの主張に異議を唱えています。.NETには、「デフォルト」ライブラリをバンドルするたびに既存のエコシステムを殺してきた歴史があります。ここで（デフォルトをバンドルすることがエコシステムに役立ったときのことを思い出すのに苦労しています）。 しかし、それにもかかわらず、APIがフリーズする前にアクセスして入力できるようにしたい、リリースされているものとのシームレスな統合を開発する必要があります。 しかし、それは大丈夫です。既存および将来の実装をサポートする必要がある既存のフレームワーク/ライブラリにどのように影響するかを気にする必要はありません。JSON.NETがサポートされたままであるかどうかだけが心配です。それがあなたに影響を与えるすべてだからですが、あなたの仮定を保持し、このような破壊的な変化を吸収することについて私たちがどのように感じるべきかを私たちに知らせてみてください。

デフォルトをバンドルすることがエコシステムを助けたときのことを思い出すのに苦労しています

ああ、さあ！

（残りの部分では、私はあなたの感情にほとんど同意します）

@mythz今日、別のサードパーティのJSONライブラリをフレームワークにバンドルしているので、これが問題を引き起こしていることに驚いています。 JSONをベイクする場所はほんの一握りであり、それらのほとんどには、ユーザーが合理的に置き換えるプロバイダーモデルがあります（MVCフォーマッターなど）。

私の予測では、JSON.NETとデフォルトのimplの間の相互運用は、それが設計目標であり、テスト対象であるため素晴らしいものになるでしょうが、他のシリアライザーはそれほど幸運ではないでしょう。

私たちが出荷するものは、JSON.NETがサポートする機能の全範囲をサポートしないことはすでにお伝えできます。 そのため、これはすでに真実ではなく、実際には、場合によっては機能が低下すると予想されます（パフォーマンスとスコープの理由により）。

プラグ可能性は今日すでにほとんど存在しており、デフォルトのJSON.NET実装がどこにでもあります。 これは、そのデフォルトを代わりに新しいJSONシリアライザーに変更するだけです...

@abatishchev

基本フレームワーク（またはプロジェクト）にデフォルトの実装を組み込んだり採用したりすることで、既存の周囲のエコシステムにメリットがあったのはいつですか？ NuGet、MVC、ORM、ユニットテスト、Web APIなどがバンドルされているのを見るたびに、有害な影響しかなく、そのスペース内で競争するための酸素と動機を効果的に取り入れています。

ASP.NET Ajaxのような競合するライブラリが競合に失敗し、最終的にそれを放棄してjQueryを採用した場合もありますが、それが役に立ったときのことを思い出せませんか？ 注：これは、数年後の.NETを綿密に追跡した私の観察結果です。例があるかもしれませんが、いくつか知りたいと思いますか？ しかし、私のPOVからは、MSのデフォルトの影響は、置き換えられる機能の既存のエコシステムに悪影響を及ぼします。

マイクロソフトによるデフォルトのソリューションを持つことによるユーザーにとっての@mythzの利点は、代替ソリューションの作成者にとっての利点と同じではありません。 EFは.NETの世界で最高のORMであり、MSTestは当時のNUnitよりも優れていました。 私の意見では。

しかし、氾濫して主題に固執しないようにしましょう。 乾杯！

@davidfowlこれは、デフォルトを新しいJSON

デフォルトのシリアライザーがなく、実装をダウンロードする必要があることを提案したいと思います。 デフォルトが必要な場合、それはフレームワークまたはいくつかの別個のライブラリにベイクされますか（現在の場合のように）？

デフォルトのシリアライザーがなく、実装をダウンロードする必要があることを提案したいと思います。 デフォルトが必要な場合、それはフレームワークまたはいくつかの別個のライブラリにベイクされますか（現在の場合のように）？

経験が劣るので、それは不合理です。 最新のプラットフォームにはすべてJSONが組み込まれています。

@davidfowlまだ

私たちが出荷するものは、JSON.NETがサポートする機能の全範囲をサポートしないことはすでにお伝えできます。 そのため、これはすでに真実ではなく、実際には、場合によっては機能が低下すると予想されます（パフォーマンスとスコープの理由により）。

JSON.NET機能のサブセットをサポートすることだけを期待しています。たとえば、JSON.NETはデフォルトのワイヤー形式をサポートしますか？ （私はそうだと思います）。 新しいimplは、可能な場合はJSON.NETシリアル化形式を採用しますか（これもyesを想定しています）。

シームレスにサポートするにはどれだけの労力が必要ですか、既存の動作をサポートするために新しいimplにカスタマイズを適用できるか、新しいカスタマイズモデルとAPIをサポートできるか、サポートするようにシリアライザーをカスタマイズできるかデフォルトの構成/ワイヤーフォーマットは、新しいAPIが.NETCoreと.NETFrameworkの両方をサポートできるようにします。

@mythz私はこれのいくつかをフォローしていません。 私は、これが存在するAPIと、それらがどのように消費されるかについて議論していることを理解しようとしています。 たぶん、いくつかの具体的なシナリオを見ることができますか？

@mythz servicestackで私が目にする唯一の本当の懸念は、この新しいAPIが.net Framework Classicでサポートされていない場合です。servicestackは

また、これは非常に初期の段階での提案であり、達成したい目標はかなり有望に見えます。 建設的な批判は、どんなossプロジェクトにとっても常に良いことです。

マイクロソフトによるデフォルトのソリューションを持つことによるユーザーにとっての@mythzの利点は、代替ソリューションの作成者にとっての利点と同じではありません。

エコシステムとは、周囲の.NETライブラリエコシステム/コミュニティ（おそらくOPの「エコシステム」も参照している）を指します。これは、.NETユーザーも健全なエコシステムの恩恵を受けていると私は主張します。さまざまなオプションとより多くの競争（Python、Java、Node、Ruby、PHPなどのより健全なエコシステムの特徴として）。

EFは.NETの世界で最高のORMです

EFがリリースされた直後に、それはすぐに大部分のORM市場シェアを獲得しましたが、NHibernateよりも6倍以上遅く、おそらくサポートする機能は少なく、 2012年のInfoQインタビューからの抜粋です。

Entity FrameworkのORMデータアクセスレイヤーでの最近の試みは、以前の著名なORMNHibernateのかつて繁栄していたコミュニティにも悪影響を及ぼしました。 EFは、他のすべてのオープンソース.NET ORMよりも数倍遅いにもかかわらず

これは、パフォーマンスが最優先事項となった.NET Coreより前のバージョンでしたが、MSのデフォルトが既存のエコシステム/コミュニティに及ぼす悪影響の歴史的な例であることに注意してください。 IMOは、MSがデフォルトを導入したときに既存のコミュニティに何が起こるかをほぼ受け入れています。そのため、IdentityServerやAutoMapperと競合するデフォルトの出荷から元に戻すことが最近プッシュバックされています。

当時、MSTestはNUnitよりも優れていました。

IMOはかつてなかった（そしてNUnitのR＃サポートは常に優れたAFAICRでした）そしてMonoでクロスプラットフォームで実行できなかったという事実は、Monoでクロスプラットフォームをサポートしたライブラリ（.NET Core以前）が使用できなかったことを意味しましたそれ。

しかし、氾濫して主題に固執しないようにしましょう。 乾杯！

私もこれでこのスレッドをハイジャックしたくありませんが、なぜ私があなたの主張に同意しないのかを述べる必要がありました。

これに関連して、JSON.NETとは異なるシリアライザーを使用する主な理由はパフォーマンスであり、この新しいデフォルトのシリアライザーの理由を考えると、パフォーマンスです。 ほとんどの人はデフォルトを使用しているだけなので、これがJSON.NET共有に最も顕著な影響を与えると予想していますが、代替シリアライザーを使用する主な理由は、この高速なimplではもはや存在しないはずです。 したがって、基本的には、これが既存の（ライブラリ）エコシステムに悪影響を与えることもわかります。 JSONライブラリのより弱いエコシステムであるIMOは、.NETにとって正味のネガティブです（ほとんどの消費者は、デフォルトを使用して他のオプションを忘れるだけだとは思わないでしょう）が、それは私の主な関心事ではありません。

@davidfowl @ shahid-pk

それにもかかわらず、ServiceStack.Textを開発する主な理由は、.NET FrameworkのJSONシリアライザーが非常に遅いため、これが8年前に存在することを実際に望んでいました。 しかし、すべてのこの時間後SS.Textは、すべて私たちの図書館間での機能の数、支援するなどのカスタマイズと拡張されている異なる言語ServiceStackサポートする、さまざまなServiceStackでJSONのカスタマイズオプションでJSONサポートServiceStackテンプレート、内複合型JSONブロブサポートServiceStack .Redisなど

そのため、今は、影響がどのようなものになるか、新しいAPIとプラグイン可能性オプションがどのようになるか、既存の機能をそれに組み込むことができるか、SS .NET CoreAppsのJSONシリアライザーとして採用できるかを評価することに焦点を当てています。 （何が壊れますか）、ServiceStack.Textは新しいAPIをサポートできますか、.NET v4.5をサポートできますか、既存のデプロイメントのワイヤーフォーマットをサポートするようにカスタマイズできますか？I私はまだ何かを使用したり見たりする機会がなかったので、基本的にこれへの影響や今後の戦略についてはわかりません。 APIを使用する機会があれば、より多くの回答がわかります。APIがフリーズする前に、統合をテストしてフィードバックを提供し、変更を提案する機会が欲しいのは明らかです。

@mythz

JSON.NETに次いで2番目に人気のあるJSONライブラリ-SpanAPI上に構築されるようにすでにいるServiceStack.Textが除外された理由はありますか？

省略は意図的なものではありませんでした。 CoreFxLabリポジトリの一部としてJSONライブラリの作成者を積極的に検索して作業し、、NuGetの「json」などの基本的な検索用語を使用して最初に入力されたと思います。 ライブラリが表示されなかったようです。 これはあなたにとって苛立たしいことや心配なことかもしれませんが、私たちの側から状況を理解するようにしてください。私たちのチームは、太陽の下ですべての図書館を知ることを期待することはできません。 この発表は、コミュニティ全体を巻き込むためのオープンな開発モデルの一部です。 私たちが最初に小さなグループに手を差し伸べる傾向がある唯一の理由は、私たちがそれを世界と共有する前に、私たちの計画とメッセージが合理的なレベルの思慮と品質を持っていることを確認することです。 まだ最終的なものはありません。 追加のフィードバックを積極的に探しています。

あなたが言及している「エコシステム」について知りたいのですが、ここで「一緒に働く」ことを望んでいますか？

.NETエコシステム、特にJSON処理に関心のある関係者。

私は明らかに、これらの「プラグ可能な」APIの互換性がどの程度になるのか、またはこれが新しいMSライブラリの採用と統合によって置き換えられるエコシステムが破壊される別の領域になるのかどうかに興味があります。

計画されたASP.NETCore拡張ポイントの目的は、顧客が組み込みのJSONコンポーネントを必要なJSONライブラリに置き換えることができるようにすることです。 もちろん、ASP.NETには常に「バッテリーが含まれています」、つまり妥当なデフォルトエクスペリエンスが付属しています。 これまではJson.NETでしたが、今後はプラットフォームが提供するコンポーネントになります。 Json.NETがASP.NETにいくらか組み込まれていることを考えると、新しい計画はあなたのような人々にとってネット的に優れているように思われます。 ですから、私たちの計画のどの部分が脅威だと思うかは完全にはわかりません。

3.0のASP.NETのテンプレートが何を使用するかについては自由形式の質問があります。

テンプレートをモジュール化する時ではありませんか？ たとえば、vue.jsを取り上げます。

新しいvueアプリを作成すると、必要なものを選択できます。 すべてのシナリオに対応するために500個のテンプレートを作成する代わりに、asp.netに対して同様のことを実行できないのはなぜですか。

これは、JSON.NET以外のJSON入出力フォーマッターが問題に直面する.ASP NET Core 2.2の機能の具体例と、分離されたソリューションがどのように役立つかを示しています。
RFC 7807互換性のあるエラーレスポンスを可能ProblemDetails機能、：
https://github.com/aspnet/Mvc/blob/release/2.2/src/Microsoft.AspNetCore.Mvc.Core/ProblemDetails.cs

[JsonProperty(NullValueHandling = NullValueHandling.Ignore, PropertyName = "instance")]
public string Instance { get; set; }

[JsonExtensionData]
public IDictionary<string, object> Extensions { get; } = new Dictionary<string, object>(StringComparer.Ordinal);

上記のコードは、特定のフォールバック属性[JsonExtensionData]を含むJSON.NET固有の属性で注釈が付けられ、すべての不明なJSONプロパティがこのディクショナリに逆シリアル化され、このディクショナリのコンテンツが通常のJSON構造にシリアル化されます。

代替のJSON入力/出力フォーマッターは、このタイプを適切にシリアル化/逆シリアル化するか、別の方法、つまりこれらのタイプのJSON.NETへのフォールバックを見つけるために、これらのJSON.NET固有の属性を処理する必要があります。

ここで、JSONのInput / OutputFormatterが3.0をサポートする必要がある機能の明確な仕様がある場合、上記の問題は存在しません。つまり、これらの属性はMicrosoft.Extension ...パッケージとすべてのカスタムJSONフォーマッターに存在する可能性があります。それらを使用して、互換性のあるこの機能を実装できます。

私の知る限り、JSON.NET属性で注釈が付けられたASP.NET Coreの「公式」ソースコードのインスタンスはごくわずかですが、JSON.NET固有の属性（通常は指定する）を使用するサードパーティライブラリも見ました。 [JsonProperty("name")]経由の属性名

FWIW、それがhttps://github.com/Tornhoof/SpanJson/issues/63の目的です。

@terrajobst IMOが私の懸念をより明確にしている私の以前のコメントを読む前に、あなたは答えたと思います。

追加のフィードバックを積極的に探しています。

どこ？ API提案/ドキュメントはありますか？APIは作成されていますか？どのリポジトリで開発されていますか？

IMOが私の懸念をより明確にしている私の以前のコメントを読む前に、あなたは答えたと思います。

私はそれを読みましたが、 @ davidfowlが説明したように、私たちにとって実用的ではないデフォルトを持つことに反対しているようです。 私のポイントは、私たちの計画は私たちが現在持っているものの改善、つまりJson.NETへの事実上のハードワイヤリングであるということでした。 したがって、私の質問。

どこ？ API提案/ドキュメントはありますか？APIは作成されていますか？どのリポジトリで開発されていますか？

この発表を最初に発表したかったので、.NETCoreでのコーディング/ API設計はまだ意図的に行っていません。 この発表が提供したコンテキストを提供せずに、人々に茶葉を読んでほしくありませんでした。 つまり、しばらくお待ちください。APIとコードはまもなく公開されます。

@terrajobstその投稿の全体的な印象

1. 変更を加える決定が行われます。

今後、JSONサポートにいくつかの変更を加える予定です。

1. いくつかの予備設計が行われます
   高性能のJSONAPIが必要です。
   ASP.NETCoreからJson.NETへの依存関係を削除します。
   Json.NET用のASP.NETCore統合パッケージを提供します。

これはすべて、方向性が取られることを意味します。 「エコシステム」から求められるのは、MSが現実的に説明できなかった明らかな問題点を見つけることだけです。

ServiceStackを省略し、セカンダリクラスの.NETライブラリとして議論するのは笑えることです。 私がMSで出荷されたライブラリだけを扱っているとしても、それは私が代替案について知らないという意味ではありません。

私はMSが決定を下すのに問題はありませんが、それが直接述べられていて、すでに下された決定に関する「コミュニティフィードバック」でカバーされていない場合。

それが私の印象です

@terrajobst

私はそれを読みましたが、あなたはデフォルトを持つことに反対しているようです

JSON.NETがこれ以前のデフォルトであったことを示唆したことはありません。 上記で詳しく説明しましたが、繰り返しになりますが、これはデフォルトを引き継ぎ、新しいデファクトスタンダードになります。事実上、.NET Coreには将来的に2つのJSONシリアライザー（この新しいデファクト高性能デフォルトとJSON）しかありません。カスタム機能のためのNET。 他のJSONシリアライザーはニッチになります。たとえば、さまざまなシナリオをサポートするために追加された独自の機能です。

この発表を最初に取得したかったので、意図的にコーディング/ API設計の.NETCoreを実行していません。

さて、「外部の人」がプラグイン可能性、拡張性、または相互運用性をどれだけうまく知ることはできません。
まだです。

この発表が提供したコンテキストを提供せずに、人々に茶葉を読んでほしくありませんでした。 つまり、しばらくお待ちください。APIとコードはまもなく公開されます。

それで、それは内部で開発されましたか？ リリースしてからどれくらいの期間、部外者はAPI設計の変更をテストして提案する必要がありますか？ 「プラグ可能」および「拡張可能」APIがどのように見えるかについての私の主な関心事は、参照/値型のワイヤー形式を「引き継いで」完全に制御できるようになるのでしょうか。 組み込み型、列挙型、bool、その他の組み込み関数などはどうですか？ たとえば、例として、「yes」、「on」、「1」などの他の一般的なJSON値を受け入れるようにboolを構成できます。

その他の質問：

• この実装をスタンドアロンで（別のNuGetパッケージで）使用できますか？
• APIの「プラグイン可能な」部分はWebフレームワークに関連付けられていますか、それとも他の場所（Xamarin / UWPなど）で使用できますか？
• .NET Standard2.0または.NETv4.5をサポートしますか？
• そうでない場合、APIは.NET Standard2.0または.NETv4.5をサポートできますか？

@mythz
それは実際には内部で開発されていません（私の知る限り）、リーダー/ライターの部分はcorefxlab（https://github.com/dotnet/corefxlab/tree/master/src/System.Text.JsonLab/System/Text/ Json）、具体的には、corefxlabにはまだ高レベルのAPIはありません。

個人的には、拡張可能/プラグ可能なAPIパーツを除いて.NET標準（つまり属性など）にします。 corefxlabのライブラリは現在.NETStandard 1.1ですが、ライブラリのパフォーマンス目標などによって変わると思います。

@mythz

あなたは私の発言を「グラスは半分空っぽ」という文脈に入れたいと思っているようです。 わかりました、あなたは懐疑的です。 抽象的に議論するのではなく、たくさんのキーストロークを節約し、具体的なAPI提案について議論することをお勧めします。 私たちの計画はあなたが必要とする拡張ポイントを提供すると私はかなり確信しています。

@terrajobst懐疑的ではなく、提案された高レベルの機能が何であるかを知りたいと思っています。これはすでに決定されていると思います（または、すべてまだ未定ですか？）。 この発表は私たちのほとんどがそれを聞いた最初のものであるため、プラグイン可能、拡張可能、および再利用可能であることがどのように意図されているかについていくつかの説明をした後です。 System.Text.JsonLabは現在の実装ですか？ これは、.NET Standard2.0および.NETv4.5もサポートすることを意味しますか？

これはライブラリ作成者にとっては素晴らしい機能かもしれませんが、依存関係ツリーを持つ50のライブラリを使用し、それらの間の互換性を見つけようとするエンタープライズ開発者も考慮する必要があります。 不一致を管理しようとするバインディングリダイレクトスタイルのマッピング構成はありますか？

この会話は、人々が何らかの形で気分を害したためであろうと、実行されたアクションまたは実行されなかったアクションを防御しようとしているためであろうと、端を発しているように見えます。 読みにくいです。 お詫びします！ 現在の状態のままにして、先に進んでください。

この変更には2つの理由があるようです。 1つは、.NetCore内の新しいタイプを利用してパフォーマンスを向上させたいという要望です。

さらに、少し前に、.Netの外部にあるライブラリであるJSON.Netへのハード参照を含めることでアーキテクチャエラーが発生したことが認識されていました。 これを修正するには、サードパーティが独自の実装を使用できるようにするインターフェイスとともに、新しい組み込みのJSON実装を導入する必要があります。

これは物事を壊しますか？ はい！ そのため、アナウンスには「重大な変更」というラベルが付いています。 （おそらく、そのラベルはここに複製する必要があります。）そして、これは重大な変更であることが知られているため、影響を調査するための議論が開始されました。 さらに、影響を最小限に抑えるために、JSON.Netの使用を継続できる追加のライブラリが提供されます。

図書館の著者として、私はこれに本当に興味があり、会話が前進することを望んでいます。

@Tornhoofは、あなたの例に応えて、JSON.Netを引き続き使用したい場合は、前述の互換性ライブラリも参照する必要があります。 これは主に、プラグアンドプレイでなければなりませんが、変更があるかもしれません。 私は間違いなく私のシリアライザは、同様のコンセプトのために異なるメカニズムを使用する場合は特に、フレームワーク（.NETコア）は、私が選択したシリアライザは、シリアル化のためのこれらの属性を使用しなければならないことを指示する必要はありません。

.Netが提供するソリューションは、それよりも一般的である必要があります。 特定のモデルのシリアル化の処理は、選択したJSON実装によって実行する必要があります。

@mythzこの提案の作成に携わった人々から私が知っていて見たすべてのことから、安定したものとしてリリースされる前に、提案されたAPIと実装についてレビューしてコメントする長いチャンスがあります。 このような早い段階でこの投稿を行う目的の1つは、特にこの理由であなたのような人を見つけることでした。

@gregsdennis
より一般的な意味がわかりませんか？
シリアライザーがjsonプロパティ名をオーバーライドし、それらのnull動作やフォールバック/キャッチオール実装を変更し、3つの機能すべてが.netコア3.0のJSONシリアライザーの共有仕様の一部であると仮定すると、実装パッケージこれらの属性を内部実装の詳細にマップします。
たとえば、ライブラリが[DataMember]を使用してプロパティの名前を指定することを好む場合（SpanJsonのように）、統合パッケージはそれを簡単にマップする必要があります。
属性が正しい方法だと言っているのではなく、たまたまコード例の目に見える部分になっているだけです。

明らかに、理想的な世界は、ASP.NET Coreフレームワークライブラリがシリアル化の動作を制御するために特定の注釈を使用しないことですが、RFCでは特定の命名規則に従う必要があるため、上記の機能は非常に複雑で不可能です。 。

いずれにせよ、これらの共有機能、それらの使用方法と説明については、今後多くの議論が行われると思います。

RapidJSONのように、新しいJSONパーサーでSIMD命令を使用する予定はありますか？

参照： http ：

提案された提案は良さそうですが、「重大な変更」をスムーズにしてみてください。私はサードパーティのライブラリの一般ユーザーであり、最近、UWP .netネイティブリリースビルドプロセス（コンパイラ）からリフレクションが突然除外された経験があります。 ）。

そのため、サードパーティのライブラリでリフレクションを使用するすべてのコードを書き直す必要があったため、UWPアプリをリリースモードで数か月間ビルドすることはできませんでした。 多くのライブラリ作成者は、それらのUWPパーツへの反映を除外するために、実装を再度分割する必要があったことを知っています。 ほとんどの図書館の著者はパーティーに来ず、私は船に飛び乗ることを余儀なくされました。 MSが前面に出て、.net標準2.1で代替を実装することを約束しましたが。 現場での現実は.net標準2.1であり、最初の重大な変更から実現するには数か月かかることがわかっています。

重要なのは、これは私にとって非常に破壊的なプロセスであり、エンドユーザーに多大な影響を及ぼし、「スムーズ」で摩擦のないものではなかったということです。

これは間違いなく正しいステップです。
このJson.Netリファレンスをしばらく見て疑問に思っています。

@Tornhoof定義された分離が必要だと思います

インターフェースは可能な限り汎用的である必要があります。 おそらく、 Serialize() Deserialize()メソッドと

その他の詳細は実装に任せる必要があります。 デフォルトの実装で属性を使用してカスタムプロパティキーイングメカニズムを定義している場合は、それで問題ありません。 これは実装固有の詳細であり、インターフェースの一部であってはならないと思います。

とはいえ、プロパティをカスタムキー設定する機能があることが要件になる可能性がありますが、それをどのように体系化できるかはわかりません。

@gregsdennisはい、その通りです。私は主に、現在ASP.NETCoreにすでに存在するIInput / OutputFormatterと、それらを非JSON.NETバージョンに置き換えることに関する問題を調べていました。
とにかく、あなたと@mythzのコメントが示すように、スコープの定義は面白くなり、おそらくそれほど単純ではないと思います（DIインターフェイスの仕様の問題を覚えています）。 したがって、プロセスの早い段階で多くの異なる視点を取り入れることをお勧めします。

@Tornhoofは同意しました。 現在のフォーマッターインターフェイスは明らかにJSON.Netベースですが、シリアライザー自体ではなく、オプションオブジェクトに基づいています。 オプションを伝達するための一般的な方法（一般的なオプションオブジェクト）も必要になるようです。

これは、optionsオブジェクトが実装の最小機能セットを指示することを意味しますか？ そうは思わない。 私は最近、optionsオブジェクトを完全に無視するシリアライザー用のフォーマッターを実装しましたが、それは私用でした。 公用に作りたいのなら、それらをサポートするために、できるだけ多くのオプションを解釈しようと考えています。

それが今の私たちのやり方ではありません。 オプションはシリアライザー固有であり、それらに共通のインターフェースはありません。 MVCのフォーマッターはすでに適切に除外されており、何にも結合されていません。 JsonResultはJsonSerializationOptionsを直接（JSON.NETタイプ）取るため、重大な変更があります。

私は同じことを言おうとしていました。 JSONリーダー/ライター/シリアライザーの抽象化を構築する予定はありません。 必要ありません。 フレームワークは、IOプリミティブ（ Stream 、 TextReader ）を処理するか、高レベルのフレームワーク処理（ASP.NET Coreフォーマッターなど）にプラグインします。

問題点について言えば、個人的に（そして私は非常に少数派である可能性が高いです）、私は多くのJSONパーサーの緩い性質について懸念しています。 標準（tm）がありますが、ほとんどのパーサーは寛大で、不適合なドキュメントを受け入れることを選択しました。 長期的に見て悪いのは、開発者がライブラリに向けて実装する標準に向けて実装しないことです。 ライブラリが不適合ドキュメントを許可している場合、すべてのビットが同じライブラリを使用している限り、開発者は満足しています。 異なるライブラリを使用するドメイン間で通信しようとすると、問題が発生します。 さまざまなライブラリがさまざまなフレーバーのJSONをサポートしているため、突然問題が発生します。

JSONライブラリを可能な限り寛大にする（ただし、おそらく複雑さとあいまいさで終わる）か、根本原因を攻撃することによって、問題点を取り除く必要があります。 未確認のJSONライブラリ。

影響力のあるMSは、長期的に相互運用性を向上させるために、適合したJSONパーサーを首尾よく擁護するようMSに求めることがたくさんあるかもしれませんが、それが違っていたらいいのにと思います。 おそらく、読み取りには寛容ですが、書き込みには厳密ですか？

（標準にないもの、コメント、末尾のコンマ、一重引用符、引用符なしなど）

私見ですが、JSONはWebブラウザーの世界に由来しているため、相互運用性のために、JSON標準では担当者について何も述べられていませんが、JSONの数値の基礎となる表現としてdoubleを選択する必要があります。

APIについて言えば、最も一般的に使用されるAPIはAPIのようなDOMであると暗黙のうちに想定していますが、トークンストリームを消費したり、ビジターインターフェイスでシグナルを送信したりできる低レベルのAPIがあれば、非常に便利です。データのごく一部を抽出したいだけの大きなドキュメント。

@ mrange-できる限り厳密にするのが好きです。そうすることは、不適合なコードを変更する機能に依存しています。

他の会社の管理下にあるレガシーサービスとやり取りしている場合、問題のあるコードを変更する機能はほぼゼロです。 厳密な書き込みでさえ、より実行可能ですが、ここでそれ自体の問題がないわけではありません。問題のあるコードが不適合なオブジェクトを送信することを期待している場合はどうなるでしょうか。

@terrajobstありがとうございます！ ここで必要なのはFunc<Stream, CancellationToken, Task<T>>とFunc<T, CancellationToken, Stream, Task>です。 TextReader / Writer、Span、およびstringのオーバーロードが多分あります。

ただし、欠点は、別のライブラリの型をシリアル化/逆シリアル化したい場合であり、その型は、使用していないjsonシリアライザーの属性で装飾されています。

@thefringeninjaオブジェクトにサードパーティのライブラリをすでに使用している場合は、

私は恐怖を恐れる人ではありませんが、 @ mythzにはいくつかの有効なポイントがあると思います。

@terrajobstエコシステムに関しては、そこにあるすべてのライブラリを説明することは不可能ですが、NuGetで「json」をすばやく検索してもあまり意味がないと思います。 おそらく、ServiceStack.Textという名前は、「Hey！私はJSONを（逆）シリアル化できるパッケージです！」という最も直接的な言い方ではありませんが、それを比較するベンチマークは何年にもわたってあります。 おそらくそれは、MSのデフォルトをドッグフーディングし、代替案の幅と人気を知らないか、それらに精通するのに十分な頻度で内部的に使用している場合です。

すぐに使用できるエクスペリエンスを提供するには、デフォルトが必要であることに同意します。 エコシステム内の他のライブラリ作成者が統合パッケージを公開する場合、デフォルト以外の選択肢があることを強調するために、ドキュメントやリリースノートなどのプラグインを入手できれば素晴らしいと思います。 発見を困難にすることは、生態系にとって問題となるでしょう。

依存関係を削除するという目標が誠実である場合、APIはコミュニティのニーズを最もよく表し、Json.NETの直後にモデル化されるべきではないことを願っています。 肝心なのは、ServiceStackだけでなく、すべてのライブラリ作成者の作業が必要になるということですが、APIはJson.NETのAPIに直接似ているべきではありません。そうでないと、依存関係のように見えますが、dllはありません。

APIはJson.NETのAPIに直接似ているべきではありません

...またはその他の特定のプロバイダーの実装。

発表前に行われた議論の一部には、.Netチームがさまざまなライブラリから引き出して、さまざまな問題がどのように解決されたかを感じ取ってから、彼らが考えたものを使用するという考えが含まれていました。独自のアイデアと組み合わせたアイデア。 多くの点で、他の新しいJSONライブラリがどのように開発されるかと同じです。 これがフレームワークに含まれるのはたまたまです。

私たちは、自分たちで構築する必要のない高性能のJSONライブラリを用意しています。 :)

何かを議論する前に、その領域に関するMicrosoft Researchの結果を活用することを検討してください（より具体的には、分岐なし、FSM解析なし） https://www.microsoft.com/en-us/research/publication/mison-fast-json-parser -データ分析/

高性能のJSON解析のためにその方向に進んでいます---もちろんSpan<T>の他に---
cc @terrajobst @karelz

:( JSONに関するこのすべての議論は、テンプレートに関する私の質問が間違っていると感じさせます。

地獄だったので、この議論にもっと時間があればいいのにと思いますが、なぜそれが今のようになったのかはわかります。 4.6.1はアップグレードと一貫性を保つ必要があり、アップグレードと重大な変更は残りの部分になります。

コアと461のリコールされたパッケージをたくさん見てきましたが、このタイプまたは変更で修正されることを願っています。

カスケードの問題が私たちを悩ませるのではないかと心配しています。間違っていることを証明してください。

//どこにでもドットネット開発者

@ c0shea

[…]デフォルト以外の選択肢があることを強調するために、ドキュメントやリリースノートなどにプラグインを入手できれば素晴らしいと思います。

きっとそうなると思います。 ドキュメントには、 DIコンテナー、ロギングプロバイダー、 Swagger統合、 EFコアデータベースプロバイダーなど、複数のトピックの代替実装が既にリストされてい

@ phillip-haydon
テンプレートシステムはすでにカスタマイズ可能なテンプレートをサポートしており、既存のテンプレートには実際にはすでにいくつかのオプションがあります。 現在可能なことについては、たとえばdotnet new mvc --helpをチェックしてください。 たとえば、代替のJSONシリアライザー統合を使用して、これを簡単に拡張できると確信しています。そのための機能要求またはプル要求は、

@ mrange-できる限り厳密にするのが好きです。そうすることは、不適合なコードを変更する機能に依存しています。

他の会社の管理下にあるレガシーサービスとやり取りしている場合、問題のあるコードを変更する機能はほぼゼロです。 厳密な書き込みでさえ、より実行可能ですが、ここでそれ自体の問題がないわけではありません。問題のあるコードが不適合なオブジェクトを送信することを期待している場合はどうなるでしょうか。

たぶん、デフォルトで厳密なモードがあり、より寛大なモードに明示的に切り替えることができます

@poke本当に

さまざまなブラウザのJSONの解析がint64値を適切にサポートしておらず、longを文字列としてシリアル化/逆シリアル化する機能を提供していることを覚えておいてください。 それはあなたが激しく噛むまであなたが気付かないものの1つです。 これのバリエーションは、数値がデフォルトでintまたはlongに逆シリアル化されるかどうかを決定できることです。

さまざまなブラウザのJSONの解析がint64値を適切にサポートしておらず、longを文字列としてシリアル化/逆シリアル化する機能を提供していることを覚えておいてください。 それはあなたが激しく噛むまであなたが気付かないものの1つです。 これのバリエーションは、数値がデフォルトでintまたはlongに逆シリアル化されるかどうかを決定できることです。

....ああ、EcmaScript、すべてを2倍にしてくれてありがとう。 それがコードの他の部分で問題を引き起こしていないと確信しています...

純粋主義者として、私はこのようなものが嫌いです。
現実主義者として、私はこれに同意する必要があると思います。

新しいJSON実装の一部は.NetStandard 2.1に含まれますか？

私はこれを少しフォローしてきましたが、見逃したかどうかはわかりません。 レビューできる提案されたAPIサーフェスまたはインターフェースはありますか？ この提案のAPI表面積を確認することに興味があります。

レビューできる提案されたAPIサーフェスまたはインターフェースはありますか？

やるべきことはまだたくさんありますが、 がAPIレビューノートです。

更新：ロードマップもここで入手でき

では、aspnet 3.0apiはjson.netapiとどのように比較されますか？ また、ネイティブAPIを使用した新しいアプリの開発により、すべての目的と目的のjson.netが段階的に廃止されますか？

パフォーマンスを向上させるだけですか、それともjson.netのすべての機能を置き換えることを意味しますか？

これは素晴らしいニュースです。

@neueccとのコラボレーションを試みることを強くお勧めします。MessagePack 、 Utf8Json 、 ZeroFormatterなどでの彼の仕事は驚異的です。

@linkanywayの結果は、新しい割り当てなしAPIを提供しながら、json.netのサブセットを置き換えることです。

aspnetユーザーの大多数はjson.netの実装に強く依存しておらず、ほぼシームレスに移行できると思います。

レビューできる提案されたAPIサーフェスまたはインターフェースはありますか？

やるべきことはまだたくさんありますが、dotnet / corefx＃33216は始まりです。 これがAPIレビューノートです。

更新：ロードマップもここで入手でき

@khellang実際にc＃でjsonを記述できるlangヘルプを取得する予定ですか？

OSS方向へのもう1つの良い動き。 他の商用プラットフォームの開発者が、MSがすでに無料で行っているよりも優れたものを開発するように動機付けするか、コミュニティを本当に気にかけている場合は完全にOSSになります。

実際にc＃でjsonを書くことができるlangヘルプを取得する予定ですか？

@dotnetchris 「 わかりませんか？ JSONリテラル？ 私はそれが起こるとは思わない。 今後の「埋め込み言語」機能を見たことがありますか？ 特にJSONの場合は？

@khellangは確かに正しい方向への一歩ですが、私は完全なサポートを意味します。 リンクから同じサンプルオブジェクトを使用すると、次のようになります。

json v1 = { 
                    first: 0, 
                    second: ["s1", "s2" ] 
                }

var andCsharp = v1.second.Where(item => item.EndsWith("1"));

暗黙のタプル/値タプル/レコードオブジェクトの生成など、すべてが舞台裏でlangレベルで機能するようにするのに十分なブードゥーがあります。

逆に、コンパイラーはjsonサービスを呼び出し、クラスを作成してから、次のようにクラスのインスタンスを操作できます。

var v1 = "{ first: 0, second: ['s1', 's2' ] }".Deserialize<MyV1>();

編集：LOL @賛成票。

@dotnetchris https://github.com/dotnet/csharplang/issues/1238

@dotnetchris興味がある場合は、 https：//github.com/dotnet/roslyn/pull/24110に投票して

「組み込み」および「プラットフォーム提供」のJSONAPIは、別個の（netstandard）nugetパッケージではないことを意味しますか？ そうでない場合は、なぜですか？

新しいASP.NETCore共有フレームワークはnugetパッケージに依存できないと思いますか、それともできますか？

System.Json名前空間はすでにありませんか？ これは、.NET Core 3.0、そして最終的には.NETStandardで使用/拡張される名前空間ですか。 その名前空間は、Xamarin.Android 7.1以降、Xamarin.iOS 10.8以降、およびXamarin.Mac 3.0以降ですでに使用されています（あまり使用されていない可能性がありますが、利用可能です😅）。

これを削除すると、下位互換性が失われます。 それを残して新しいAPIを開始すると、混乱が生じる可能性があります。 APIを削除せずに拡張/拡張すると、新しいAPIを追加するときに少し制限される場合があります。

ストリームだけでなく他のソースとターゲットもあるので、JsonReader / JsonWriterのインターフェースがあると便利です。 たとえば、MongoDBにはJSON.NETも使用しています。 高速で、アプリケーションで複数のシリアライザーを維持する必要はありません。

パフォーマンスに少し悪影響を与える可能性があることは知っていますが、非常に便利です。

@SebastianStehle ：JsonReader / JsonWriterは高レベルの抽象化です。terrajobstのコメントを参照してください

3.0の計画は次のとおりです。

1. 組み込みの高性能JSONAPI。 低レベルのリーダー/ライター、ストリームベースのリーダー/ライター、および>シリアライザー。
2. ASP.NET Coreは、JSONコンポーネントにプラグインできます。

3.0のASP.NETのテンプレートが何を使用するかについては自由形式の質問があります。 3.0までに提供できる忠実度によっては、Json.NET統合パッケージをプルする場合があります。 ただし、目標は、デフォルトで組み込みのものにのみ依存するのに十分な忠実度とパリティを提供することです。

高レベルで使いやすいAPIは、ストリームとの間で簡単に逆シリアル化するためにストリームにラップされます（これは、シリアル化するときに最も一般的です。ストリームを使用できないシナリオで最高のパフォーマンスが必要な場合は、低レベルを使用する必要がありますSpan<T>またはMemory<T>で動作するレベルAPI。特に、データがすでに手元にある/メモリ内にある場合は、これらを使用し、非同期のオーバーヘッドはありません。

@TsengSR

https://github.com/neuecc/Utf8Jsonは、パフォーマンス上の理由（仮想呼び出しと割り当て）のため、カスタムリーダー/ライターを作成する機能を提供していません。彼らは同じ道を進みたいと思っていました。 しかし、これまでのところ、シリアル化コードはまだ見ていません。

@ JonasZ95と@gregsdennisに同意します。実装が、同じJSON.Net実装の詳細を単純に抽象化したものではなく、どのように見えるかに焦点を当てることを願っています。

また、2つの別々の機能としてアプローチする必要があると思います...

1. シリアル化/逆シリアル化
2. 上記のシリアル化と逆シリアル化のjsonバージョン。

うまくいけば、ASP.NET Coreフレームワークは、JSON固有の抽象化ではなく、一般的なシリアル化の抽象化を使用します。

拡張性に関しては、フレームワークが抽象化（抽象クラ​​スではなくインターフェース）にコーディングするDI手法を使用し、単にローカルのデフォルトを提供することを望んでいます。 JSONライブラリの作成者の観点からは、インターフェイスのライブラリ実装を使用するASP.NET Coreアダプタークラスを提供し、ライブラリアダプターを使用するようにASP.NET Coreを構成するだけなので、これは最大の拡張性を提供します。

サードパーティライブラリの実装は次のようになります。
`` `C＃
//サードパーティのライブラリを参照します
Newtonsoft.Jsonを使用します。

//簡潔にするための非常に素朴な例
//要点を述べる
パブリッククラスNewtonsoftAdapter：ISerializer
{{
プライベートJsonSerializerSettings_settings;
プライベートフォーマット_format;

public NewtonsoftAdapter(JsonSerializerSettings Configuration, Formatting FormatOption)
{
    _settings = Configuration;
    _format = FormatOption;
}

    // interface method
public string Serialize<T>(T Subject)
{
    return JsonConvert.SerializeObject(Subject, _format, _settings);
}

    // interface method
public T Deserialize<T>(string SerializedContent)
{
    return JsonConvert.DeserializeObject<T>(SerializedContent, _settings);
}

}

..。

//サードパーティのカスタマイズオプションを使用してアダプタを設定します
var settings = new JsonSerializerSettings
{{
MissingMemberHandling = Newtonsoft.Json.MissingMemberHandling.Ignore
};
var adapter = new NewtonsoftAdapter（settings、Formatting.Indented）;

//asp.netコアを構成します
//アダプタがISerializer（またはあなたが思いついた名前）を実装する場所
//ライブラリの作成者は、独自のUseXYZ（）拡張メソッドを提供することもできます。
app.UseSerializer（adapter）;
`` `

JSONのような構造化テキストを含め、SIMDベースのテキスト解析には多くの進歩がありました。 .NET Coreでの作業がこのパフォーマンスレベルに近づく可能性はありますか？ これらのテクニックを使用する方法はありますか？

ねえ、Microsoft Researchでさえ、いくつかの新しい高性能ソリューションがあります！

@AnthonyMastreanこれを持ってきてくれてありがとう。 また、この現在のJsonimplがsimdjsonとどのように比較されるかを理解するためのベンチマークにも興味があります。

ちなみに、simdjsonの作者は、まだこのプロジェクトの完全な公開に取り組んでいると言っています（私はもっとドキュメントだと思います）。 今のところ、 HNでこのプロジェクトの興味深い議論を読むことができます。

これらのテクニックを使用する方法はありますか？

.NET Core 3.0はたまたまプラットフォームに依存する組み込み関数を大量に出荷しているので、間違いなく実行可能です😄

Webスコープでは、ネットワークが主要なボトルネックであり、数秒でギガバイトを解析できるのはすばらしいことですが、それはWebプロジェクトにはあまり役立たないと思います。

誤解しないでください。このようなパフォーマンスの最適化は非常に優れており、非常に小さなJSONドキュメントでもメリットが得られる可能性があります。 しかし今のところ、新しいライブラリの焦点は、メモリ割り当てを回避し、すべてをネットワーク層に非常に近づけることだと思います。 それだけでも、JSON.NETよりもパフォーマンスが大幅に向上するはずです。 しかし、最初の作業が完了したら、追加の最適化を検討することは別の話かもしれません。

私が働いている場所では、毎日テラバイトのJSONを解析しています。 .NETとF＃を使用して多くのJSONドキュメントを処理する他のユーザーも知っています。 JSONは、単なるサーバー=>ブラウザー転送メカニズム以上のものになりました。 純粋なバックエンドシナリオで多く使用されます。

OFC; バックエンドがAVRO / Protobufのようなバイナリ形式に切り替える方が良いでしょうが、それはしばしば困難であり、JSONにはいくつかの利点があります（私は惜しみなく認めます）。 本当に高速なJSONパーサーを使用すると、私たちと同様の企業にとって、文字通り月額10,000ドルを節約できます。

@pokeこのプロジェクトは

.NET Core 3.0のこの特定の最適化手法に取り組むには遅すぎるという考えには同意できますが、将来的に最適化が可能になることを確認するために、今すぐ調査を行うことを望んでいます（つまり、変更を壊すことなく） ）。

JSONをC＃クラスにマッピングするための属性やその他のものを定義する統合マッピングアセンブリ（ 'System.Text.Json.Mapping'）のようなものを作成する方が良いかもしれませんか？ これを実装した後、既存のすべてのJSONパーサー/ライターを採用して統合マッピングを使用できます。 これにより、すべての.NET標準アプリケーションが問題なく異なるJSONライブラリ間で移行できるようになります。

@AlexeiScherbakov新しい抽象化は実際にはそれほど役に立ちません。 共通の抽象化を選択することで、自分自身を再び制限するだけで、抽象化を使用できず、さらに多くを必要とする新しいライブラリが常に存在します。 ロギングなど、常にそのようになっています。

この新しい実装に基づいて新しい抽象化を作成しても、特にライブラリの機能が大幅に少なくなるように設計されている場合は、メリットがないと思います。

そして、実際には、DataContract / DataMemberの形式で既存のnetstandard抽象化がすでに存在します。これは、このライブラリが最終的に尊重されることを願っています（その抽象化がいくらか制限されている場合でも）。

無視属性以外に、10億の新しい属性とシナリオを用意することはできません。 JSONをクラスに1：1でマッピングしたい場合は、標準外のことを実行したり、レガシーをサポートしたりする場合は、json.netを使用してください。

個人的には、JSON <=> C＃クラスについてはあまり気にしません。 JSONの解析/書き込みの概念を、作成されたC＃オブジェクトモデルとJSONモデルから分離することが重要だと思います。
そうすれば、私（JSON <=> C＃クラスについてはあまり気にしない）は、ある種のオブジェクトモデルをラウンドトリップすることなく、非常に効率的なパーサーを持つことができます。

@mrangeそれがリーダーとライターの目的です

それは、プラットフォームが提供するJSONAPIでReader / Writer APIを期待できることを意味しますか？ リーダー/ライターパターンは最も効率的なパターンですか？

現在、 System.Text.Jsonは

• Utf8JsonReader -UTF-8でエンコードされたJSONテキストを読み取るための高速でキャッシュされていない転送専用の方法。
• Utf8JsonWriter -^ Utf8JsonReaderと同じですが、書き込み用です。
• JsonDocument -JSONペイロード用の読み取り専用のランダムアクセスドキュメントモデル。

上記のすべてのタイプは、（多かれ少なかれ）割り当てが不要である必要があります👍

simdjsonの論文を投稿しました： https ：//arxiv.org/abs/1902.08318

simdjsonのC＃ポートで進行中の作業もあります： //github.com/EgorBo/SimdJsonSharp

cc @EgorBo

JSONをC＃クラスにマッピングするための属性やその他のものを定義する統合マッピングアセンブリ（ 'System.Text.Json.Mapping'）のようなものを作成する方が良いかもしれませんか？ これを実装した後、既存のすべてのJSONパーサー/ライターを採用して統合マッピングを使用できます。 これにより、すべての.NET標準アプリケーションが問題なく異なるJSONライブラリ間で移行できるようになります。

新しい抽象化が属性に依存しないことを本当に望んでいます。 基盤となるライブラリでクリーンなPOCOオブジェクトを使用し、DIを使用して、実装について知る必要がないようにしています。 実装に必要な属性で基礎となるクラスを装飾したくはありません。 これにより、既存のドメインオブジェクトをjsonにマッピングするだけの追加のクラスがUIレイヤーに作成される可能性があります。

おそらく、jsonからc＃クラスへの1-1マッピングの方が良いアプローチです。少なくとも、ビューモデルタイプのクラスが他の場合に必要な場合でも、新しいクラスの作成を回避できる場合があります。

ただし、不要なプロパティを無視し、少なくともシリアル化の側面の一部（キャメルケースとパスカルケースなど）を制御する何らかの方法があれば、それは素晴らしいことです。

@mrangeそれがリーダーとライターの目的です

@davidfowlそれは、新しいAPIがこのルートを進んでいることを意味しますか？ デザインは完成しましたか？

私たちが話しているしています。 関連する問題は次のように述べています。

• 時間の制約のため、またフィードバックを収集するために、機能セットは3.0の最小実行可能製品を対象としています。
• 単純なPOCOオブジェクトシナリオが対象です。 これらは通常、DTOシナリオに使用されます。
• 以降のリリースおよびコミュニティによって新機能に拡張できるように設計されたAPI。
• さまざまなオプションを定義するための設計時属性ですが、実行時の変更もサポートします。
• 互換性のある標準リフレクションへのフォールバックを備えたILEmitを使用した高性能。

また、列挙型変換、null処理、ラクダとPascalCasingなどのサポートをどのように計画しているかについても詳しく説明します。

これについてフィードバックがある場合は、その問題またはプルリクエストにコメントを残す必要があります。

@lemireうわー、それは本当にクールです。 simdjsonは確かに超高速です。

TechEmpowerのJSONシリアル化ベンチマークを実装できる可能性はありますか？ （私はそれがもっと多くの仕事になることを知っています）

私はこれらの実装を見つけました： TechEmpowerリポジトリとASP.NETリポジトリ。

@KPixelこれはシリアル化ですよね？ 一方、simdjsonはパーサーです...用語について混乱しない限り、これらのことは反対の方向に進みますか？

私の悪い。 私は（パーサーを使用する）逆シリアル化部分があると仮定しました。

System.Text.Jsonは.net標準のnugetパッケージになりますか？ またはそれは.netコア3.0でのみ利用可能なものですか？

@ John0Kingはこちらをご覧ください： //github.com/dotnet/corefx/blob/master/src/System.Text.Json/source_package/README.md

使いやすさも新しいJSONパッケージの焦点になるはずだと思います。 私が持つべきだと思う機能の1つは、JSONスキーマ検証のサポートです。 Newtonsoftはその料金を請求します。 これは、XMLスキーマ検証の場合と同様に、プラットフォームで無料で提供する必要があるほど基本的なものです。

@ jemiller0私の印象では、XML検証はやや複雑であり、JSONスキーマは実際の言葉で採用されています。 追加の手順として、いつでもライブラリを介してスキーマチェックを行うことができます...確かに、これにはソフトウェアライセンスの取得が含まれる場合がありますが、それは大したことですか？

@lemireはい、オープンソースソフトウェアを開発していて、ソフトウェアをすべての人が利用できるようにしたいのであれば、それは大きな問題です。 XML解析は混合バッグではありません。 できます。 JSONスキーマ検証でも同じです。 これを行うための組み込みの無料の方法がないため、.NETプラットフォームは競争力がなくなります。

私は現実の世界で使用されているjsonスキーマを見たことがありません。 それでも、ここで説明する実装の一部であってはなりません。 そして、json.netの他の10億の機能や癖のどれもここで実装されるべきではありません。 これは、超軽量で高速な実装にすぎません。 json検証をサポートするためにjson.netのライセンスが必要であることに不満がある場合。 独自のオープンソース実装を作成し、自由に利用できるようにします。

@ jemiller0

私は本当に興味があります：他のプログラミング言語は標準ライブラリでJSONスキーマサポートを提供していますか？

このライブラリの目標は、JSONを操作するための高性能で低レベルのライブラリになることです。 それ以外のものは、JSON.NETのより高度な機能のほとんどとJSONスキーマを含み、これには含まれません。

JSONスキーマの検証が必要な場合は、このライブラリの上にバリデーターを自由に実装できます。バリデーターは、それを実行できるように十分に低レベルである必要があります。

標準ライブラリでJSONスキーマの検証を行うことは、プラットフォームが競争力があるかどうかとは関係がないと思います。

このライブラリの目標は、JSONを操作するための高性能で低レベルのライブラリになることです。 それ以外のものは、JSON.NETのより高度な機能のほとんどを含み、これには含まれません。

Newtonsoft.Jsonのドロップイン置換として設計された高レベルの機能も含まれることを除いて😊

@pokeあなたは、私と同じように、あなたが望んでいる意見を何でも持つ権利があります。 XMLは至る所で使用されています。 したがって、当然のことながら、Microsoftは.NETFrameworkに検証サポートを含めました。 現在、JSONは大流行しており、構成ファイルやWeb APIなど、あらゆる場所で使用されています。これまでXMLでサポートされていたのと同じレベルのJSONをサポートすることは理にかなっています。 個人的には、Microsoftがそもそもサードパーティのソフトウェアを利用しているのは少しばかげていると思います。 これは、プラットフォームのコア機能である必要があります。

@lemire間もなくPythonをチェックします。 その時点で、それが組み込みであるか、簡単にインストールできるパッケージとして含まれていることがわかります。 そうでなければ、私は非常に驚きます。 私は今必要なものにNJsonSchemaを使用することを検討しています。 すぐに、ドキュメントがひどいのを見ることができます。 ええ、品質が良いかもしれないし、そうでないかもしれないサードパーティのライブラリに依存することは、完全にユビキタスでどこでも使用されているJSONを扱うようなものにとって素晴らしいアイデアです。 商用ソフトウェアか、ドキュメントのないサードパーティのパッケージに頼りましょう。 .NETは、Pythonのような他のプラットフォームと一致するだけではいけません。 彼らは、箱から出して適切なドキュメントを備えた高品質のソフトウェアを提供することによって、彼らを打ち負かす必要があります。 これは歴史的にそれがどのように機能してきたかです。 私が働いている場所では、誰もが.NETを嫌い、Pythonの使用を強制したいと思っています。 お気づきかどうかはわかりませんが、船を捨ててPythonに切り替える人が増えています。 JSONを検証するなどの簡単なことを行うには、ライセンスを購入する必要があると上司に伝えます。 そもそもなぜ.NETを使いたいのかという疑問があります。 これは、とにかくライセンスを取得できないオープンソースプロジェクト用であるという事実を気にしないでください。 うまくいけば、NJsonSchemaが正しく機能することがわかります。 私は、JSONを使用する人なら誰にでも明らかなはずの、フレームワークの明白な省略を指摘しているだけです。

私は仕事でJSONスキーマを使用していますが、半分良いJSONパーサー+ JSONスキーマバリデーターよりも本当に良いJSONパーサーを持っています。 また、AFAIKJSONスキーマは現在_draft_7です。 したがって、JSONスキーマを、スキーマと一緒にすばやく進化できる外部ライブラリとして使用することは、私にとって理にかなっています。 ただし、ロードマップにJSONスキーマを含めると便利です。

@ jemiller0

これまでXMLでサポートされていたのと同じレベルのJSONをサポートすることは理にかなっています。

.Netには、XSLTおよびXPathのサポートも含まれています。 「同じレベルのサポート」が必要な場合、それはJSON用のバージョンも必要になるという意味ではありませんか？

私が言おうとしているのは、JSONエコシステムはXMLエコシステムとは異なるということです。 どちらも使用パターンが異なり、関連するテクノロジーの使用数と標準化レベルも異なります。 また、XMLは、NuGet、git、またはGitHubが存在する前に.Netに追加されました。 今日では、サードパーティのライブラリに依存する方がはるかに簡単で、はるかに受け入れられています。

ですから、いや、「XMLにはこれがあったので、JSONにもそれが必要だ」と盲目的に言うのは意味がないと思います。

また、検証は単純に構文解析と直交しています。 ある時点で（おそらく別のパッケージで）検証サポートが追加されれば、私は絶対に大丈夫です。 ただし、適切な解析サポートにはまったく必要ありません。

APIRESTリクエストのデータを厳密に検証する方法が必要です。
APIを介して取得したjsonをエラーなしで保存し、後でコンマなどが続くためにJSで解析できないためです。

そして、なぜ今その要求を検証できないのですか？

@フィリップ・ヘイドン@ freerider7777私文書は整形式でない場合に任意のまともなJSONパーサーはJSONの仕様を遵守し、エラー（および/または警告を）投げるべきだと思います（例えば、それはカンマを末尾にしたとき）。 これはかなり基本的なことですが、JSONデータとスキーマの比較である検証とは異なります（少なくとも、私がこの用語を使用する方法です）。

https://tools.ietf.org/html/rfc7159

そこにある最大のソフトウェア開発会社の1つであるMicrosoftには、検証に取り組む人がいません。 高速パーサーがより重要です。 それはあなたが光速で無効なJSONを解析することを可能にします。 :-)高速検証が役立つ可能性があることは誰にも起こりませんでした。 これは、ASP.NET Coreと同じように、Webフォームへの高速でダムダウンされたアップグレードです。

そして、なぜ今その要求を検証できないのですか？
@ phillip-haydonこのようなjsonを使用したコントローラーコード：
ModelState.IsValid == true

🤦‍♂️

NSwag + System.ComponentModel.DataAnnotationsを使用して、jsonスキーマに基づいて検証を行うことができます。

<Project Sdk="Microsoft.NET.Sdk" >
  <ItemGroup>
    <PackageReference Include="NSwag.MsBuild" Version="12.0.10" />
  </ItemGroup>
  <ItemGroup>
    <Compile Remove="**\*.g.cs" />
  </ItemGroup>
  <ItemGroup>
    <SchemaFiles Include="$(MSBuildProjectDirectory)\..\schema\*.json" InProject="false" />
    <EmbeddedResource Include="$(MSBuildProjectDirectory)\..\schema\*.json" LinkBase="Messages\Schema" />
  </ItemGroup>
  <Target Name="GenerateMessageContracts" BeforeTargets="GenerateAssemblyInfo">
    <Exec Command="$(NSwagExe_Core21) jsonschema2csclient /name:%(SchemaFiles.Filename) /namespace:MyNamespace.Messages /input:%(SchemaFiles.FullPath) /output:$(MSBuildProjectDirectory)/Messages/%(SchemaFiles.Filename).g.cs" />
    <ItemGroup>
      <Compile Include="**\*.g.cs" />
    </ItemGroup>
  </Target>
</Project>

@lemireに同意します。JSONの構造を検証することと、スキーマに対してJSONを検証することには違いがあります。 マイクロソフトが前者を正しく実装するために時間と労力を費やしたことは間違いありません...後者はコーナーケースであり、このJSONライブラリの一般的な設計には適合しないと思います。 このJSONライブラリは、asp.netコアが動作するために必要な高速で効率的な解析を提供するためだけに設計されていることを明確にしたと確信しています。 newtonsoftのパーサーに付属の_extras_を含めるようには設計されていません。 （スレッドの前半にある@pokeのコメントを参照してください）。

彼らが意図的にこれをすべてのベルとホイッスルが付属するように設計しなかったという事実は、それを劣った製品にするとは思わない。

これはプレビュー4に同梱されていましたか？

System.Text.Json.Serialization.Policies.JsonValueConverterを作成する計画はありますかJson.netからコンバータークラスを置き換えることを許可するクラスパブリック？

System.Text.Json 、nugetを介した完全な.Netサポートとともに出荷されますか？ 完全な相互運用を確保し、完全なフレームワークのメリットを活用することは確かに素晴らしいことです。

System.Text.Jsonは最近、OOBを出荷するためのnetstandard2.0バイナリを生成するように変更されました。 https://github.com/dotnet/corefx/pull/37129 ：

可能であれば、.NET Core 3.0をターゲットにして、インボックスのSystem.Text.JsonAPIを入手する必要があります。 ただし、netstandard2.0をサポートする必要がある場合（たとえば、ライブラリ開発者の場合）、netstandard2.0と互換性のあるNuGetパッケージを使用できます。

完全なフレームワークのメリット

これらはまた何ですか？ 🤔

@khellang

私の好みは、完全なフレームワーク（4.5または許容可能な最小値）、標準、コアなど、複数のフレーバーを持つNugetです。 インボックスアセンブリを使用することをお勧めします。

上記のリンクされた問題はこのパッケージを参照していますが、サポートされていません：

https://www.nuget.org/packages/System.Text.Json

現在サポートされているパッケージはありますか？

私の好みは、完全なフレームワーク（4.5または許容可能な最小値）、標準、コアなど、複数のフレーバーを持つNugetです。

なぜあなたはそれを好むのですか？ マルチターゲットにする必要がない場合、つまり使用されるすべてのAPIが標準の一部である場合は、単一のターゲットを使用する方がはるかに優れています😊

現在サポートされているパッケージはありますか？

まだ出荷されていないと思います。 PRは数日前に統合されました。 そのパッケージは、以前はコミュニティプロジェクトでしたが、現在はMSに転送されています。

@khellangそれは

ネット標準バージョンでは、ネットフルバージョンで可能なネットコアバージョンから何かを省略しなければならない場合は、3つのフレーバーすべてを使用できるようにしたいと思います。 上記のリンクされた問題からの元のステートメントと同じ一般的な理由は、ユーザーがインボックスバージョンをターゲットにすることを好むことについてだと思います。

nugetパッケージへの参照を追加すると、適切な最も互換性のあるフレーバーが自動的に選択されます。 だから、それは大したことではありません。 消費ライブラリが正味標準の場合、正味標準フレーバーが選択されます。

インボックスフレーバーに対する私の一般的な好みは、 goto definitionときに、逆コンパイルされたソースを取得することです。 ネット標準ライブラリでgoto definitionすると、通常、 NotImplemented例外をスローするスタブソースのみが表示されます。

完全なフレームワークのメリット

これらはまた何ですか？ 🤔

多くのアプリケーションが.NETFrameworkを使用しているのは、.NET Coreを絶対に使用したくないからではなく、.NETCoreがオプションではないからです。 オプションの場合は.NETCoreを使用します。 Windows Server 2012（.NET Core 3.0の最小バージョン）より前のバージョンのWindowsをターゲットにする必要がある場合は、.NETFrameworkを使用する必要があります。 Windows Server 2008 R2以下のサポートを終了することは非常に苦痛な決断だったと確信していますが、アップグレードしたくない/基本的に最初から再作成することを望まないサーバーを顧客に支払っているすべての企業にとって、非常に苦痛な決断です。少し新しいツールを使用できるようにするためです。

明日.NETFrameworkの使用をやめることができれば、私ほど幸せな人はいないでしょうが、.NET Core 3.0以降のすべてのWPFおよびWindowsフォームの機会があっても、Microsoftはサポートポリシーでそれを実質的に不可能にしています。 私はこれについてマイクロソフトを聞く人と話し合うことを試みましたが、残念ながら、メッセージが配信されたことを確認する電子メールをまだ受け取っていません。

@JesperTreetopは、企業で使用する価値のある.NET Coreのバージョンに対するLTSサポートの欠如は

@marksmeltzer昨日からのブログ投稿Introducing.NET 5は、.Net Core 3.1がLTSであり、2019年11月にリリースされる予定であることを示しています。

この新しいJSONシリアライザーはF＃タイプをサポートしますか？

@rlimanは現在、GuidまたはEnumをサポートしていないため、まだ長い道のりがあります。 私は、C＃nullableと同様のF＃オプションタイプの完全なサポートが必要であることに同意しますIMHO

個人的には、これは悪い建築設計の決定に対する急いでの解決策だと思います。 これはずっと前に行われていたはずです....今ではどこでも多くの苦痛を引き起こすでしょう...ライブラリ開発者からエンタープライズ開発者まで。

この新しい「機能」を「スムーズ」にする簡単な方法はありません。

これは、MSが最初に引き起こした問題を解決しようとしていることです。 そして今、誰もが代償を払わなければなりません。

NET Coreを使用すると、最初からワゴンは少し「スピーディー」であるように見えます...この純粋な「アジャイル」アプローチでは、少し速度を落とし、全員に息をのむようにする必要があるかもしれません。

ASP.NET Coreの場合と同様に、これらの「機能」（重大な変更）が新しい標準になりました。

私の意見では、ASP.NET Coreは、アーキテクチャ設計プロセスのやり直しを切実に必要としています。 なぜなら、これらの「後で修正する」機能を何度も作り続けているからです。

ASP.NET Coreは初期のベータ版であったため、開発を続けてきました...そしてそれは.NETの大幅な改善です。

しかし、MSチームは少し立ち止まって、ここで実際の問題にどのように対処できるかを考える必要があります。急いで一貫性のないアーキテクチャ設計の決定です。

戻って他のスレッドを読んでください...それは繰り返しのテーマのようです。

ですから、座って、より安定した製品を作るための最善のアプローチを再考する時が来たのかもしれません。

クラシック.NETはコアほど強力ではないかもしれません...しかし、2.0以降は非常に安定していて一貫性があります。

ただ私の意見です。

こんにちは@suncodefactory 、
少し前に、pplがオープンソースライブラリを使用していないことをmsで叫んだときのことを覚えていますが、今ではそうしていると非難されています：D
私の見解では、Aspnet / core MVCapiはmvc1 / 2以降非常に安定しています！ 2.0以降aspnetが安定していた理由は、aspnetがまったく変更/改善されなかったためです😄。
正直なところ、シリアル化ライブラリの高度な機能を使用している場合は、すべてのシリアライザーがすべての言語機能をサポートしているふりをする代わりに、それについて再考し、タスクに適したデータ構造で問題に取り組む機会があります。解決すべき間違った問題、およびシリアル化を使用する間違った方法。
明確性、下位互換性、および将来の拡張機能が、シリアル化可能なdtoを駆動し、一般的なビジネスロジックオブジェクトで使用される非常に異なるトレードオフです（これらはプライベートであり、多くの機能を備えています）。

マイクロサービスをネットフレームワークからLinux（ネットコア）に移行することは、製品チームの努力なしに可能です。 君たちが何を話しているのかわからない。 マイクロソフトは、長い間延期されてきたこのような変更の実装を加速する素晴らしい仕事をしています。

こんにちは@suncodefactory 、
少し前に、pplがオープンソースライブラリを使用していないことをmsで叫んだときのことを覚えていますが、今ではそうしていると非難されています：D

私にとって重要なのはサードパーティのライブラリではありません...この特定のケースでは欠けているか、まったく間違っている建築設計についてです。

また、私は古典的なasp.netについて話したことはありません...私は.NET Framework2.0について話していました。 そして、それが安定した理由は、あなたが誤って主張したように改善がなかったからではありませんでした（.netコアは.NET4.6.1に基づいているため）。 その理由は、それがよく計画され、設計されていたからです。

aspnetコアがこの特定のスレッドとは何の関係もない古典的なasp.netmvcと比べてどれほど優れているかについては。

このスレッドは、MSが完全に考えずにもう一度出荷しようとしている重大な変更に関するものです。

マイクロサービスをネットフレームワークからLinux（ネットコア）に移行することは、製品チームの努力なしに可能です。 君たちが何を話しているのかわからない。 マイクロソフトは、長い間延期されてきたこのような変更の実装を加速する素晴らしい仕事をしています。

このような変更はまったく起こらないはずです.....それで、あなたは変更を壊すことに満足していますか？

そして、asp.netコアチームが変更の出荷で素晴らしい仕事をしていると言うことは、単に真実ではありません。

私はベータ3からasp.netコアを使用して開発してきましたが、アーキテクチャ設計プロセスが不足していると確信しています。

asp.netコアがクラシックと比べてどれほど優れているかについては...クラシックよりも優れていると私も信じているので、異論はありません。

しかし、asp.netコアがクラシックよりも優れているからといって、優れたジョブアーキテクチャ設計を行っているとは限りません。 これら2つは完全に異なるトピックです。

この議論を.NETCore 3のJSON機能に限定できますか？

このような変更はまったく起こらないはずです.....それで、あなたは変更を壊すことに満足していますか？

それで、改善は行われるべきではありませんか？ ソフトウェアを進化させ、成長させ、より良くしたくないのに、なぜあなたはプログラマーでさえあるのですか？

@suncodefactory

このような変更はまったく起こらないはずです.....それで、あなたは変更を壊すことに満足していますか？

ああ、さあ、あなたはそれを「破壊的な変化」のように聞こえるようにします。それはあなたがあなたのプロジェクトを廃棄して最初から始めなければならないことを意味します。

ASP.NET Core 2.x / 3.0にあった、以上を必要とする重大な変更の数を数えることができます

• 別のパッケージを参照する
• 別の名前空間を使用する
• 5行を超えるコードを変更する
• 1〜2行のコード（つまり、Optionsクラスからのプロパティ）の削除

??

@suncodefactory

このスレッドは、MSが完全に考えずにもう一度出荷しようとしている重大な変更に関するものです。

これは実際にどのように_重大な_変更ですか？ 新しいJSONAPIは、.NET Coreで導入されたまったく新しいAPIのセットであり、既存のものを削除したり壊したりすることはありません。 はい、さまざまな最適化の機会を提供するため、最終的には物事やライブラリがそれに切り替わるのがわかりますが、それをコードに適用する必要はありません。

特にASP.NETCoreについて言えば、_「この特定のスレッドとは何の関係もありません」_が、より高度な機能のいくつかに依存している場合は、Newtonsoft.Jsonを引き続き使用することを選択できます。 はい、それを機能させるためにいくつかのコードを変更する必要がありますが、実際に新しいバージョンにアップグレードしたい場合にのみそれを行う必要があることを考えると、それが本当に壊れているとは思いません。 それは今では素晴らしいことです。選択肢が増えます。

何らかの理由でこれが気に入らない場合は、既知の安定した固定機能セットである.NETFrameworkを自由に使用してください。 それはかなり長い間そこにとどまるでしょう、それであなたは完全にそれに頼ることができます。 ただし、_「この特定のスレッドとは何の関係もない」_場合は、このスレッドを使用して新しいものに反対するアジェンダを広めるのをやめてください。

EFコアユーザーからの2つの質問。

1. System.Text.Json循環参照をサポートしますか？ 循環参照は、クラス間で双方向に移動するナビゲーションリンクがあるEFコアデータで発生する可能性があります。 Json.NETは次のような設定でこれを処理します
   c# var json = JsonConvert.SerializeObject(entities, new JsonSerializerSettings() { PreserveReferencesHandling = PreserveReferencesHandling.Objects, ReferenceLoopHandling = ReferenceLoopHandling.Ignore });
2. プライベートセッターとプライベートコンストラクターを備えたDDDスタイルのクラスの台頭により、 System.Text.Jsonこれらのタイプのクラスを逆シリアル化できますか？

@JonPSmithIMOそれは問題ではないはずです。 エンティティを直接シリアル化しないでください。 投影をシリアル化する必要があります。 これにより、循環参照が回避され、すべてのデータが公開されるわけではありません。特に、機密性が高くなる可能性のあるプロパティをエンティティに追加する場合はなおさらです。

@JonPSmith ：

1. エンティティを直接逆シリアル化することを推奨するベストプラクティスを見たことがありません（最も単純なチュートリアルの例を除く）。 循環参照には常にコストがかかります。 すでに処理されたオブジェクトを追跡する必要があります。つまり、メモリ割り当てと追加のCPUサイクルです。 しかし、新しいJSONライブラリのメールの目標の1つは、これらのメモリ割り当てを正確に回避することです。
2. ドメインモデルにシリアル化することは決してないため、特にWebApi呼び出しなどのWeb要求を介してデータを取得する場合は、無効です。 DDDでは、常にイベント/コマンドを操作し、コマンドをWebアプリケーションに送信し、リポジトリからエンティティを取得（および脱水）し（ORMマッピングまたはEventSourcingを介して）、コマンドを適用し、永続化する必要があります。

その上、新しいJSONAPIは高性能シナリオ用です。 豊富な機能セットが必要なその他すべての場合は、JSON.NETまたはニーズを満たすものを引き続き使用します（使用する必要があります）。

@suncodefactoryこれは

たとえば、 Microsoft.Extensions.Configuration.Json2.2.0を見てください。これはNewtonsoft.Json11.0.2に依存しています。 これは構成パッケージです。 HTTPリクエスト処理やASP.NETCoreMVCとは何の関係もありません。 または、JSONWebトークンの処理に使用するMicrosoft.IdentityModel.Protocols.OpenIdConnectを見てください。 これは、可能な限り多くのパフォーマンスを必要とするホットパスです。 JSON.NETは、どの標準でも低速のライブラリではありませんが、パフォーマンス、機能の豊富さ、および広範なユーザーシナリオのサポートのバランスをとっています。 JSON.NETが存在するため、Microsoftの新しいJSONライブラリはそれを行う必要はありません。 したがって、最大のパフォーマンスで絶対的な基本を処理することに集中できます。

.NETは常にSystem.Runtime.Serialization.Jsonに独自のJSONシリアル化ソリューションを持っていましたが、

アプリケーションでNewtonsoft.Jsonを参照し、以前と同様に要求/応答データの逆シリアル化/シリアル化パイプラインとして引き続き使用できます。 そしてこれからは、コアフレームワークがどのバージョンに依存しているかを気にせずにそうすることができるようになります。 それは誰にとっても勝利です。

@ phillip-haydonと@TsengSRにご意見をお寄せいただきありがとうございます。 私はこれらの機能がサポートされるかどうか尋ねていました、そしてあなたはそれがサポートされていないと言います、それは理解して受け入れます。 EFコアクラスをシリアル化/逆シリアル化する必要がある場合は、引き続きJson.NETを使用します。

ところで。 DDDスタイルのEFコアエンティティクラスをシリアル化/逆シリアル化する正当な理由があります。 Seed from Productionと呼ばれる機能を含むライブラリがあります。これにより、開発者は本番データベースからデータのスナップショットを取得し、プライベートデータを匿名化して、そのスナップショットを使用して新しいデータベースにシードできます。

私はクライアントの1つにこの機能が必要でした。クライアントのためだけに作成するのではなく、オープンソースライブラリEfCore.TestSupportに組み込んで、他の人が使用できるようにしました（クライアントが料金を支払う必要はありませんでした）。

[DataContract] 、 [DataMember]とその友達をサポートする計画はありますか？

今日、これは、それを使用するプロジェクトへのシリアル化ライブラリへの依存関係をもたらさない方法で、型をシリアル化/逆シリアル化する方法（フィールド名など）を定義する方法です。

現在のJsonNamingPolicyは文字列のみを受け取るため、メンバーの属性を検査する方法はありません。

やあ。
マイクロサービスをDotNetCore 3プレビュー6に切り替えようとしましたが、不変の参照型を逆シリアル化できませんでした。不変のプロパティを持つクラス（セッターなし）と、すべてのプロパティを設定するコンストラクターが1つだけです。 Json.netはこれらのクラスを正しく処理します。
これは必要なSystem.Text.JsonAPIの問題ですか、それともそれをサポートする計画ですか？
ご回答ありがとうございます

@agjinihttps ： //github.com/dotnet/corefx/issues/38569を参照してください

@khellangに感謝します。
サポートは実際に計画されていますが、3.0リリースでは計画されていません。
DotNet Core 3でJson.netを引き続き使用することは可能のようですが、その方法がわかりません（パッケージ参照を追加するだけでは不十分です）。 それを行う方法はありますか？

@agjini ：

C# services.AddControllers() .AddNewtonsoftJson()

助けてくれてありがとう。
できます ！
すべてが説明されている移行ガイドを見逃しました：

https://docs.microsoft.com/fr-fr/aspnet/core/migration/22-to-30?view=aspnetcore-2.2&tabs=visual-studio

IMO json.netは半分焼き付けられており、既存のコードを壊すデフォルト（つまり、シグナリング用）にするのは時期尚早でした。

一方、.NET Core 2.2から3.0への移行はメジャーバージョンのアップグレードであり、.NET Coreチームがセマンティックバージョニングに厳密に従っていない場合でも、明示的な変更なしに1つのバージョンから別のバージョンにアップグレードするときに問題が発生することが予想されます。 （パイプラインにNewtonsoftのライブラリを明示的に追加するような）

これは発表であり、問​​題ではありません。

コミュニティには改善に反対する声がたくさんありますが、新しい高性能フレームワークとして、速度の悪さは受け入れられません。

以前にも言われたことは知っていますが、私の願いも付け加えたいと思います。

不変のオブジェクトがあれば本当に素晴らしいでしょう。 Json.NETをMVCパイプラインに追加することで可能であることはわかっていますが、私の場合、 Microsoft.AspNet.WebApi.Clientピア依存関係のどこかに実装されているReadAsAsync<>を使用しているため、テストはすべて失敗します。 Microsoft.AspNet.WebApi.ClientそしてそれはSystem.Text.Json依存しています

お客様が.NETStandardクラスライブラリを使用して、.NET Standardをサポートする任意のプラットフォームで作業できるように、.NET標準クラスライブラリを提供しています。 クラスライブラリでSystem.Text.Jsonを使用する必要があります。 .NET StandardでSystem.Text.Jsonをサポートする計画は何ですか？

@alsami

不変のオブジェクトがあれば本当に素晴らしいでしょう。

他の人がそれを変更するのを防ぐ機能だけが必要ですか、それともパーツがスマートに置き換えられた新しいインスタンスを作成する機能も必要ですか（不変のコレクションやRoslynなど）？ 前者が必要な場合は、今後のJsonDocument DOMAPIで対応します。

@ mwoo-o

.NET StandardでSystem.Text.Jsonをサポートする計画は何ですか？

.NET Standard 2.0のNuGetパッケージとして利用できます： System.Text.Json 。

@terrajobst

ありがとう。 このSystem.Text.Jsonはいつ.NETStandard SDKに含まれますか？
.NET標準3.0（または他のいくつかの新しいリリースバージョン）にはSystem.Text.Jsonパッケージが含まれますか？ .NET Core 3.0 SDKの製品リリースで発生しますか？

@terrajobst

DeserializeメソッドをPipeReaderで機能させる計画はありますか？ または、逆シリアル化を開始したときにすべてのデータがないストリーミングシナリオで使用できるパッチメソッドを追加します。

提案されたAPIの簡略版は次のとおりです。

private async ValueTask<T> Deserialize<T>(PipeReader reader, CancellationToken cancellationToken) 
    where T: new()
{
    T model = new T();
    while (!cancellationToken.IsCancellationRequested)
    {
        ReadResult readResult = await reader.ReadAsync(cancellationToken);
        ReadOnlySequence<byte> buffer = readResult.Buffer;

        if (readResult.IsCanceled) break;
        if (buffer.IsEmpty && readResult.IsCompleted) break;

        SequencePosition consumed = JsonSerializer.Patch(model, buffer, readResult.IsCompleted);
        reader.AdvanceTo(consumed, buffer.End);               
    }

    return model;
}

public SequencePosition Patch<T>(T model, ReadOnlySequence<byte> jsonData, bool isFinalBlock, JsonSerializerOptions options = null)
{
      ...            
}

@terrajobst

他の人がそれを変異させるのを防ぐ能力

現在これのみ。 本当に「data-transfer-objects」のためだけです。 素晴らしいニュース！

@ mwoo-o

ありがとう。 このSystem.Text.Jsonはいつ.NETStandard SDKに含まれますか？
.NET標準3.0（または他のいくつかの新しいリリースバージョン）にはSystem.Text.Jsonパッケージが含まれますか？ .NET Core 3.0 SDKの製品リリースで発生しますか？

.NET標準SDKはありません。 .NET StandardはAPIサーフェスであり、サポートされているすべてのプラットフォームで使用できます。 System.Text.Jsonは、.NET標準でサポートされているサポートされているプラ​​ットフォームをターゲットとして実行される任意のアプリケーションで出荷できます。.NET実装サポートを参照してください。

@TsengSR

.NET標準SDKはありません。 .NET StandardはAPIサーフェスであり、サポートされているすべてのプラットフォームで使用できます。

さて、APIを使用できるようにするプロジェクトタイプがあります。 @ mwoo-oは、.NET StandardにSystem.Text.Jsonを追加する計画があるかどうかを尋ねていると思います。 答えはノーだ。 現在、これをNuGetパッケージのままにすることを計画しています。

それはひどいです。プロジェクトに適用するには機能が少なすぎます。