Heya,
The C# generator creates service names as-is, but all methods on the server-side return awaitables. It's convention to append "Async" to methods that return awaitables.
The implementation classes can be referenced and used in as normal code - that is, you can save a reference to GreeterImpl or construct a new instance of it and call its method in your other code: Task<string> GreeterImpl.GetGreeting(...) instead of Task<string> GreeterImpl.GetGreeting[Async](...). It feels weird that half of methods in your code don't follow the general convention (aka all gRPC-generated classes), and the remaining half do (BCL, libraries, existing code, and non-gRPC classes).
Please consider changing this behaviour so that the generator would generate Task<string> GetGreetingAsync() instead of Task<string> GetGreeting() given a service with rpc GetFeature() returns (string) { }.
It's a small change and I understand that gRPC has recently hit 1.0, so if we think it's a good idea I'm happy to do the work to make it happen.
Heya,
The C# generator creates service names as-is, but all methods on the server-side return awaitables. It's convention to append "Async" to methods that return awaitables.
The implementation classes can be referenced and used in as normal code - that is, you can save a reference to
GreeterImplor construct a new instance of it and call its method in your other code:Task<string> GreeterImpl.GetGreeting(...)instead ofTask<string> GreeterImpl.GetGreeting[Async](...). It feels weird that half of methods in your code don't follow the general convention (aka all gRPC-generated classes), and the remaining half do (BCL, libraries, existing code, and non-gRPC classes).Please consider changing this behaviour so that the generator would generate
Task<string> GetGreetingAsync()instead ofTask<string> GetGreeting()given a service withrpc GetFeature() returns (string) { }.It's a small change and I understand that gRPC has recently hit 1.0, so if we think it's a good idea I'm happy to do the work to make it happen.