Serialization/Deserialization of Metadata
See original GitHub issueHi,
I’m not sure this is an issue, but I’m struggling with deserialization metadata send using the method:
client.SendAndWait(metadata, totalMilliseconds, "my string");
Currently, I’m adding a class to the metadata dictionary. It’s a simple one, which should be serializable/de-serializable using Json.NET. The class in question has a few string properties, with a constructor sufficient for de-serialization again.
It looks similar to:
public class MyClass
{
public MyClass(string property)
{
MyProperty = property ?? throw new ArgumentNullException(nameof(subscriptionFile));
}
public string Property { get; }
}
My understanding was that I should be able to add this as a value to the metadata dictionary on the client side, and then on the server side, it should be deserialized into my type again. (Going over the wire in JSON.)
What I see is that the metadata dictionary on the server side contains a JObject type which represents the original class as JSON, not an instance of the original concrete class.
From the JObject, I can call
o.ToObject<MyClass>()
Which turns it into my concrete object again.
Is there a reason I have to manually call ToObject on my metadata to deserialize it?
It’s not a particular pain, I just don’t want to be abusing how this otherwise brilliant framework should be used. 😃
Alternatively, would you recommend against using classes in the metadata dictionary?
Ta,
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (5 by maintainers)
Top GitHub Comments
Also I’ll be sure to update the README on this one. Thanks for catching it.
Hi @code-pug I believe the reason this is happening and the reason you have to do a
JObject.ToObject<[type]>...
is because the metadata dictionary is defined as<object, object>
. I’m glad you pointed this out, because I wasn’t aware this would happen.I’ll leave this open in case anyone has a suggestion on how the library could be amended to allow the object to be deserialized automatically.