Support shared .NET contracts

Right now, gRPC seems to rely on Protobuf contracts to be shared between server and client. But for a .NET context, .proto files are somewhat strange.

I would like having a way to define services as interfaces and data contracts as POCOs in a separate .NET assembly that would then be referenced by both the server and the client. That way, one wouldn’t need to exchange .proto files but could rely on .NET mechanisms to share .NET-native types.

In a way, this would be a bit like WCF’s ChannelFactory<T> which also allowed you to connect to a hosted service when you already had the contracts around.

---

@JamesNK - Oct 2019 update:

protobuf-net.Grpc supports code-first gRPC without .proto code generation. It builds on top of grpc-dotnet, replacing the code generation serializer with protobuf-net.

protobuf-net.Grpc is available on NuGet today. There are currently no plans to support code-first in grpc-dotnet.

For more information about protobuf-net.Grpc, see https://protobuf-net.github.io/protobuf-net.Grpc/gettingstarted

[AlgorithmsAreCool]

@Kadajski

The point of making this request here is that we want to use GRPC and not a REST based API. GRPC has great features such as bi-directional streaming that are valuable to us.

Libraries like ProtoBuf-Net and even WCF have showed us that versioning POCO definitions is very possible and not overly cumbersome.

Besides, it is not like Protobuf has some magic that allows versioning to always work, you still have to follow rules when you update your definitions.

Lastly we don’t want today really have to write a reflection based shim.

We would just like a path forward that allows us to annotate an existing POCO model so that it can be serialized across the wire.

As an aside, magic onion might be that solution but first party support for this scenario would be nice and that is the key ask of this issue.

[neuecc]

gRPC itself does not depend protocol buffers and there method definition. We can register handler manually, it completely works. I’ve already tried, and created a framework that built on gRPC. https://github.com/Cysharp/MagicOnion Maybe it is not a concern of gRPC Core. However, if grpc-dotnet is also open to extensibility, such a framework can continue to be developed.