C# protoc.exe: Support --csharp_namespace command line option

[omghb]

What language does this apply to?
Code generator for C# (protoc.exe)

Describe the problem you are trying to solve.
Today we can define a custom C# namespace for the generated code within the proto file.

option csharp_namespace = "My.Namespace";

I get proto files from another team (C++ technology stack) so this option is not set. I would prefer to take the original proto files without adapting them.

Describe the solution you'd like
I would like to pass the option as command line parameter to protoc.exe:

protoc.exe --csharp_namespace="My.Namespace"

If both variants set the csharp_namespace then I would prefer that the command line option wins.

[w5423709]

i want this command line option too,so i dont need to modify the original proto files and add "option csharp_namespace = "My.Namespace"" to every single file ,it is horrible.

[jtattermusch]

I don't think this option is useful. The C++ stack should jut add the option csharp_namespace = "My.Namespace"; to their .proto files, or (or that's for some reason not possible) you should just patch the .proto files as you import them into your C# project.
Also, the introducing a new option is not a good solution because it cannot accommodate the case when multiple .proto files as being processed by a single protoc invocation` (which is quite common). It can also create incompatibilities (different projects could override the cmdline option with different values).

[omghb]

@jtattermusch I would see this as a feature and not an incompatibility:

It can also create incompatibilities (different projects could override the cmdline option with different values).

Our .proto files provided by the C++ "server" team is used by multiple "client" teams (C#). The client teams are independent of each other. Every client team generates their own C# classes out of the .proto files with different settings (e.g. Namespace) and different Google.Protobuf library version.

---

I still believe that it can be a useful option. I agree that it does not work when a single protoc call processes multiple .proto files.

Alternative solution would be to specify a base namespace:
--csharp_basenamespace="My.Namespace"

This might be confusing as there is already the CLI option --csharp_opt=base_namespace=Example. This creates a directory hierarchy for the generated source code. But it does not change the "base" namespace as some might expect.

[rurounijones]

I just came across this issue. I thought the --csharp_opt=base_namespace=Example did what this request is asking for and wasted a lot of time trying to figure out why it was not working.

I also don't see

not a good solution because it cannot accommodate the case when multiple .proto files as being processed by a single protoc invocation`

as a good reason not to do this. Teams that need this option will be making protoc multiple invocations if they need to for the different "batches" of .proto files that may need separate handlinh.

This feature is even more useful in open source development where the client libraries may be written by groups who wish to namespace different based on their project names.

[Blackclaws]

Missing this option leads to the problem that if you're developing and add tests for a library that generates a grpc client using Internal access level you're generating a ton of warnings when you generate the gRPC message types also for the mocked server.

[kamil-mrzyglod]

Missing this option leads to the problem that if you're developing and add tests for a library that generates a grpc client using Internal access level you're generating a ton of warnings when you generate the gRPC message types also for the mocked server.

This. Lack of that option leads to numerous issues when developing projects, which are testing the main service, and you share .proto files across various projects. As you need to create both client and server types while referencing the main service, you get tons of warnings related to namespace collision and imports must fallback to one of the types.