Json.NET 5.0 Release 5 – DefaultSettings and Extension Data


If you have used Json.NET then you will be familiar with JsonSerializerSettings. This class has been an extremely successful at providing an simple way for developers to customize Json.NET.

With Json.NET’s increasing popularity and its use by more third party frameworks, a problem I have noticed is a developer has to customize serializer settings in multiple places. If you want your HtmlHelper.ToJson extension method, Web API services and SignalR to serialize JSON the same way across an application then you have to manually share a JsonSerializerSettings instance between them and figure out how each different framework allows you to customize Json.NET.

The solution I have come up with is to add global default settings. Set once with JsonConvert.DefaultSettings in an application, the default settings will automatically be used by all calls to JsonConvert.SerializeObject/DeserializeObject, and JToken.ToObject/FromObject. Any user supplied settings to these calls will override the default settings.

// settings will automatically be used by JsonConvert.SerializeObject/DeserializeObject
JsonConvert.DefaultSettings = () => new JsonSerializerSettings
    Formatting = Formatting.Indented,
    ContractResolver = new CamelCasePropertyNamesContractResolver()
Employee e = new Employee
    FirstName = "Eric",
    LastName = "Example",
    BirthDate = new DateTime(1980, 4, 20, 0, 0, 0, DateTimeKind.Utc),
    Department = "IT",
    JobTitle = "Web Dude"
string json = JsonConvert.SerializeObject(e);
// {
//   "firstName": "Eric",
//   "lastName": "Example",
//   "birthDate": "1980-04-20T00:00:00Z",
//   "department": "IT",
//   "jobTitle": "Web Dude"
// }

Because there are cases where JSON should not be customized, e.g. a Facebook or Twitter library, by default JsonSerializer won’t use DefaultSettings, providing an opt-out for those frameworks or for places in your application that shouldn’t use default settings. To create a JsonSerializer that does use them there is a new JsonSerializer.CreateDefault() method.

In the short term there will be some third party libraries that don’t use default settings that should, and some third party libraries that do use default settings that shouldn’t. If you encounter a situation where DefaultSettings doesn’t work for you then continue to customize Json.NET settings like you do today.

In the long term DefaultSettings will hopefully provide a simple, standard way to developers to customize JSON in .NET applications.

Extension Data

The second new feature in Json.NET 5.0 Release 5 is copied inspired by WCF’s IExtensibleDataObject.

Extension data is a JSON object’s values that aren’t matched to a .NET property during deserialization. By placing the JsonExtensionDataAttribute on a dictionary all unused values are automatically added to that dictionary and are accessible by you.

public class DirectoryAccount
  // normal deserialization
  public string DisplayName { get; set; }
  // these properties are set in OnDeserialized
  public string UserName { get; set; }
  public string Domain { get; set; }
  private IDictionary<string, JToken> _additionalData;
  private void OnDeserialized(StreamingContext context)
    // SAMAccountName is not deserialized to any property
    // and so it is added to the extension data dictionary
    string samAccountName = (string)_additionalData["SAMAccountName"];
    Domain = samAccountName.Split('\\')[0];
    UserName = samAccountName.Split('\\')[1];


Here is a complete list of what has changed since Json.NET 5.0 Release 4.

  • New feature – Added global default serialization settings with JsonConvert.DefaultSettings
  • New feature – Added extension data support with JsonExtensionDataAttribute
  • New feature – Added NullValueHandling and DefaultValueHandling support to serializing dynamic types
  • Change – Changed some explicit interface methods on JArray to public to support use with ImpromtuInterface
  • Fix – Fixed deserializing non-ISO formatted date dictionary keys
  • Fix – Fixed values not being set when deserializing with DefaultValueHandling.IgnoreAndPopulate
  • Fix – Fixed deserializing with type named handling and assemblies loaded with Assembly.LoadFrom
  • Fix - Fixed deserializing Regexes when using StringEnumConverter
  • Fix – Fixed serializing and deserializing typed DataSets


Json.NET CodePlex Project

Json.NET 5.0 Release 5 Download – Json.NET source code and assemblies

Json.NET 5.0 Release 4 – Performance

This release of Json.NET ships with many performance improvements, and is over 30% faster serializing and deserializing JSON compared to Json.NET 4.5.

Smithers, release the hounds.

Json.NET extends its performance lead over DataContractJsonSerializer and continues to be significantly faster than JavaScriptSerializer which is used by ASP.NET MVC.

Compiled Expressions on Windows 8 and Windows Phone 8

