protobuf-net.Grpc: a gRPC contract you write as a C# interface

The service contract is an interface, not a .proto file

The central idea is that you describe a gRPC service the way you describe any other .NET contract. The README shows a service declared as an interface carrying the ServiceContract attribute, with an asynchronous method returning a ValueTask:

[ServiceContract]
public interface IMyAmazingService {
    ValueTask<SearchResponse> SearchAsync(SearchRequest request);
    // ...
}

On the server side you implement that interface, and on the client side you ask the system for an implementation of it:

var client = http.CreateGrpcService<IMyAmazingService>();
var results = await client.SearchAsync(request);

The README then shows the equivalent .proto, which is the clearest statement of the trade-off. The generated service would look like this:

service MyAmazingService {
    rpc Search (SearchRequest) returns (SearchResponse) {}
	// ...
}

The point of the comparison is that you keep a normal type model, with request and response as ordinary classes, and you skip a code generation step and the checked-in stubs it produces. The README also notes that it should work on all .NET languages that can generate something even remotely like a regular .NET type model, and the examples directory carries usage samples in C#, VB and F#.

Four packages, because the transport differs

Everything ships as pre-built packages on NuGet, and the README names the ones you are likely to want. protobuf-net.Grpc.AspNetCore is for servers using ASP.NET Core. protobuf-net.Grpc.ClientFactory is for clients resolved from dependency injection. protobuf-net.Grpc and Grpc.Net.Client cover clients using HttpClient. protobuf-net.Grpc.Native is for clients or servers using the native, unmanaged API. The split exists because protobuf-net.Grpc can sit on two different gRPC stacks. The README describes it as adding code-first support for services over gRPC using either the native Grpc.Core API, or the fully managed Grpc.Net.Client / Grpc.AspNetCore.Server API. Choosing the native package means the C core gRPC runtime under the hood; choosing the managed one means the call travels over HttpClient with no native dependency, which is what you want in environments where a native library is awkward. The documentation site points to a page explaining what each package is for.

Configuration is convention based until it is not

The README is brief about wiring, and deliberately so. You obviously need to tell the system the URI and so on, and it points to the Getting Started page for that. The useful detail is the shape of the configuration: usually it is convention based, and when convention is not enough there are various configuration options documented separately on the site. For a team used to the code-first style, this is the least documented part of the story, and the one to check before committing. Nothing in the README describes the option names, the defaults or the defaults' precedence rules, so treat the configuration page rather than the readme as the reference. There is also a separate note that build and usage tooling is available via protobuf-net.BuildTools, which covers the cases where you want to generate something rather than write the contract by hand.

What sits in the repository beside the readme

The repository layout shows a project with real depth, not a thin wrapper. There are src/ and tests/ directories, a docs/ folder, and an examples/ directory whose entries are more revealing than the readme: examples/dotnet-grpc/, examples/grpc/, examples/pb-grpc/, examples/pb-net-grpc/, examples/pb-net/, examples/perf/ and examples/wcf-port/. Two of those names deserve a second look. The perf/ example shows that the authors expect performance comparisons to matter. The wcf-port/ example implies an existing Windows Communication Foundation service surface being reproduced over gRPC, which is a common reason teams arrive at a code-first approach in the first place. The tree also carries global.json, nuget.config, Directory.Build.props, Directory.Packages.props and Directory.Packages.props style central package management files, plus get-version.ps1 and get-version.sh for versioning and a version.json file, and a ProtoBuf.snk signing key with a reflection.proto file in the root. The solution file is protobuf-net.Grpc.slnx with an older protobuf-net.Grpc.sln.old kept alongside it.

The trade-off: fewer moving parts, narrower ecosystem, one maintainer

The benefit is speed of iteration. When the contract is an interface, changing a method signature is a normal refactor in your own language, and there is no protoc step to rerun and no stub file to regenerate, review and keep in sync with the server. The cost is ecosystem. Code-first means the schema is expressed in language features rather than in a neutral IDL, so tools that read .proto files, such as gateway generators or cross language SDK generators, have nothing to read, and a second team writing the service in another language has no shared schema file to work from. A second cost is support concentration: the README states that protobuf-net.Grpc is created and maintained by Marc Gravell, the author of protobuf-net. The README is also careful to say the project makes use of tools from the grpc project but is not officially associated with, affiliated with, or endorsed by that project, which is worth remembering when you read its documentation and when you weigh it against the official gRPC for .NET stack.

Licence and release cadence to check before you depend on it

Two practical details. The licence field on the repository says Other, described as a custom licence that GitHub cannot classify, with the terms in the LICENSE file at the root, so that file is the one to read before the package enters a build. The README also mentions a SECURITY.md in the tree, so vulnerabilities have a defined route. On the release side, the project is moving: the last push was on 2026-10-12, and the recent versions are 1.3.14 from 2026-08-20, 1.3.6 from 2026-08-17 and 1.3.0 from 2026-08-16, which shows a patch level line at 1.3.x with several small increments close together. The repository is not archived, so work is continuing, but the package family is broad, with a separate package per hosting and transport combination, and each of those has its own versioning and its own upgrade to plan for.

Editorial conclusion

protobuf-net.Grpc suits .NET teams that want gRPC without maintaining generated code from .proto files, especially where the service contract already lives in C#, VB or F#. Skip it if your organisation standardises on protoc generated stubs, since the value here is precisely the absence of a codegen step, and skip it if you cannot accept a single maintainer project with a custom licence. Before adopting, open the LICENSE file, since the licence field on the repository says Other and the terms are not one of the standard ones, then map your hosting model onto the package list, choosing protobuf-net.Grpc.AspNetCore for an ASP.NET Core server and protobuf-net.Grpc.ClientFactory when clients come from dependency injection.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. protobuf-net/protobuf-net.Grpc on GitHub
4. README
5. Releases