Conerlius / protobuf-net

Automatically exported from code.google.com/p/protobuf-net
Other
0 stars 0 forks source link

Enumeration types with duplicate values not DEserialized correctly #263

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Please include an e-mail address if this might need a dialogue!
==============

What steps will reproduce the problem?
1. Run attached test - it will fail on assertion
2. Compile enumeration member V1_1 to remove duplicates
3. Run test again - it will be OK

What is the expected output? What do you see instead?
> We really want enumerations to be correctly handled. There should be mapping 
between wire tag <-> underlying enumeration value.

What version of the product are you using? On what operating system?
> protobuf-net v2 r480

Please provide any additional information below.
> Nope

Original issue reported on code.google.com by vadim.sk...@gmail.com on 20 Jan 2012 at 4:32

Attachments:

GoogleCodeExporter commented 8 years ago
Will check later, but you should be able to use ProtoEnumAttribute and 
ProtoIgnoreAttribute to influence this. Ultimately, I suspect we could allow 
duplicates as long as they agree on both wire-value and enum-value.

Original comment by marc.gravell on 20 Jan 2012 at 5:02

GoogleCodeExporter commented 8 years ago
Please take a loook at EnumSerializer.cs attached.

Аfter looking at the code I can't get the reasons for switch inside the 
GetContiguousGroups results. After commenting out 'else' branch in the code my 
tests succeeded.

Original comment by vadim.sk...@gmail.com on 22 Jan 2012 at 5:50

Attachments:

GoogleCodeExporter commented 8 years ago
We are having the same issue when serializing the System.Windows.Input.Key 
enumeration.

Snapshot = 30,
PrintScreen = 30,
Insert = 31

ProtoBuf.Serializer.DeepClone(System.Windows.Input.Key.Insert) returns the 
value System.Windows.Input.Key.Snapshot

As the enum is part of the .NET framework, decorating it with the 
ProtoEnumAttribute is not an option for us.

Original comment by adrian.s...@gmail.com on 6 Jun 2012 at 11:43

GoogleCodeExporter commented 8 years ago
Hmmm... pretty sure that has been fixed for a long while - I will double check, 
however you can also use (at app-startup):

    RuntimeTypeModel.Default.Add(typeof(YourEnumType), false).EnumPassthru = true;

which will essentially tell it to treat it as a naked int/short/long/whatever.

Any use?

Original comment by marc.gravell on 6 Jun 2012 at 12:06