An additional performance improvement specific to Windows 8 and Windows Phone 8 is the switch from the serializer internally using latebound reflection to compiled expressions. In exchange for a small one off cost the first time a type is serialized, compiled expressions are considerably faster than latebound reflection and provide an additional speed boost to Json.NET on Win8 and WP8.


Here is a complete list of what has changed since Json.NET 5.0 Release 1.

  • New feature - Added JsonWriter.SetWriteState to support inheritance from JsonWriter implementations
  • Change - Changed .NET 4.5 portable library and WinRT library to use compiled expressions reflection
  • Fix - Fixed error serializing non-generic types that implement IEnumerable<T>


Json.NET CodePlex Project

Json.NET 5.0 Release 4 Download – Json.NET source code and assemblies

Json.NET 5.0 Release 1 – .NET 4.5, BigInteger, Read-Only Collections

New and Updated Libraries

In Json.NET 5.0 there are a bunch of library version changes:

  • Added .NET 4.5 library
  • Added portable library targeting .NET 4.5 + WP8 + Win8
  • Removed the Silverlight library.
  • Removed the Windows Phone library

Upgrading library versions allows Json.NET to support new .NET features such as dynamic and async across more platforms.

A baseline portable class library still supports all platforms (.NET 4 + WP7 + SL5 + Win8) so have no fear  Silverlight and Windows Phone developers, even though the dedicated libraries have been removed you can continue use the latest version of Json.NET on Silverlight/Windows Phone with a portable class library.

Note that the assembly version number of Json.NET 5.0 hasn't changed and is still to avoid assembly redirect issues. Read more about assembly version numbers here.

Serializing NaN and Infinity Floating Point Values

Json.NET no longer serializes NaN and positive and negative infinity floating point values as symbols, which is invalid JSON. With 5.0 the new default is to serialize those values as strings, e.g. "NaN" instead of NaN. There is no change to serializing normal floating point numbers.

A FloatFormatHandling setting has been added so you can control how NaN and infinity values are serialized.

string json;
IList<double> d = new List<double> {1.1, double.NaN, double.PositiveInfinity};
json = JsonConvert.SerializeObject(d);
// [1.1,"NaN","Infinity"]
json = JsonConvert.SerializeObject(d, new JsonSerializerSettings {FloatFormatHandling = FloatFormatHandling.Symbol});
// [1.1,NaN,Infinity]
json = JsonConvert.SerializeObject(d, new JsonSerializerSettings {FloatFormatHandling = FloatFormatHandling.DefaultValue});
// [1.1,0.0,0.0]

BigInteger and Read-Only Collections

Json.NET 5.0 adds support for BigInteger. Now when reading and writing JSON there is no limit on the maximum size of integers Json.NET can handle.

There is also support for read-only collection interfaces (IReadOnlyList<T> and IReadOnlyDictionary<TKey, TValue>) which were added in .NET 4.5. As long as there is an IEnumerable<T> constructor then Json.NET will deserialize to the read-only collection for you.

string json = @"[
var l = JsonConvert.DeserializeObject<IReadOnlyList<BigInteger>>(json);
BigInteger nineQuindecillionAndOne = l[0];
// 9000000000000000000000000000000000000000000000001


There are many performance and memory improvements in Json.NET 5.0, especially when serializing and deserializing collections, and Json.NET in Windows 8 Store apps.


Here is a complete list of what has changed since Json.NET 4.5 Release 11.

  • New feature - Added .NET 4.5 library
  • New feature - Added portable library targeting .NET 4.5, Win8, WP8
  • New feature - Added Path to JToken
  • New feature - Added BigInteger support
  • New feature - Added IReadOnlyCollection<T> and IReadOnlyDictionary<TKey, TValue> support
  • New feature - Added FloatFormatHandling to JsonWriter/JsonSerializer/JsonSerializerSettings
  • New feature - Added DateFormatString to JsonWriter/JsonSerializer/JsonSerializerSettings
  • New feature - Added support for multiple serialization events and use base type serialization events
  • New feature - Added DeserializeAnonymousType overload with JsonSerializerSettings
  • New feature - Added support for specifying root type when serializing JSON with TypeNameHandling.Auto
  • New feature - Added support for creating lists and dictionaries with an IEnumerable<T> constructor
  • New feature - Added IConvertible support to JValue
  • New feature - Added support for serializing custom IConvertible values
  • New feature - Added support for deserializing IList
  • New feature - Added support for converting byte array JValues to Guid
  • New feature - Added support for deserializing byte arrays to Guid
  • Change - NaN and Infinity floating point values are serialized as strings by default
  • Change - Minor breaking changes to JsonSchema type
  • Change - Upgraded Windows Phone assembly to WP8
  • Change - DateTime IDictionary keys are now serialized in ISO date format
  • Change - DataContractAttribute is no longer inherited to match DataConctractSerializer behavior
  • Change - StringEnumConverter converts empty strings to null for nullable enums
  • Change - Guids serialize to a binary UUID in BSON instead of a string
  • Remove - Removed SL4 library
  • Remove - Removed WP7 library
  • Fix - Fixed JTokenWriter returning a null reference
  • Fix - Fixed static fields to no longer be included with fields serialization
  • Fix - Fixed recursively reading type wrapper objects when deserializing
  • Fix - Fixed incorrect namespace when converting XML to JSON
  • Fix - Fixed poor performance when serializing/deserialize dynamic objects
  • Fix - Fixed StringEnumConverter to throw JsonSerializerException on error
  • Fix - Fixed hidden properties not being serialized


