8

I'm wondering how to exclude/strip certain properties of given type(s) (or collections of those) from being serialized using Json.NET library? I tried to write my own contract resolver (inheriting from DefaultContractResolver) with no luck.

I know that I could be done using DataAnnotations, decorating the excluded properties with ScriptIgnoreAttribute, but it's not applicable in my scenario. The objects serialized can be virtually anything, so I don't know which properties to exclude at design-time. I know only the types of properties that should not be serialized.

It looks like a rather simple task, but unfortunately I couldn't find a decent solution anywhere...

BTW - I'm not bound to Json.NET library - if it can easily be done with default/other .NET JSON serializers it'd be an equally good solution for me.

UPDATE

The properties has to be excluded before trying to serialize them. Why?

Basically, the types of objects I'm receiving and serializing can have dynamic properties of type inheriting from IDynamicMetaObjectProvider. I'm not going to describe all the details, but the DynamicMetaObject returned from GetMetaObject method of these objects doesn't have DynamicMetaObject.GetDynamicMemberNames method implemented (throws NotImplementedException...). Summarizing - the problem is those objects (I need to exclude) doesn't allow to enumerate their properties, what Json.NET serializer tries to do behind the scenes. I always end up with NotImplementedException being thrown.

Improve this question
6
  • So, to clarify, you want to exclude from serialization properties whose values implement IDynamicMetaObjectProvider? I am very familiar with dynamic types, but I am unsure in your case what you are actually serializing. It sounds like you are serializing normal classes and want to exclude certain properties on these that reference dynamic instances. At the same time you also indicated that you do not know the types, or base types, of the items you are serializing--just that they occasionally reference properties that are dynamic and cannot be serialized. Please post a simple example. Commented May 27, 2011 at 17:27
  • Exactly that! The root object I'm serializing can be anything, but sometimes it may have a dynamic property (which references some IDynamicMetaObjectProvider object, or a collection of some), which I want to exclude from serialization. Serialized object is not dynamic, only the excluded property/ies are. Commented May 27, 2011 at 17:37
  • Is it sufficient to your need to not completely exclude these properties by instead to serialize them as empty objects? So a property named Foo whose instance is dynamic would be serialized as Foo: {} Commented May 27, 2011 at 18:42
  • @Jamie: That'd be perfectly sufficient, yes. They are not going to be de-serialized to .NET objects, but only reused client-side in JS. Commented May 27, 2011 at 18:48
  • Do you know the type of the dynamic property values themselves? For example, are they instances of DynamicObject or some other known type implementing IDynamicMetaObjectProvider or are they also completely random classes from other libraries not known at design time? Commented May 27, 2011 at 18:59

3 Answers 3

Reset to default
5

I have tried both the WCF JSON serialization as well as the System.Web.Script.Serialization.JavaScriptSerializer. I have found if you want solid control of the serialization process and do not want to be bound by attributes and hacks to make things work, the JavaScriptSerializer is the way to go. It is included in the .NET stack and allows you to create and register JavaScriptConverter subclasses to perform custom serialization of types.

The only restriction I have found that may cause you a problem is that you cannot easily register a converter to convert all subclasses of Object (aka, one converter to rule them all). You really need to have knowledge of common base classes or preregister the set of types up front by scanning an assembly. However, property serialization is entirely left up to you, so you can decide using simple reflection which properties to serialize and how.

Plus, the default serialization is much much much better for JSON than the WCF approach. By default, all types are serializable without attributes, enums serialize by name, string-key dictionaries serialize as JSON objects, lists serialize as arrays, etc. But for obvious reasons, such as circular trees, even the default behavior needs assistance from time to time.

In my case, I was supporting a client-API that did not exactly match the server class structure, and we wanted a much simpler JSON syntax that was easy on the eyes, and the JavaScriptSerializer did the trick every time. Just let me know if you need some code samples to get started.

Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

@Jamie: Thanks for the info, but unfortunately I cannot know the exact type of a serialized object at design time, as they can be just anything. I only know the exact types that shouldn't be serialized
Do you need to perform custom serialization for all types found in the .NET framework itself, or just types in your own projects or assemblies you are referencing. If the later, you could easily register converters for all types in your assemblies (less exclusions of your choosing). This could be as simple passing something like assembly.GetTypes().Where(t => t.IsClass) during the registration process.
@Jamie: Application has a modular structure, so assemblies from which the objects come can be added/removed at runtime. Btw it looks like an overkill to scan all assemblies and gather all types just to do simple JSON serialization.
Agreed. I fortunately have not needed to resort to this approach. However, that is my only frustration with the JavaScriptSerializer as it requires you to specify the supported types for a converter up front instead of allowing you to specify a predicate Func<Type, bool> to indicate support on the fly and then caching the result in an internal hashtable to not adversely affect performance.
Since you know the exact runtime types of the instances you want to avoid serializing, you can register a JavaScriptConverter that returns these types from the SupportedTypes property. Then just override Serialize in the converter and return an empty hashtable (or potentially null) indicating that you do not want to serialize anything.
|
2

Create your own contract resolver, override the method that creates the properties for an object and then filter the results to only include those that you want.

Improve this answer

1 Comment

thanks for the tip. I've tried that, but couldn't get it to work as I need to exclude certain properties before serializer even tries to inspect them. Some of the dynamic objects I need to exclude doesn't allow to enumerate their members and throw an exception if you try. So filtering the results is not going to work... I've updated the question accordingly.
-1

Have you considered using the ShouldSerialize prefix property to exclude the property of your specific type at runtime?

public class Employee
{
  public string Name { get; set; }
  public Employee Manager { get; set; }

  public bool ShouldSerializeManager()
  {
    return (Manager != this);
  }
}
Improve this answer

1 Comment

Yes, but unfortunately this did not address my issue. It was about not being able to choose certain properties (based on their type) of some arbitrary object (not known at design time) and exclude those from serialization. I knew only the types that shouldn't get serialized, nothing else.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.