Announcement

Collapse
No announcement yet.

[CLOSED] [json#93] Deserialize fails on prop with type Dictionary if TKey is an Enum

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • [CLOSED] [json#93] Deserialize fails on prop with type Dictionary if TKey is an Enum

    My team is seeing an issue using DeserializeObject on an object that has a property with type Dictionary<TKey, TValue> when TKey is an Enum type.
    Invalid Enumeration Value at ctor (http://localhost:63375/Scripts/bridge/bridge.js:5226:31) at new ctor (http://localhost:63375/Scripts/bridge/bridge.js:5409:35) at Function.parse (http://localhost:63375/Scripts/bridge/bridge.js:4441:23) at Function.DeserializeObject (http://localhost:63375/Scripts/bridg...son.js:1196:61) at Function.DeserializeObject (http://localhost:63375/Scripts/bridg...son.js:1255:84) at Function.DeserializeObject (http://localhost:63375/Scripts/bridg...son.js:1402:78) at Function.DeserializeObject (http://localhost:63375/Scripts/bridg...son.js:1402:78) I opened an issue on the Bridge.Newtonsoft.Json github repo:

    https://github.com/bridgedotnet/Brid...Json/issues/93
    Last edited by fabricio.murta; 2018-04-17 @ 07:53 PM. Reason: bind issue tags to the thread. additional renaming in title to fit

  • geoffrey.mcgill
    replied
    Hi jguy

    The issue has been reviewed and is now in our queue to fix. With some luck, it will be fixed this week. We will keep Issue #99 updated with our progress.

    Leave a comment:


  • jguy
    replied
    Has there been any progress made on this issue? Is there any timeline on when it will be fixed?

    Leave a comment:


  • fabricio.murta
    replied
    Yes, anyway, it should be deserializing the string, your dotnet fiddle sample should be enough as comparison proof for interoperability, thanks!

    I will add this deck and dotnet fiddle to the issue for convenience:
    Deck: https://deck.net/a17ac5321a9baa1e4075d2a5c33ad2b2
    Dotnet fiddle: https://dotnetfiddle.net/ZQtysD

    Leave a comment:


  • jguy
    replied
    Here is a .NET fiddle that demonstrates how that JSON is being generated:
    https://dotnetfiddle.net/xTQlOF

    I can't reproduce the JSON in Deck.NET because the Bridge version of Newtonsoft.Json does not include TypeNameHandling.All, so that same code does not compile.

    Leave a comment:


  • fabricio.murta
    replied
    Hello jguy! Thanks for your follow up!

    In fact, we got issue #76 in Bridgedotnet/json that is related to the TypeNameHandling being ignored in serialization. But that shouldn't be a problem during deserialization, though.

    Anyway, if a native .NET application can't deserialize the string you provided, and Bridge goal is to reproduce what native .NET does, then there's not much point in supporting that.

    I don't mean your code is wrong! Just that it would help us fix the issue if we can see how it should work in native .NET. And with the string you provided in your deck, I couldn't make it work in native .NET either. Look at this, this is the dotnet fiddle I tried to port your deck into, and it is also breaking: https://dotnetfiddle.net/1yfv4Z

    Could that be that the web api controller is using a format that's not compatible with Newtonsoft.Json at all?

    Leave a comment:


  • jguy
    replied
    The serialized dictionary string came from a web API controller. The only difference I am seeing is when serializing the the data from the server, we are using TypeNameHandling.All. Is that not supported in bridge?

    Leave a comment:


  • fabricio.murta
    replied
    About the key enum mapping I mentioned above, albeit being related to your issue, it does not seem to be what's causing it. We can serialize and deserialize to and from dictionaries all the time with that, in both native and bridge environments.

    Anyway, I've logged that specific issue (that's related to the serialization, not the deserialization) under #99 over the Newtonsoft.Json repository.

    Can you, maybe, come up with a corresponding dotnetfiddle sample that works based on the deck you provided? As mentioned previously, I tried to run your deck on native .NET but it also breaks on an exception, even though I paid attention on trying to map back the metadata and even stripping it out. It seems something else is required in order to deserialize -- maybe remove the \r\n from the string?

    Leave a comment:


  • fabricio.murta
    replied
    Hello @jguy!

    How did you end up with that serialized dictionary string? From the deck sample you provided in the github issue, I tried to reproduce the test case in dotnetfiddle.com for reference, but the serialized string (if I make the actual class and serialized it) can be deserialized normally. If I use the string you provided in your test case it won't work on native .NET either. The sample running in dotnet fiddle (deserializing the string it serialized), also worked on deck.

    Take a look at the working deck: https://deck.net/f54fd945ddf01472bb81bd8614c57d9c
    Here's the corresponding dotnetfiddle code: https://dotnetfiddle.net/8EYiAW

    For reference this is the serialized result of the Person object:
    From Deck:
    {"Addresses":{"0":{"City":"Demo City","PostalCode":"Demo ZIP","State":"Demo State","Street":"Demo Street"}}}
    From dotnet fiddle:
    {"Addresses":{"Home":{"Street":"Demo Street","City":"Demo City","State":"Demo State","PostalCode":"Demo ZIP"}}}
    At the least, the string you used as a sample did not serialize back in native .NET either, so maybe something missing from the deck you provided?

    EDIT: I can see it is not quite right, by default, not mapping the enum to its string representation, but I just tried to add the string from native .NET and it deserialized successfully, so interop is granted. The other way around also works (took deck string to native dotnet and it serialized it back to the string it originally did.

    Well, but that's an issue with Bridge, as if the enum numbers change, then the mapped value will no longer be actual.
    Last edited by fabricio.murta; 2018-04-17 @ 07:07 PM.

    Leave a comment:

Working...
X