I've been working on a request to the West Wind Application Configuration library to add JSON support. The config library is a very easy to use code-first approach to configuration: You create a class that holds the configuration data that inherits from a base configuration class, and then assign a persistence provider at runtime that determines where and how the configuration data is store. Currently the library supports .
NET Configuration stores (web.config/app.config), XML files, SQL records and string storage.About once a week somebody asks me about JSON support and I've deflected this question for the longest time because frankly I think that JSON as a configuration store doesn't really buy a heck of a lot over XML. Both formats require the user to perform some fixup of the plain configuration data - in XML into XML tags, with JSON using JSON delimiters for properties and property formatting rules. Sure JSON is a little less verbose and maybe a little easier to read if you have hierarchical data, but overall the differences are pretty minor in my opinion. And yet - the requests keep rolling in.Hard Link Issues in a Component LibraryAnother reason I've been hesitant is that I really didn't want to pull in a dependency on an external JSON library - in this case JSON.
NET - into the core library. If you're not using JSON.
NET elsewhere I don't want a user to have to require a hard dependency on JSON.
NET unless they want to use the JSON feature. JSON.
NET is also sensitive to versions and doesn't play nice with multiple versions when hard linked. For example, when you have a reference to V4.4 in your project but the host application has a reference to version 4.5 you can run into assembly load problems. NuGet's Update-Package can solve some of this *if* you can recompile, but that's not ideal for a component that's supposed to be just plug and play. This is no criticism of JSON.
NET - this really applies to any dependency that might change. So hard linking the DLL can be problematic for a number reasons, but the primary reason is to not force loading of JSON.
NET unless you actually need it when you use the JSON configuration features of the library.Enter
Dynamic LoadingSo rather than adding an assembly reference to the project, I decided that it would be better to dynamically load the DLL at runtime and then use
dynamic typing to access various classes. This allows me to run without a hard assembly reference and allows more flexibility with version number differences now and in the future.But there are also a couple of downsides:No assembly reference means only
dynamic access - no compiler type checking or IntellisenseRequirement for the host application to have reference to JSON.
NET or else get runtime errorsThe former is minor, but the latter can be problematic. Runtime errors are always painful, but in this case I'm willing to live with this. If you want to use JSON configuration settings JSON.
NET needs to be loaded in the project. If this is a Web project, it'll likely be there already.So there are a few things that are needed to make this work:Dynamically create an instance and optionally attempt to load an Assembly (if not loaded)Load types into
dynamic variablesUse Reflection for a few tasks like statics/enumsThe
dynamic keyword in C# makes the formerly most difficult Reflection part - method calls and property assignments - fairly painless. But as cool as
dynamic is it doesn't handle all aspects of Reflection. Specifically it doesn't deal with object activation, truly
dynamic (string based) member activation or accessing of non instance members, so there's still a little bit of work left to do with Reflection.
Dynamic Object InstantiationThe first step in getting the process rolling is to instantiate the type you need to work with. This might be a two step process - loading the instance from a string value, since we don't have a hard type reference and potentially having to load the assembly. Although the host project might have a reference to JSON.
NET, that instance might have not been loaded yet since it hasn't been accessed yet. In
ASP.
NET this won't be a problem, since
ASP.
NET preloads all referenced assemblies on AppDomain startup, but in other executable project, assemblies are just in time loaded only when they are accessed.Instantiating a type is a two step process: Finding the type reference and then activating it. Here's the generic code out of my ReflectionUtils library I use for this:/// <summary>
/// Creates an instance of a type based on a string. Assumes that the type's
/// </summary>
/// <param name="typeName">Common name of the type</param>
/// <param name="args">Any constructor parameters</param>
/// <returns></returns>
public
static object CreateInstanceFromString(string typeName, params object[] args)
{
object instance = null;
Type type = null;
try
{
type = GetTypeFromName(typeName);
if (type == null)
return null;
instance = Activator.CreateInstance(type, args);
}
catch
{
return null;
}
return instance;
}
/// <summary>
/// Helper routine that looks up a type name and tries to retrieve the
/// full type reference in the actively executing assemblies.
/// </summary>
/// <param name="typeName"></param>
/// <returns></returns>
public
static Type GetTypeFromName(string typeName)
{
Type type = null;
// Let default name binding find it
type = Type.GetType(typeName, false);
if (type != null)
return type;
// look through assembly list
var assemblies = AppDomain.CurrentDomain.GetAssemblies();
// try to find manually
foreach (Assembly asm in assemblies)
{
type = asm.GetType(typeName, false);
if (type != null)
break;
}
return type;
}
To use this for loading JSON.
NET I have a small factory function that instantiates JSON.
NET and sets a bunch of configuration settings on the generated object. The startup code also looks for failure and tries loading up the assembly when it fails since that's the main reason the load would fail. Finally it also caches the loaded instance for reuse (according to James the JSON.
NET instance is thread safe and quite a bit faster when cached). Here's what the factory function looks like in JsonSerializationUtils:/// <summary>
/// Dynamically creates an instance of JSON.
NET
/// </summary>
/// <param name="throwExceptions">If true throws exceptions otherwise returns null</param>
/// <returns>Dynamic JsonSerializer instance</returns>
public
static dynamic CreateJsonNet(bool throwExceptions = true)
{
if (JsonNet != null)
return JsonNet;
lock (SyncLock)
{
if (JsonNet != null)
return JsonNet;
// Try to create instance
dynamic json = ReflectionUtils.CreateInstanceFromString("Newtonsoft.Json.JsonSerializer");
if (json == null)
{
try
{
var ass = AppDomain.CurrentDomain.Load("Newtonsoft.Json");
json = ReflectionUtils.CreateInstanceFromString("Newtonsoft.Json.JsonSerializer");
}
catch (Exception ex)
{
if (throwExceptions)
throw;
return null;
}
}
if (json == null)
return null;
json.ReferenceLoopHandling =
(dynamic) ReflectionUtils.GetStaticProperty("Newtonsoft.Json.ReferenceLoopHandling", "Ignore");
// Enums as strings in JSON
dynamic enumConverter = ReflectionUtils.CreateInstanceFromString("Newtonsoft.Json.Converters.StringEnumConverter");
json.Converters.Add(enumConverter);
JsonNet = json;
}
return JsonNet;
}This code's purpose is to return a fully configured JsonSerializer instance. As you can see the code tries to create an instance and when it fails tries to load the assembly, and then re-tries loading.Once the instance is loaded some configuration occurs on it. Specifically I set the ReferenceLoopHandling option to not blow up immediately when circular references are encountered. There are a host of other small config setting that might be useful to set, but the default seem to be good enough in recent versions. Note that I'm setting ReferenceLoopHandling which requires an Enum value to be set. There's no real easy way (short of using the cardinal numeric value) to set a property or pass parameters from
static values or enums. This means I still need to use Reflection to make this work. I'm using the same ReflectionUtils class I previously used to handle this for me. The function looks up the type and then uses Type.InvokeMember() to read the
static property.Another feature I need is have Enum values serialized as strings rather than numeric values which is the default. To do this I can use the StringEnumConverter to convert enums to strings by adding it to the Converters collection.As you can see there's still a bit of Reflection to be done even in C# 4+ with
dynamic, but with a few helpers this process is relatively painless.Doing the actual JSON ConversionFinally I need to actually do my JSON conversions. For the Utility class I need serialization that works for both strings and files so I created four methods that handle these tasks two each for serialization and deserialization for string and file.Here's what the File Serialization looks like:/// <summary>
/// Serializes an object instance to a JSON file.
/// </summary>
/// <param name="value">the value to serialize</param>
/// <param name="fileName">Full path to the file to write out with JSON.</param>
/// <param name="throwExceptions">Determines whether exceptions are thrown or false is returned</param>
/// <param name="formatJsonOutput">if true pretty-formats the JSON with line breaks</param>
/// <returns>true or false</returns>
public
static bool SerializeToFile(object value, string fileName, bool throwExceptions = false, bool formatJsonOutput = false)
{
dynamic writer = null;
FileStream fs = null;
try
{
Type type = value.GetType();
var json = CreateJsonNet(throwExceptions);
if (json == null)
return false;
fs = new FileStream(fileName, FileMode.Create);
var sw = new StreamWriter(fs, Encoding.UTF8);
writer = Activator.CreateInstance(JsonTextWriterType, sw);
if (formatJsonOutput)
writer.Formatting = (dynamic)Enum.Parse(FormattingType, "Indented");
writer.QuoteChar = '"';
json.Serialize(writer, value);
}
catch (Exception ex)
{
Debug.WriteLine("JsonSerializer Serialize error: " + ex.Message);
if (throwExceptions)
throw;
return false;
}
finally
{
if (writer != null)
writer.Close();
if (fs != null)
fs.Close();
}
return true;
}You can see more of the
dynamic invocation in this code. First I grab the
dynamic JsonSerializer instance using the CreateJsonNet() method shown earlier which returns a
dynamic. I then create a JsonTextWriter and configure a couple of enum settings on it, and then call Serialize() on the serializer instance with the JsonTextWriter that writes the output to disk. Although this code is
dynamic it's still fairly short and readable.For full circle operation here's the DeserializeFromFile() version:/// <summary>
/// Deserializes an object from file and returns a reference.
/// </summary>
/// <param name="fileName">name of the file to serialize to</param>
/// <param name="objectType">The Type of the object. Use typeof(yourobject class)</param>
/// <param name="binarySerialization">determines whether we use Xml or Binary serialization</param>
/// <param name="throwExceptions">determines whether failure will throw rather than return null on failure</param>
/// <returns>Instance of the deserialized object or null. Must be cast to your object type</returns>
public
static object DeserializeFromFile(string fileName, Type objectType, bool throwExceptions = false)
{
dynamic json = CreateJsonNet(throwExceptions);
if (json == null)
return null;
object result = null;
dynamic reader = null;
FileStream fs = null;
try
{
fs = new FileStream(fileName, FileMode.Open, FileAccess.Read);
var sr = new StreamReader(fs, Encoding.UTF8);
reader = Activator.CreateInstance(JsonTextReaderType, sr);
result = json.Deserialize(reader, objectType);
reader.Close();
}
catch (Exception ex)
{
Debug.WriteLine("JsonNetSerialization Deserialization Error: " + ex.Message);
if (throwExceptions)
throw;
return null;
}
finally
{
if (reader != null)
reader.Close();
if (fs != null)
fs.Close();
}
return result;
}This code is a little more compact since there are no prettifying options to set. Here JsonTextReader is created dynamically and it receives the output from the Deserialize() operation on the serializer.You can take a look at the full JsonSerializationUtils.cs file on GitHub to see the rest of the operations, but the string operations are very similar - the code is fairly repetitive.These generic serialization utilities isolate the
dynamic serialization logic that has to deal with the
dynamic nature of JSON.
NET, and any code that uses these functions is none the wiser that JSON.
NET is dynamically loaded.Using the JsonSerializationUtils WrapperThe final consumer of the SerializationUtils wrapper is an actual ConfigurationProvider, that is responsible for handling reading and writing JSON values to and from files. The provider is simple a small wrapper around the SerializationUtils component and there's very little code to make this work now:The whole provider looks like this:/// <summary>
/// Reads and Writes configuration settings in .
NET config files and
/// sections. Allows reading and writing to default or external files
/// and specification of the configuration section that settings are
/// applied to.
/// </summary>
public class JsonFileConfigurationProvider<TAppConfiguration> : ConfigurationProviderBase<TAppConfiguration>
where TAppConfiguration: AppConfiguration, new()
{
/// <summary>
/// Optional - the Configuration file where configuration settings are
/// stored in. If not specified uses the default Configuration Manager
/// and its default store.
/// </summary>
public string JsonConfigurationFile
{
get { return _JsonConfigurationFile; }
set { _JsonConfigurationFile = value; }
}
private string _JsonConfigurationFile = string.Empty;
public override bool Read(AppConfiguration config)
{
var newConfig = JsonSerializationUtils.DeserializeFromFile(JsonConfigurationFile, typeof(TAppConfiguration)) as TAppConfiguration;
if (newConfig == null)
{
if(Write(config))
return true;
return false;
}
DecryptFields(newConfig);
DataUtils.CopyObjectData(newConfig, config, "Provider,ErrorMessage");
return true;
}
/// <summary>
/// Return
/// </summary>
/// <typeparam name="TAppConfig"></typeparam>
/// <returns></returns>
public override TAppConfig Read<TAppConfig>()
{
var result = JsonSerializationUtils.DeserializeFromFile(JsonConfigurationFile, typeof(TAppConfig)) as TAppConfig;
if (result != null)
DecryptFields(result);
return result;
}
/// <summary>
/// Write configuration to XmlConfigurationFile location
/// </summary>
/// <param name="config"></param>
/// <returns></returns>
public override bool Write(AppConfiguration config)
{
EncryptFields(config);
bool result = JsonSerializationUtils.SerializeToFile(config, JsonConfigurationFile,false,true);
// Have to decrypt again to make sure the properties are readable afterwards
DecryptFields(config);
return result;
}
}This incidentally demonstrates how easy it is to create a new provider for the West Wind Application Configuration component. Simply implementing 3 methods will do in most cases.Note this code doesn't have any
dynamic dependencies - all that's abstracted away in the JsonSerializationUtils(). From here on, serializing JSON is just a matter of calling the
static methods on the SerializationUtils class.Already, there are several other places in some other tools where I use JSON serialization this is coming in very handy. With a couple of lines of code I was able to add JSON.
NET support to an older AJAX library that I use replacing quite a bit of code that was previously in use. And for any other manual JSON operations (in a couple of apps I use JSON Serialization for 'blob' like document storage) this is also going to be handy.Performance?Some of you might be thinking that using
dynamic and Reflection can't be good for performance. And you'd be right… In performing some informal testing it looks like the performance of the native code is nearly twice as fast as the
dynamic code. Most of the slowness is attributable to type lookups. To test I created a native class that uses an actual reference to JSON.
NET and performance was consistently around 85-90% faster with the referenced code. That being said though - I serialized 10,000 objects in 80ms vs. 45ms so this isn't hardly slouchy. For the configuration component speed is not that important because both read and write operations typically happen once on first access and then every once in a while. But for other operations - say a serializer trying to handle AJAX requests on a Web Server one would be well served to create a hard dependency.
Dynamic Loading - Worth it?On occasion
dynamic loading makes sense. But there's a price to be paid in added code complexity and a performance hit. But for some operations that are not pivotal to a component or application and only used under certain circumstances
dynamic loading can be beneficial to avoid having to ship extra files and loading down distributions. These days when you create new projects in Visual Studio with 30 assemblies before you even add your own code, trying to keep file counts under control seems a good idea. It's not the kind of thing you do on a regular basis, but when needed it can be a useful tool. Hopefully some of you find this information useful…© Rick Strahl, West Wind Technologies, 2005-2013Posted in .NET C#
Tweet
!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");
(function() {
var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true;
po.src = 'https://apis.google.com/js/plusone.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s);
})();
