Protoc generates faulty C# namespace

[nickwinger]

Hello,

i'm not sure if this is a bug or how to fix this, haven't found anything on the internet.
We have a package like "my.name.space._3".
This works in protobuf and java generated code.
However in C# generated code the unserscore gets removed, and then the C# Compiler tells an error about that namespace "my.name.space.3".
Seems like only having a number in the namespace in C# is not working.

So how to handle this issue ? And we cannot change the protobuf files, since they are delivered by 3rd party.

C:\protoc --version
libprotoc 24.0

actually it should have been fixed: #10268

Thanks for help,
Nick

[jskeet]

Please could you post your specific .proto file? (It's not clear what you mean by "namespace" here - protobuf package, or csharp_namespace option. If you want a specific C# namespace, the simple fix would be to specify it explicitly.)

[nickwinger]

Hello,

i mean package in proto file, e.g.:

package my.scope._3

in C#:

namespace my.scope.3

the underscore gets removed which does not work in C#.
The bugfix i linked seem to only preserve the underscore before numbers at the beginning, but the routine has to check and preserve the underscore before numbers on every part of the package/namespace string separated by dots.

[jskeet]

Right. I'd expect that to actually be modified to My.Scope.3.

I would suggest you just use an explicit namespace option for the moment, which will allow you to avoid both the capitalization and the underscore removal:

option csharp_namespace = "my.scope._3";

I'd expect that to work fine.

[nickwinger]

Thank you for the suggestion, i will try it out as a workaround. However it’s not the best solution as we have to modify and scan the delivered 3rd party proto files

[jskeet]

Thank you for the suggestion, i will try it out as a workaround. However it’s not the best solution as we have to modify and scan the delivered 3rd party proto files

Hopefully I'll be able to fix this at some point, but given that Protobuf isn't my main work and there is a workaround (which isn't true for some issues in the C# space), it's likely that it'll be a while before I get to this. If you were to contribute a PR that fixes this, that would be likely to speed things up.

[nickwinger]

I will try to do a PR based on the fix that has already been made

[nickwinger]

here is the PR: #13504

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

[jskeet]

We still intend to address this, but it's unlikely to be in 2023 due to higher-priority issues.

[jskeet]

(#13504 is merged, so presumably this is at least better than it was - but I believe there are still improvements we want to make.)

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

[github-actions]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please reopen it.

This issue was closed and archived because there has been no new activity in the 14 days since the inactive label was added.