I’ve been hard at work on Json.NET over the holidays. I spent most of December setting up environments, writing PowerShell scripts and deploying applications so it was nice to do a little .NET development for a change.

JSON Schema

The big new feature in Beta 2 is JSON schema validation. JSON Schema is a specification for defining the structure of JSON. Think of it as XML Schema for JSON except it is actually readable.

{

  "description": "A person",

  "type": "object",

  "properties":

  {

    "name": {"type":"string"},

    "hobbies": {

      "type": "array",

      "items": {"type":"string"}

    }

  }

}

I have put together a demo page of the new JSON Schema features: JSON Schema Validation Demo

There are a couple of different ways of validating using JSON Schema in Json.NET. The simplest is using an extension method for the LINQ to JSON objects. IsValid in this example just returns a flag but there are other overloads that let you also capture validation messages.

JsonSchema schema = JsonSchema.Parse(schemaJson);

JObject person = JObject.Parse(@"{

  ""name"": ""James"",

  ""hobbies"": ["".NET"", ""Blogging"", ""Reading"", ""Xbox"", ""LOLCATS""]

}");

bool valid = person.IsValid(schema);

// true

As well as validation, for fun, and to help with testing, I wrote a class called JsonSchemaGenerator. This class looks at a .NET type and using reflection it generates a schema for it. The schemas on the demo page are all generated at runtime.

JSON line and position Information

JsonTextReader now reports line and position information. Line and position information was needed for the schema validator to help point out to a user in an error message which part the JSON was invalid. The nice flow on effect of this feature is now when you give Json.NET bad JSON, the resulting exception will tell you the location of the invalid character.

JObject person = JObject.Parse(@"{

  ""name"": ""James"",

  ]!#$THIS IS: BAD JSON![{}}}}]

}");

// Invalid property identifier character: ]. Line 3, position 3.

Changes

Here is a complete list of what has changed since Json.NET 3.5 Beta 1.

• New feature - Added JSON Schema implementation
• New feature - Added IJsonLineInfo. Implemented by JsonTextReader, JsonTokenReader, JsonValidatingReader, JToken
• New feature - Added line details to JsonTextReader exception messages and JsonValidatingReader errors
• New feature - Added JsonContainerAttribute with Id, Title and Description members. JsonObject and JsonArray inherit from this attribute
• New feature - Added JsonArrayAttribute. Has flag to control whether array can contain null items
• New feature - Added IsRequired to JsonProperty
• New feature - Added Load(JsonReader) to JProperty, JConstructor
• New feature - Added the ability for JsonTokenWriter to write individual values as well as arrays and objects
• New feature - Added CreateReader to JToken
• New feature - Added FromObject to JToken
• New feature - Added ReadFrom to JToken
• Change - Renamed JavaScriptConvert to JsonConvert
• Change - Value<T> on JObject supports getting nullable values
• Change - Type values now serialize and deserialize to the type name string
• Change - GetSerializableMembers has been removed and replaced with GetMemberMappings on JsonSerializer
• Fix - JsonConvert now always write a floating point number with a decimal place
• Fix - JsonSerializer now correctly skips missing members
• Fix - JsonWriter now allows objects and arrays to be written in a constructor
• Fix - QuoteChar not getting set when parsing property name
• Fix - JProperty now correctly loads content from a collection

Links

Json.NET CodePlex Project

Json.NET 3.5 Beta 2 Download – Json.NET source code, documentation and binaries

I am considering renaming the JavaScriptConvert class to JsonConvert.

When Json.NET was first released it contained a number of data classes that were prefixed with JavaScript... JavaScriptObject, JavaScriptArray, JavaScriptConstructor. JavaScriptConvert was used to convert the data objects from text and back again. In 2.0 these classes were removed and replaced by the LINQ to JSON API: JObject, JArray, etc, but JavaScriptConvert remained.

The current state of the nation is that just about every Json.NET class is prefixed with Json (JsonReader, JsonWriter, JsonSerializer) except JavaScriptConvert, a situation which I think is somewhat confusing and gets in the way of learning and discovering the Json.NET API through intellisense.

The downside of renaming JavaScriptConvert is that existing code that uses it will need to be updated when moving to a new version of Json.NET. A pain but nothing that Find and Replace couldn’t fix in 5 minutes. A namespace alias would also fix existing code.

