I guess the title is a little misleading because there is seldom any fun to be had with the .NET Framework.
But if you've got a Linq to SQL *.dbml and the tool is generating those swell ExtensionDataObject properties preventing you from easily serializing your model classes to JSON and you don't want to make shadow classes (::gasp:: yes I know the .NET Fx loves ceremony, I however do not) then you can use a custom JavaScriptConverter to ignore those properties. When you have control of a class you can put a NonSerialized attribute on properties but that becomes substantially more difficult when a tool is responsible for generating the class file and cheerfully overwrites any changes you may make if you even open the file to glance at its contents. Yes shitty *.dbml tool in Visual Studio, I'm looking at you.
So let's say you have this simple helper class:
// JsonSerializationUtility.cs
public static class JsonSerializationUtility
{
public static string ToJson(this object obj, string wrapper = null)
{
var json = new JavaScriptSerializer().Serialize(obj);
if (!string.IsNullOrEmpty(wrapper))
json = "{ \"" + wrapper + "\": " + json + " }";
return json;
}
public static T Deserialize<T>(string json)
{
var jss = new JavaScriptSerializer();
jss.RegisterConverters(new [] { new ExtensionDataObjectConverter() });
var result = jss.Deserialize<T>(json);
return result;
}
}
... then you'll need this handy ExtensionDataObjectConverter class!
// ExtensionDataObjectConverter.cs
public class ExtensionDataObjectConverter : JavaScriptConverter
{
public override IEnumerable<Type> SupportedTypes
{
get
{
return new ReadOnlyCollection<Type>(new [] { typeof(ExtensionDataObject) });
}
}
public override IDictionary<string, object> Serialize(object obj, JavaScriptSerializer serializer)
{
return null;
}
public override object Deserialize(IDictionary<string, object> dictionary, Type type, JavaScriptSerializer serializer)
{
return null;
}
}