Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C# Custom Options: TypeInitializationException: InnerException: An item with the same key has already been added #7174

Closed
doom-goober opened this issue Feb 4, 2020 · 9 comments

Comments

@doom-goober
Copy link

doom-goober commented Feb 4, 2020

What version of protobuf and what language are you using?
Version: master/v3.11.2.0
Language: C#

What operating system (Linux, Windows, ...) and version?
Windows

What runtime / compiler are you using (e.g., python version or gcc version)
GoogleProtobuf.Tools.3.11.2

What did you do?
Steps to reproduce the behavior:
Create a FieldOption in ObjectReference.proto:

syntax = "proto3";
import "google/protobuf/descriptor.proto";
extend google.protobuf.FieldOptions {
	string objectReferenceType = 1000;
}

Then use that field option in two places. First, Blah.proto:

syntax = "proto3";
import "ObjectReference.proto";

message Blah
{
  string test = 1 [(objectReferenceType) = "UnityEngine.GameObject"];
}

And Blah2.proto:

syntax = "proto3";
import "ObjectReference.proto";

message Blah2
{
  string test = 1 [(objectReferenceType) = "UnityEngine.GameObject"];
}

Create a message that uses both of those call it Configuration.proto:

syntax = "proto3";
import "Blah.proto";
import "Blah2.proto";

message Configuration
{
  Blah blah = 1;
  Blah2 blah2 = 2;
}

Compile to C# and just print Configuration.Descriptor.FullName. Doing so will trigger the "An item with the same key has already been added" exception.

What did you expect to see
No error. Should be able to use the same Field Option in 2 places.

What did you see instead?
TypeInitializationException.

Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs).

   at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
   at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
   at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
   at Google.Protobuf.ExtensionRegistry.Add(Extension extension)
   at Google.Protobuf.ExtensionRegistry.AddRange(IEnumerable`1 extensions)
   at Google.Protobuf.Reflection.FileDescriptor.AddAllExtensions(FileDescriptor[] dependencies, GeneratedClrTypeInfo generatedInfo, ExtensionRegistry registry)
   at Google.Protobuf.Reflection.FileDescriptor.FromGeneratedCode(Byte[] descriptorData, FileDescriptor[] dependencies, GeneratedClrTypeInfo generatedCodeInfo)
   at ConfigurationReflection..cctor() in C:\Users\alex\Documents\TestCSharp\TestCSharp\Configuration.cs:line 28

Anything else we should know about your project / environment
If you remove one of the ObjectReferenceType field options from one of the fields as well as it's import, the exception goes away. It only happens if two separate fields have field options and two separate files import the FieldOption extension.

@doom-goober
Copy link
Author

doom-goober commented Feb 4, 2020

Accidentally closed issue thinking it was not reproing. It repros for me 100%.

@doom-goober doom-goober reopened this Feb 4, 2020
@ObsidianMinor
Copy link
Contributor

Something is definitely wrong here... This issue should be fixed by 34f9497 and a release has been made since that commit was added however decompiling the 3.11.3 release on nuget shows that it hasn't actually been updated.
image

Any idea why this might be @jtattermusch @rafi-kamal?

@rafi-kamal
Copy link
Contributor

Looks like the commit wasn't backported to the release branch (3.11.x).

@jskeet
Copy link
Contributor

jskeet commented Feb 5, 2020

Given that this makes any use of reflection infeasible for some protos, I think this really merits a 3.11.4 release.
(As it happens, I ran into this issue just today. I've got a few more issue to file and fix when I get a chance. Although I suspect at least some of them are fixed by #7130.)

@rafi-kamal
Copy link
Contributor

#7188 to backport the fixes to the release branch.

@zhxymh
Copy link

zhxymh commented Feb 11, 2020

We have the same problem. Will the new version be released soon? @rafi-kamal

@rafi-kamal
Copy link
Contributor

We are planning to do the 3.11.4 release by the end of this week.

@zhxymh
Copy link

zhxymh commented Feb 12, 2020

We are planning to do the 3.11.4 release by the end of this week.

Thx!

@jtattermusch
Copy link
Contributor

Should be fixed by #7188.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants