This repo contains a simple setup for exploring the behaviour of version dependencies with json.net when running as part of an Azure Function (v1). The solution contains two Projects:
A basic repository-pattern style class library (C# Class Library compiling to .net Standard 2). Contains:
- abstract base class modelling data entities plus a single concrete implementation
- simple repostiory for supporting R + W operations
- Utils package for working with CosmosDb
An Azure Functions (V1) app (.Net Full Framework 4.7.2).
- Contains a single function triggered via a HTTP request.
- Function parses some hard-coded JSON to build up an object, stores it in CosmosDB and examines the Types of data present at various points
- Outputs results of tests to the Function console log
This setup is a representative example of our production architecture. Both Projects include an explict reference to Newtonsoft.Json
version 10.0.3
Deserializing JSON with "complex" properties (nested objects) to anonymous objects (e.g. Dictionary<string, object>
) results in those complex properties being represented as JObjects
(Newtonsoft.Json.Linq.JObject
). At the point of deserisling, and passing these into the data project, Type checking is working as expected:
sprocketItem["Supplier"].GetType().FullName; //"Newtonsoft.Json.Linq.JObject"
sprocketItem["Supplier"].GetType() == typeof(Newtonsoft.Json.Linq.JObject); //true
However after the entity passes through the CosmosDB Client, these Type checks fail
itemAfterSave["Supplier"].GetType().FullName; //"Newtonsoft.Json.Linq.JObject"
itemAfterSave["Supplier"].GetType() == typeof(Newtonsoft.Json.Linq.JObject); //false
Additionally, with our production stack, we are seeing different behaviour with how CosmosDB is serialising DynamicObjects when compared to running in a WebAPI with binding redirects to force json.net to 10.0.3