Json.NET CodePlex Project

Json.NET 5.0 Release 1 Download – Json.NET source code and assemblies

Monitoring Windows Azure with Foglight

I do a lot of Azure development. While it is a great platform for setting up new environments, scaling instances and simple deployments; monitoring applications in Azure is difficult. It is a remote environment and because of the way Azure abstracts hosting for you there is no option to install your own software on the server.

Foglight for Azure Apps is a hosted service that sets up gathering information from Windows Azure for you. In this blog post I'm going to try out Foglight with a demo application I've put together for simulating a broken website (demo source code available at the end of the blog post).


Getting Started

Setting up Foglight for Azure Apps is really simple. Foglight has two configuration methods for adding an Azure deployment: manual configuration where you manually add details about each deployment you want to monitor, and automatic discovery where Foglight retrieves that information from Azure for you. I'm going to step through using the automatic discovery wizard.


With Foglight automatic discovery the only information you need is your role’s Azure Subscription ID. Subscription IDs can be found in the Windows Azure Management Portal by browsing to Settings -> Management Certificates.


The next step after copy/pasting your Subscription ID is to add a management certificate from Foglight to Azure. The download link for the certificate is in the wizard and it is uploaded in the same place where you got your Subscription ID.


Finally select the deployment you want to monitor and you’re finished.




The core of Foglight for Azure Apps are the monitors it provides to measure the health of your application. The first page you’ll come upon after setup is the dashboard which provides a nice summary of the state of your application. From this screen or from the menu you can drill into more detail about each monitor.


The availability page shows you whether your application is accessible from various locations around the world – useful for times when a user or users from a country report they can’t access your application. In the screenshot above I've activated server errors on my demo website which you can see showing up in orange in the availability graphs.


The health page lets you view health details about individual rolls in your application. Here you can see details like CPU, memory and disk usage, and HTTP traffic and bandwidth being used by each role. One nice feature here is Foglight aggregates everything together and provides an indication of whether the application is healthy or not. Seeing the health of an application in a graph over time lets you match user reported errors with past server problems. In the screenshot above I've active high CPU and memory usage in my demo application.


The services page shows the status of the Windows Azure services your application depends on (e.g. compute, databases, storage) in your application's region and the status of worldwide services (e.g. management portal, CDN). This is a useful tool when debugging a broken application to double check whether the issue is yours or is being caused by a problem in Azure infrastructure.


The top URLs page shows what URLs in an application are creating problems. URLs can either be the slowest pages in your application or the pages with the highest number of 404 and server errors.

Configuring Health and Alerts

An awesome feature of Foglight is the control you have over configuring health thresholds and sending alerts.


Once you're happy with the health thresholds (the screenshot above shows the default) you can then configure at what health level alerts should be emailed and who they should be emailed to.

Health alerts are one of the most important features when monitoring, letting you know about problems as soon as they happen rather than waiting until someone look at Foglight or hear about errors from your users.

One thing I’ve done in the past with errors is to send an SMS message to my phone. Foglight doesn’t have built in SMS support but it is simple to set up using IFTTT.


Wrapping Up

I found Foglight's monitoring easy to understand and fast to update. Really impressive is how simple Foglight is to setup, taking just a couple of minutes and requiring no changes to your application. Finally the Foglight’s health alerts will ensure you know about critical issues as they happen.

If you're deploying applications to Azure and it is important they are rock solid then I recommend you check Foglight for Azure Apps out.


Click here to download the Windows Azure JsonFormat application source code


Disclosure of Material Connection: I received one or more of the products or services mentioned above for free in the hope that I would mention it on my blog. Regardless, I only recommend products or services I use personally and believe my readers will enjoy. I am disclosing this in accordance with the Federal Trade Commission’s 16 CFR, Part 255: Guides Concerning the Use of Endorsements and Testimonials in Advertising.