Tooling design

A few questions regarding https://github.com/grpc/grpc/pull/13207. I didn’t read through all 192 comments but I did briefly read through the code after using it in a prototype.

1. .proto files in the project directory is not compiled by default

I found this to be a deliberate decision: https://github.com/grpc/grpc/blob/master/src/csharp/Grpc.Tools/build/_protobuf/Google.Protobuf.Tools.targets#L41-L46. What was the reason for this? I don’t think that comment applies here and would rather compile .proto files by default for a more frictionless experience. MSBuild properties are not very discoverable so it’s best that the user doesn’t have to look up the fact that you need to set EnableDefaultProtoBufItems to true to compile .proto files.

1. Design-time build

The goal here is to enable design-time build experience in VS. Currently, the *.cs files are generated when build is called, but ideally we should be generating these files when we detect *.proto files are being edited. We can enable this via Single File Generators and using the FastUpToDateCheck mechanism in VS. I see some code to this effect that I don’t see running https://github.com/grpc/grpc/blob/master/src/csharp/Grpc.Tools/build/_protobuf/Google.Protobuf.Tools.targets#L370-L383 as well as code that needs to be modified https://github.com/grpc/grpc/blob/master/src/csharp/Grpc.Tools/build/_protobuf/Google.Protobuf.Tools.targets#L250. The stretch goal here may be to write a VSCode extension to enable the same design time experience.

1. Protodep

Investigate if this file can be removed. Currently it seems like it’s used to communicate which files to generate (Foo.cs and FooGrpc.cs). It may be possible to substitute with MSBuild ItemGroups which is more natural and would reduce the files that are added to the /obj folder

cc @jtattermusch @shirhatti

[kkm000]

@chwarr, thank you for the info!

It could be possible to change the default for the gRPC package without breaking in the common case. To do this, the package could include a target to deduplicate the ProtoBuf items[…]

FWIW (if this is related to my point of breaking users after a GA), my concern was breaking of the build semantics. This statement only deals with potential problems caused by duplicate proto items in project, which is an implementation detail. What I mean by the potentially breaking scenario is, if the default changes after a GA, the tooling package suddenly starts globbing all .proto files when it previously did not. In other words, by “breaking” I refer chiefly to a possible unexpected discontinuity in user’s experience.

[jtattermusch]

I’d be totally happy with globbing by default (and thus following the recommendation), but as @kkm000 mentioned, the challenge is that many users are already including Grpc.Tools in their projects (the old version of it, which doesn’t provide any automatic behavior, it just provides the protoc binaries that users are responsible for running via e.g. a script), so if we suddenly start providing automatic codegen of .proto files, that can break people’s projects. But if disabling the automatic codegen is as easy as adding a single tag into the .csproj file (and we announce it in advance), it think it might be ok to go with globbing by default, because automatic codegen is a great improvement in developer experience and most users will be happy about this change.

Another option is to provide a new nuget package (other name than Grpc.Tools), which will provide the automatic codegen by default and we deprecate Grpc.Tools (but I’m not sure if this is necessary).