The committers are authorized under a signed CLA.

• ✅ Antonio Mindov (6b4d9c7)

The problems with this:

• the Grpc.Tools package wouldn't support this new option anyway (and making it so would be a significant amount of work and would require extensive testing). Because Grpc.Tools is our primary and recommended way of generating for .proto files, I don't see much use for this new option.
• Generally we are against introducing new protoc / protoc plugin options as they make the codegen process more complicated and are pain to maintain.

So unless you have very compelling reasons why the "base_namespace" option is really necessary, we won't accept this patch, sorry.

Hey @jtattermusch, sorry for the late reply. Can you elaborate more on why this wouldn't be supported by the Grpc.Tools package?
The problem that this solves is pretty important in my opinion, which is easy API versioning. If you can't accept it for the reasons you pointed out(which seem reasonable) can you point me to a solution by which the following problem can be solved:

If you have multiple API versions in which there are duplicated files for example:
v1/Service.proto
v2/Service.proto

How would you generate them in the correct structure so that there are these files in the gen folder:
v1/Service.cs
v2/Service.cs

Hey @jtattermusch, sorry for the late reply. Can you elaborate more on why this wouldn't be supported by the Grpc.Tools package?
The problem that this solves is pretty important in my opinion, which is easy API versioning. If you can't accept it for the reasons you pointed out(which seem reasonable) can you point me to a solution by which the following problem can be solved:

If you have multiple API versions in which there are duplicated files for example:
v1/Service.proto
v2/Service.proto

How would you generate them in the correct structure so that there are these files in the gen folder:
v1/Service.cs
v2/Service.cs

The scenario that you're describing is something that was broken in Grpc.Tools before (see #17672), but we fixed that a while ago: #22869.

So when using a new enough version of Grpc.Tools, you basically don't need to anything for this scenario to work correctly.
The generated files will be automatically disambiguated under the "obj" directory (and of course in your code the generated classes will be diambiguated by having a different namespace).

I'm going to close this PR as #17672 is now fixed and we don't really need this anymore.