Question

We’re developing a few services that communicate with each other via Protocol Buffers. All the services are written on .NET. I don’t foresee migrating them off of .NET. I don’t foresee using the same messages with services on other platforms.

The messages are currently written in .proto. The code generation step seems superfluous to me.

Aside from cross-platform compatibility (which is not a concern to us), is there any reason to write messages in .proto instead of directly in a .NET language?

Answer 1

Given the setup you describe (.NET-to-.NET, unlikely to need cross-platform), then I would say “no”. We do a lot of things that meet this category, and we just work code-first, i.e. we write the C# types, and just use them. This gives us total control and flexibility over the types, and avoids unnecessary build/tooling steps.

Indeed, that was actually the core motivation-for, and purpose-of protobuf-net: for it to be able to work from regular c# types without requiring definition in a DSL, like all other .NET serializers do (XmlSerializer, DataContractSerializer, JavaScriptSerializer, etc).

Note that while protobuf-net includes a .GetProto<T> feature, this has not yet been re-implemented in v2; however, that is next on my list now that the cross-platform precompiler is done and working. My point here is: it is likely that if there becomes a requirement to do cross-platform etc, then protobuf-net may be able to help generate the .proto for you from the existing contracts.

If you are concerned that you might at some point need interop to other platforms, stick to the core protobuf feature set. Avoid protobuf-net additions, like:

• inheritance
• .NET-specific type support (DateTime, decimal, etc)
• reference tracking
• dynamic type support