This is a pretty common problem people run into when they start using serializers. While it is a little puzzling why the limitation you discovered exists, there is a simple solution.
When I first wrote this answer a number of years back, Gordon Bean had replied with a workable solution to the problem using a type converter. You probably don't want to use that approach, though. It works, but it provides a serialized string for output. If you are using JSON, this will give you a less than ideal result, since you really want a JSON representation of an object and not a string representation.
for example, let's suppose that you have a data structure that associates unique grid points with strings:
class Point
{
public int x { get; set; }
public int y { get; set; }
}
public Dictionary<Point,string> Locations { get; set; };
Using the TypeConverter override, you will get a string representation of this object when you serialize it.
"Locations": {
"4,3": "foo",
"3,4": "bar"
},
But what we really want is:
"Locations": {
{ "x": 4, "y": 3 }: "foo",
{ "x": 3, "y": 4 }: "bar"
},
There are several problems with overriding the TypeConverter to serialize / deserialize the class.
First, this is not JSON, and you might have to write additional custom logic to deal with serialize and deserialize it elsewhere. (perhaps Javascript in your client layer, for example?)
Second, anywhere else that uses this object will now produce this string, where previously it serialized properly to an object. For example,
"GridCenterPoint": { "x": 0, "y": 0 },
now serializes to:
"GridCenterPoint": "0,0",
You can control the TypeConverter formatting a little, but you cannot get away from the fact it is rendered as a string and not an object.
This problem isn't a problem with the serializer, since Json.NET chews through complex objects without missing a beat, it is a problem with the way that dictionary keys are processed. If you try taking the example object, and serializing a List or even a Hashset, you notice that there isn't a problem producing proper JSON. This gives us a much simpler way to solve this problem.
Ideally, we would like to just tell Json.NET to serialize the key as whatever object type it is, and not force it to be a string. Since that doesn't seem to be an option, the other way is to give Json.NET something that it can work with: a List<KeyValuePair<T,K>>.
If you feed a list of KeyValuePairs into Json.NET's serializer, you get exactly what you expect. For example, here is a much simpler wrapper that you could implement:
private Dictionary<Point, string> _Locations;
public List<KeyValuePair<Point, string>> SerializedLocations
{
get { return _Locations.ToList(); }
set { _Locations= value.ToDictionary(x => x.Key, x => x.Value); }
}
Update from @bmw15 comment:
You can make the Dictionary prop public, add a [JsonIgnore] to it, and make
the list of KeyValuePairs private, with a [JsonProperty] attribute
This trick works, because keys in a kvp aren't forced into string format. Why does the type converter generate a string format, you ask? It beats the hell out of me. The Dictionary object implements the IEnumerable<KeyValuePair<TKey, TValue>> interface, so there shouldn't be any problem in serializing it in the same fashion as the list of kvps, since that is essentially what a dictionary is. Someone (James Newton?) made a decision when writing the Newtonsoft dictionary serializer that complex keys were too messy to deal with. There are probably some corner cases I have not considered that make this a much more sticky problem.
I think that this is a much better solution because it produces actual JSON objects, is technically simpler, and doesn't produce any side effects resulting from replacing the serializer.