using JavaScriptConvert = Newtonsoft.Json.JsonConvert;

Thoughts? Objections?

Breaking the build server is Serious Business. Fortunately there are a set of rules put together by a group of wise and thoughtful men to encourage good build server practice. And beer.

Build Server Rules

1. The penalty for breaking the build is a beer.
2. A broken build beer can only be written up while the build is broken.
3. Once the build is broken, broken build beers will not be given until the build is fixed. It is considered bad form for other users to check in while the build is broken.
4. Broken builds resulting from environmental factors on the build server such as locked files or other transient behavior shall not be penalized.
5. Amnesty can be requested for tasks that can only be tested on the build server.
   1. Amnesty must be requested in advance.
   2. Amnesty requires the agreement of the build server council.
   3. While amnesty is in effect anyone can check into the build server with impunity.
   4. Amnesty ends once the task is complete and the build server is green.
6. Build beers must be cashed in upon a contributor reaching 12 broken builds. Multiples of 6 may be purchased.
7. Disputes are judged by a majority ruling of the build server council. Decisions and lulz are final.

Like developers must learn to honor the build server, testers must also be kept on their toes for that rare occasion when your code contains a bug.

QA Rules

1. Each undiscovered bug in a release, judged as one that should have been found by the council, is a beer.
2. The penalty for a bug found existing in multiple releases is a QA beer per release.

The rip in the fabric of space time between our universe and the bizzaro universe, where I am a SharePoint expert, continues to grow. First I presented a 400 level SharePoint session at TechEd and now I have helped put together a SharePoint presentation for PDC!

“Creating SharePoint Applications with Visual Studio 2008” presented by Chris Johnson walks through creating a SharePoint application using the Visual Studio 2008 extensions for SharePoint (VSeWSS). A bunch of people from Intergen contributed to the end product. I helped write the overall script with Mark Orange, one of Intergen’s actual SharePoint experts, and I wrote the application used in the presentation.

• Channel 9 Video
• Presentation Code

The application featured a new project announced at PDC: the Silverlight Control Toolkit. SharePoint hosted a Silverlight chart control that visualized data called from a WCF web service and SharePoint’s web services.

PDC Fireworks

The Wellington .NET usergroup had a special event last week covering what was announced at PDC. I gave a brief 15 minute introduction to using the Silverlight chart control. You can get the slides from my talk (all 6 of them!) here.

C# 4.0 Dynamic Lookup

I really like the way the C# team tackled bring dynamic programming to the language. C# is a static language but it is good to see that the C# team is pragmatic enough to realise that will always be situations where you don’t have type information at compile time.

With C# 4.0 rather than having to bust out ugly System.Reflection operations to interact with unknown objects, the new dynamic lookup hides any ugliness away from the developer. Statically typing an object as dynamic is a great solution as it lets you treat a specific object, which you don’t have type knowledge of, as you want with regular property and method calls while still keeping static typing throughout the rest of your application. I think this is a much better solution than the dynamic block discussed in the past.

Dynamic lookup also opens up some new interesting paradigms by offering the IDynamicObject interface to developers. The first thing I thought of when I saw it was Dynamic LINQ to JSON. I’m sure uses will come out of it that no one ever considered

C# 4.0 Covariance and Contravariance

Very happy to see this feature. I bumped my head into generic variance issues a number of times when writing LINQ to JSON. No longer having to worry about IEnumerable<JToken> not being compatible with IEnumerable<object> is great. They even kept it type safe!

C# 4.0 Named and optional parameters

Is it just me or did Anders wince when announcing named and optional parameter support in C# 4.0? Microsoft has said that they plan to keep the C#/VB.NET languages in sync and I wonder if this is C# inheriting VB.NET features by default.

.NET 4.0 Code Contracts

From everything I have seen of it so far I love the Code Contracts feature. Statically defining type information has been around forever and is A Good Thing. Its about time that we are able to statically define valid values as well.

.NET 4.0 Parallel Extensions

It is interesting to see parallel programming come as a library addition in the form of Parallel Extensions rather than a language feature (ditto for code contracts). I guess with a library you only need to create it once rather than having to figure out new concurrent programming syntax for every .NET language.

Bring on VS2010.