Google protobuf について頭を悩ませようとしています。C# で protobuf の実装をいくつか見つけましたが、1 つの機能が欠けているようです: 属性で装飾された既存の C# クラスから .proto ファイルを自動的に生成する機能です。
.proto ファイルから自動生成された C# クラスを使用するのではなく、このようにしたい理由は、プロジェクトで C# クラスが既に定義されていて、ProtoBuf を満たすためだけにそれらを複製したくないためです。
誰かがそのようなシナリオに遭遇しましたか?
アップデート
これは、C# クラスを装飾するだけで、.proto ファイルを使用せずに protobuf を使用することは可能ですか?
朗報です。あなたが説明したこと（既存のC＃クラスを持つ）は、protobuf-netの予想されるユースケースです。すべての .proto のもの (「protogen」、VS アドインなど) はすべて、後付けとして追加されました。protobuf-net のコアは、それらを認識していないか、気にしていません。
protocol buffers は、実装間で共有され、(場合によっては) コード生成に使用される DSL (.proto) を定義します。私が最初に protobuf-net を書いたとき、コード生成の側面は私の最大の関心事ではありませんでした。単純に、.NET 開発者は一般に (私自身も含めて) 「契約が先」ではなく「実装が先」の罪を犯しているということでした。
結果として、protobuf-netは動作するために.proto ファイルを必要としません。明確にシリアル化/逆シリアル化するには、属性付きクラスで十分です。Serializer.Serialize、.Mergeおよび.Deserialize（など）を使用するだけです。
そうは言っても; これには、非常に未開発で実験的なサポートが含まれています。
string proto = Serializer.GetProto<YourType>();
これはまだ完全ではありませんが、単純なタイプではうまくいくかもしれません。失敗する特定のケースがある場合は、お知らせください (コメントを追加するか、問題をログに記録してください)。でも; ほとんどの場合、.proto に関心のある人は、最初に .proto を書き、そこから作業します。
装飾されたタイプの動作例は、プロジェクトのホームページに示されています。WCF 属性、xml 属性、protobuf-net 属性のいずれを使用するかは完全にユーザー次第です (ただし、後者は、継承や数値レイアウトなどの特定のシリアル化ポイントをより詳細に制御できます)。
スキート射撃がここで実行されて大規模な上昇を遂げる前に、 protobuf.netを指摘させてください。