Question

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

It was originally intended to support AJAX web server apps, but the class can be used by any application (client, server, hybrid, anything) that serializes and deserializes .NET classes to JSON. I have a desktop app that captures screenshots and uploads to Facebook, and uses this class to deserialize the response.

would I ever want to look elsewhere for JSON deserialization from within .NET?

If so, why? and where would I Look?

---

If not, then why does JSON.Net exist? Is it strictly for historical purposes? (ie, because it was created by the community before the JavaScriptSerializer).

Answer 1

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!