When deserializing JSON from within a C# program, should I ever need to use anything other than JavaScriptSerializer?

Question

.NET provides the JavaScriptSerializer class in the System.Web.Script.Serialization namespace. (provided in System.Web.Extensions.dll)

It was originally intended to sup

Answer 1

I use the JavaScriptSerializer on a wide variety of scenarios, it never let me down, and never needed to look elsewhere for other solutions... :)

...but i do know that JSON.net has some added values like LINQ to JSON, which i never needed, and nice JSON formatting but as Serializing goes JavaScriptSerializer does the work fine.

Answer 2

I wouldn't use the serializer supplied by .Net. Look at this post to see why:

http://www.reddit.com/r/linux/comments/epd5z/microsoft_standards_and_incompatibility_19912010/c19v88j

And the reason JSON.Net exists is JavaScriptSerializer didn't appear until .Net 3.5. JSON.Net existed before then.

Answer 3

In my case there are various reasons that prevent me to use JavaScriptSerializer. Here are some of them.

1) Ugly deserialization when dealing with anonymous types

While the usage is fairly straight forward for serialization:

JavaScriptSerializer serializer = new JavaScriptSerializer(); 
String json = serializer.Serialize(data); 

For deserialization however, there is a minor annoyance in that the deserializer accepts a generic type along with the content:

serializer.Deserialize<T>(String s) 

this can be a problem if the type T is not known at compile time and needs to be dynamic. The work around is a bit ugly as I learnt because it uses reflection to create a generic method (but it works)

var result = typeof(JavaScriptSerializer).GetMethod("Deserialize") 
             .MakeGenericMethod(JsonDataType) 
             .Invoke(serializer, new object[] { inputContent }); 

Please note: according to Dave Ward comment on this answer there's a DeserializeObject() that can be used to prevent this.

2) Cannot handle circular references

I have seen this using Entity Framework, Linq to SQL, NHibernate, NetTiers and even when using Castle's proxy.

According to MS Connect the circular reference exception will be raised when a navigable relation is double-sided (can access both sides of the relation), so the first thing to do is disable one side of the relation. The exception will also be thrown when you use 1:1 relations (or 1:0..1 or any relation causing the creation of an EntityReference type property), in this case the exception will be of type System.Data.Metadata.Edm.AssociationType.

The solution to this is to make the serializer ignore the properties of type EntityReference, using an empty implementation of a class deriving from JavaScriptConverter and registering it using the RegisterConverters method of the JavaScriptSerializer object.

3) Useful features that leads to less testable code

A useful feature of the JavaScriptSerializer is that you can also implement a custom JavaScriptConverter and pass that in to JavaScriptSerializer for fine-grained control over the serialization/deserialization. However, for it to be really useful you need to know the types at compile time and have references to those types. This really limits the usefulness of this feature because by referencing those classes your code becomes tightly coupled so you cannot easily use it in something like an MVC filter.

For these reasons I have often ended up using Json.NET.

Hope this helps!