問題タブ [protobuf-net]

分散キャッシュ アプリケーションで .NET シリアル化をプロトコル バッファーに置き換えたところ、その結果は非常に印象的でした。私が気に入らない唯一のことは、基本メッセージ クラスとその子の間に依存関係を追加する必要があり、循環依存関係が作成されるという事実です。基本クラスに ProtoInclude でタグ付けする代わりの方法はありますか?

protobuf-net を WCF サービス ベースのソリューションに統合していますが、理解できない障害に遭遇しました。次のクラスは、ObjectId プロパティを除いてすべて正常にシリアル化されます。

これが私をいじっているクラスです：

運が悪いので、複数のことを試しました。どんな考えでも大歓迎です！

protobuf-net の変更ログで IList<> がサポートされていることに気付きましたが、「インターフェイスのインスタンスを作成できません」という例外が発生しています。IEnumerable<> に変更すると、人生はうまくいきます。この音は正しいですか？

ありがとう、マイク

また、これと他の回答があるドキュメントサイトはありますか? 初心者に質問するのは嫌いです。:)

私はおそらく何かを見落としていますが、後で拡張機能を提供するための簡単な方法にプロトコルバッファを取り組もうとしています。それは少し不明確に思えるので、私は直接問題に飛び込みます。

構造化データの記述を含むさまざまなタスクをサポートするアセンブリを作成しています。プロトコルバッファを使用する絶好のタイミング。プロトコルバッファを使用するプライマリクラスは、StateDefinitionと呼ばれます。これが私が思いついた.protoファイルです：

私の目標は、これらの_StateDefメッセージを、必要なフィールドで後で拡張できるようにすることでした。ただし、この拡張機能は、現在作成しているライブラリとは関係なく発生します。

Kagents.dll->StateDefinitionの解析などを処理します。

Kagents.dllを参照するもの->必要な状態を定義するための「extendGraphicsStateDef」を含むprotobuffファイルがあります。

「extendGraphicsStateDef」を定義すると、プロパティを使用してこれらのフィールドにアクセスし、面倒な「Extendible.AppendValue（）」およびGetValue（）構文を回避できるコードが生成されることを期待していました。

私が考案した解決策の1つは、ハックのようですが、次のような拡張メソッドを使用して、参照DLLでクラスを定義することです。

誰かがもっと良い方法を考えることができれば、私は大いに義務づけられるでしょう。=）また、問題の説明がどれほど明確になったかわからないので、何か説明や情報があれば教えてください。=）

編集：それで、これについてよく考えて、私が問題に間違ってアプローチしていることに気づいた後。StateReferenceは、さまざまなGameStateのリストを格納することになっています。また、StateDefinitionを格納します。これは、この状態参照の状態を記述する必要があります。現在、状態バッファーを別のクラス（GraphicsStateDef）に逆シリアル化しようとしていますが、実際には状態オブジェクト自体に逆シリアル化する必要があります。

したがって、StateDefinitionがストリームのコンテナーになり、「繰り返されるStateTypes requiredStates = 1」フィールドに十分な情報のみを抽出するように、設計を再考する必要があります。次に、参照アセンブリで、ストリームの残りの部分をそれぞれの状態に逆シリアル化できます。

これにアプローチする方法について誰かが推奨事項を持っていますか？いくつかのアイデアが策定されていますが、具体的なものは何もありません。他の人の意見を取り入れたいと思います。

私は一連のプロトコル バッファ (protobuf-net を使用) を持つシステムを作成しています。すべて継承する抽象クラスで次のようなものを定義したいと考えています。

ただし、プロトコル バッファ シリアル化には型引数が必要です。継承クラスの型を取得する効率的な方法はありますか?

例：

このようなクラス階層があります。これらのクラスには、私が除外した他の多くの詳細が含まれています。これは、これらのクラスのシリアル化の側面に焦点を当てるための単純化です。

また、多種多様なジェネリック型を持つジェネリック Query の自動生成された子孫が約 150 あります。例えば：

これらすべてのタイプに対して [ProtoInclude] も自動生成しました。例えば：

問題は、これらの 150 個の ProtoIncludes をどのようにデプロイするかです。論理的に見えるさまざまな組み合わせを試しましたが、どの属性がどこに存在するかに応じてさまざまな例外が発生します。上記の例で実際にシリアル化が必要な型は、W、X、Y、Z で、約 150 個しかありません。

protobuf-net はこのようなものにも対処できますか、それとも他の種類のシリアル化を試す必要がありますか?

Google protobuf について頭を悩ませようとしています。C# で protobuf の実装をいくつか見つけましたが、1 つの機能が欠けているようです: 属性で装飾された既存の C# クラスから .proto ファイルを自動的に生成する機能です。

.proto ファイルから自動生成された C# クラスを使用するのではなく、このようにしたい理由は、プロジェクトで C# クラスが既に定義されていて、ProtoBuf を満たすためだけにそれらを複製したくないためです。

誰かがそのようなシナリオに遭遇しましたか?

アップデート

これは、C# クラスを装飾するだけで、.proto ファイルを使用せずに protobuf を使用することは可能ですか?

Protobuf-Net を使用すると、パラメーターなしのコンストラクターを使用せずにクラスを逆シリアル化することはできないようですが、何か不足している可能性があります。

パラメーターなしのコンストラクターを持つ一部のクラスは必要ありません。使用できる属性やその他のテクニックはありますか?

Protobuf/Protobuf-net と 2 つのクラス (1 つは基本クラス、もう 1 つは基本から派生したクラス) を使用します。
リストをどのようにシリアライズ/デシリアライズしますか?

例えば：

そして、シリアル化される次のフィールド:

リストには SomeBase および SomeDerived オブジェクトが含まれていることに注意してください。

Int64として0のエンコーディングに問題があるようです。Int64okとしての他の値。

Int64.MinValueとして逆シリアル化されます

何か案が？

バグを確認します。_val == 0の場合、このクラスは正しくシリアル化されません

[ProtoContract]

このテストは失敗します

[テスト]