C++ gRPC Version for Generating C# .NET Compatible Proto Wrappers

[Luke S]

I am currently working as a developer for a C++ gRPC Server project, and one of my server clients is using C# to interact with our server. Their client code currently utilizes the older gRPC C# library but they have a need to move to the more modern modern gRPC C# .NET framework. They noted that when they attempted to switch over to this more modern framework, their client code no longer compiled due to compilation issues in the C# proto wrapper files we generated for them.

The issue clearly seems to stem from the version of protoc.exe/grpc_csharp_plugin.exe we are using. Currently, the C++ install of gRPC that we have comes with version 3.5.0 of protoc.exe. When our client did the NuGet C# .NET install of gRPC, they were provided with a protoc.exe version of 3.13.0, which we took from them (along with their installed grpc_csharp_plugin.exe file). We used these two files, and these alone, to replace our existing exes at C:\Program Files\grpc\bin and noticed that, without any other changes, all of our C# files generated from proto, had different outputs. When we sent these newly generated files to our client, their project was able to properly compile with them where it could not before.

Clearly a change was made between version 3.5.0 and 3.13.0 of protoc (and maybe also grpc_csharp_plugin) where file generations of C# files became compatible with your .NET framework. At what version did this occur? What is the earliest possible version of your C++ gRPC library that I can install to obtain the version of protoc/plugin to enable me to generate these more modern files for our clients?

Your help is greatly appreciated!

[Christopher Warrington - MSFT]

On Wednesday, February 3, 2021 at 8:14:54 AM UTC-8 Luke S wrote:

>  ... to obtain the version of protoc/plugin to enable me to generate these

>  more modern files for our clients?

Typically, one shares the .proto files with consumers--not the generated
code. This lets them generate code however fits best into their development
process.

If you were to share the .proto files with them, they could use their .NET
Core 3+/.NET 5+ toolchain, and you could use your C++ toolchain. Each of you
can upgrade toolchains independently of each other now.

This assumes the messages and service remain backward/forward compatible
with each other [1] [2], but you have that problem when sharing generated
code too...

[1]: https://developers.google.com/protocol-buffers/docs/proto3#updating
[2]: https://docs.microsoft.com/en-us/aspnet/core/grpc/versioning?view=aspnetcore-5.0

--
Christopher Warrington
Microsoft Corp.

[Luke S]

Right, this is definitely the known, recommended process and will likely be a goal of ours in the long run. Unfortunately, in the short to mid-term this won't work for us for the following reasons:

• The client is internal and does not have the time to add this to their process right now
• We need to update our version of gRPC C++ anyway, so if possible, we can just update to a version inclusive of the protoc binary that enables us to continue doing what we're doing while providing our client with something they can use

I completely agree with you in terms of how our process should work, but sometimes reality bites. Outside of even the need to accommodate this, many on our team are also just generally curious of when the change occurred in protoc because we would just like to understand how the library has developed. Looking through the change logs of gRPC on GitHub, the answer wasn't obvious which is why we wanted to ask here!

[Jan Tattermusch]

The protobuf C# library has always worked just fine with the grpc-dotnet implementation. We've made some changes in the generated code over time, but even the ancient versions of the generated code should just work with grpc-dotnet.

In gRPC C# (not the codegen) we've made some changes to enable the grpc-dotnet functionality. Your best best is to look a the version of Grpc.Core.Api and Google.Protobuf that's being included by the early versions of grpc-dotnet and you can be sure that those work just fine - 

e.g the first stable version of Grpc.AspNetCore.Server is using Grpc.Core.Api 2.23.0 (but yeah the prereleases before that also worked just fine).

Btw, when you don't specify what broke on your end, it's kind of impossible to tell what change could have caused it.

[Luke S]

Thanks for your reply Jan, my apologies I should have been more specific in what our issue was. Specifically, our current generations of service objects from our protos yields C# code that utilizes the Channel class, whereas their C# compiler with the new native .NET gRPC implementation is expecting services to be implemented with the ChannelBase class. When we update our protoc version to 3.13.0 we can see the generated implementations utilize ChannelBase where before they use Channel. As far as I understand it from our client, the Channel class no longer exists in the .NET gRPC implementation they are using. Below is an example of our generated code difference.

How our code currently generates one of our services:

public ServiceManagerClient(grpc::Channel channel) : base(channel)
{
}

When we use protoc 3.13.0:

public SystemConfigClient(grpc::ChannelBase channel) : base(channel)
{
}

Let me know if this is not clear or if you need more information.

[Luke S]

Let me know if any further information is required, we are still curious about the answer!