C# Proto2 -> GRPC or REST

[wyss....@gmail.com]

Hy all

We have two clients (c++ and c#). We're generating a c++ and a c# object out of our proto2 proto-definition:

syntax = "proto2";
option csharp_namespace = "xxx.yyy";

message Data {
  required int32 id = 1;
  optional Data2 data2 = 2;
}

message Data2 {
    optional int32 id = 1;}
}

...

We need to use proto2 (this is a requirement of the framework we use in our c++ application). For generating the c# class, we use the following protoc-version:
- protoc-3.0.0-alpha-3-win32>

...because this is the latest version, which works with proto2 definitions.

*****************

We would also like to expose functionality from our c# application to other external clients, so we're discussing this two scenarios:
- Variant A: Using GPRC
- Variant B: Using a REST Service

Variant A:

We added the service definition to our proto-file:

syntax = "proto2";
option csharp_namespace = "xxx.yyy";

service TestService {
  rpc SendData (Data) returns (Data) {}
}

message Data {
  required int32 id = 1;
  optional Data2 data2 = 2;
}

message Data2 {
    optional int32 id = 1;}
}

Then we've tried to create the server/client stub according to:
https://grpc.io/docs/quickstart/csharp.html

...but this does not work with our proto2 defined proto file:
C# code generation only supports proto3 syntax

-> So this will not work with our proto2-definition right?

Variant B:
How can we expose our auto-generated ProtoBuf object to REST without writing a new Object and doing a mapping all the time?

Thanks for your help!

Kind regards,
Peter

[Jan Tattermusch]

It's tough to help here - as you said, C# only supports proto3 and given you have conflicting requirement to only use proto2, there doesn't seem to be an ideal solution here.

proto2 and proto3 are wire compatible for many message definitions (refer to proto3 documentation), so you might have 2 copies of .proto files - one with proto2 and one with proto3 and if you are careful when designing the your proto schema, the client and server will still be able to communicate (in fact we used this approach in early versions of our interop testing framework where before proto3 was supported by some languages). Needless to say, it's not an ideal solution, but it might be good enough for you.