2

Closed

NewtonSoft.Json.Linq Namespace Entities not marked as [Serializable]?

description

I've got a caching mechanism that's using the DataContractSerializer as a best-effort serializer for anything the cache receives. The problem is the JObject (and it's children) aren't marked as [Serializable] and cannot be serialized by this method.
 
I know the library is a serialization framework in itself, but It's a bit upsetting that it doesn't play nice with other serializers.
 
Here's the stack trace into the serializer when a JObject is attempted to be serialized:
 
System.Runtime.Serialization.InvalidDataContractException: Type 'Newtonsoft.Json.Linq.JObject' cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute. If the type is a collection, consider marking it with the CollectionDataContractAttribute. See the Microsoft .NET Framework documentation for other supported types.
at System.Runtime.Serialization.DataContract.DataContractCriticalHelper.ThrowInvalidDataContractException(String message, Type type)
at System.Runtime.Serialization.CollectionDataContract.GetValidContract(SerializationMode mode)
at System.Runtime.Serialization.NetDataContractSerializer.GetDataContract(RuntimeTypeHandle typeHandle, Type type, Hashtable& surrogateDataContracts)
at System.Runtime.Serialization.NetDataContractSerializer.InternalWriteObject(XmlWriterDelegator writer, Object graph)
at System.Runtime.Serialization.XmlObjectSerializer.WriteObjectHandleExceptions(XmlWriterDelegator writer, Object graph, DataContractResolver dataContractResolver)
at System.Runtime.Serialization.XmlObjectSerializer.WriteObject(XmlDictionaryWriter writer, Object graph)
at System.Runtime.Serialization.XmlObjectSerializer.WriteObject(Stream stream, Object graph)
 
Marking the object with [Serializable] and potentially ISerializable (to hook the proper serialization methods in the library) should allow it to be serialized properly.
Closed May 4 at 8:05 AM by JamesNK
Sorry, I still don't want to do this. I'm trying to limit what is added to json.net so the dll doesn't grow too big.

comments

ReAn1985 wrote Oct 3, 2011 at 9:47 PM

Thanks for the quick response JamesNK, I thought of a different approach that might be useful for the library. If you implement ISerializable & a Serialization Constructor to invoke .Parse() / .ToString() You'd be able to drop JObject values into NetDataContractSerializer with no effort. This is useful for allowing objects with references to JObjects to be sent over WCF or just serialized in general as it wouldn't be compiling them into xml or binary representations but as a string (which is JSON of course). This way the serialization/de-serialization happens automatically and doesn't affect the library.

It's literally very little work and would facilitate (what is in my mind) a great feature gap in your excellent library.

JamesNK wrote Oct 3, 2011 at 10:56 PM

There is a lot of work involved in making those objects either XML or binary serializable by other serializes, and it isn't something I really want to do. I recommend converting those objects to strings on whatever transfer objects you are passing around to avoid serialization issues.



** Closed by JamesNK 9/30/2011 10:28 PM

JamesNK wrote Oct 3, 2011 at 10:56 PM

I didn't think of using Serializable attribute + ISerializable. I'll investigate it in the future and see how much work it is.

Dickster wrote Feb 10, 2012 at 3:42 PM

Would be a great feature to add. I just went to do a Deep Clone on my object marked [Serializable] but the underlying Newtonsoft.Json.Linq.JObject gave the same problem as described.

Dickster wrote Feb 10, 2012 at 3:43 PM

Would be a great feature to add. I just went to do a Deep Clone on my object marked [Serializable] but the underlying Newtonsoft.Json.Linq.JObject gave the same problem as described.

Dickster wrote Feb 10, 2012 at 3:45 PM

Would be a great feature to add. I just went to do a Deep Clone on my object marked [Serializable] but the underlying Newtonsoft.Json.Linq.JObject gave the same problem as described.

Sign in to add a comment