Develop Reference

Serializer that saved in text format (not binary) which does not require public constructor and can save fields

I'm looking for a Serializer to persist my classes in text format (not binary). But...
I'm already using protobuf for binary serialization. It works pretty fine. As a side note, I would have prefer not to deal with field id (index) like with protobuf.
Before closing or voting to close this question, please consider these points:
The specificity of this question
If other question really apply to my requirements and are not too old
I'm looking for a serializer with the following properties:
Easy to use
Serialize in text (readable) either Json or XML would be fine
Free
Is documented
Support versioning easily (obsolete field, type change, property name change, ...)
Uses Attribute to define items to serialize (or not serialize)
Does not uses an index (ID like Protobuf)
Be able like Protobuf, to deserialize an object directly without any constructor. Be able to instanciate an object either if the object does not have any public constructor and does not have any constructor with no arguments.
Does not require me to change my class or member accessibility, ie:
Does not need default constructor
Can serialize fields
Can skip public property (when marked to do so)
Others points not essential:
The speed is not important
Open source is a nice bonus
Has some examples is a nice bonus
Some examples of what I prefer to not use:
Microsoft XMLSerializer and JsonSerializer does require default constructor.
I have hard time using Microsoft-DataContractSerializer, an easier solution would be welcome.

Custom JSON converter to help deserialize back to objects of the exact original types

What I'm doing has already been implemented in Json.net by setting TypeNameHandling to TypeNameHandling.Objects. That way the object type will be serialized as well and the deserialized object will have the exact original type.
However using TypeNameHandling exposes some security issues and requires us to use a custom SerializationBinder to limit which types will be supported to avoid possible code injection. That's not the main reason for me trying to find another solution. Actually I find that by using TypeNameHandling.Objects, an object will be serialized to a complex JSON including not just the object data itself and the object type but also some other properties which look redundant to me.
I think we just need one more property containing info about object type (such as the assembly qualified name of the object type) so I would like to create a custom JsonConverter which will serialize any object to some JSON like this:
{
"Item" : "normal JSON string of object",
"ItemType" : "assembly qualified name of object type"
}
Isn't that just enough? As I said before, besides 2 properties similar to those (with different names), the Json.net lib includes some other properties (signature ...) which really look like redundant to me.
I'm not asking for how to implement the custom JsonConverter I mentioned above. I just wonder if that converter (with a simplified JSON structure) is fine or I should use the standard solution provided by Json.net with TypeNameHandling (which involves a more complex JSON structure)? My main concern is with possible performance issues with TypeNameHandling set to Objects due to more data to convert/serialize/transfer.
One more concern with the standard solution is performance issue, actually I just need to apply the custom converting logic to all objects of the exact type object, not to all other strongly typed objects (which may still be unnecessarily applied by TypeNameHandling?)

I have a few reactions to your proposed design for a polymorphic custom JsonConverter (let's call it PolymorphicConverter<T> where T is the base type):
Regarding security, you wrote,
... using TypeNameHandling exposes some security issues and requires us to use a custom SerializationBinder to limit which types will be supported to avoid possible code injection.
The same security risks that can arise with TypeNameHandling will also arise with PolymorphicConverter<T>.
The risk here is that an attacker tricks some polymorphic deserialization code into instantiating an attack gadget. See TypeNameHandling caution in Newtonsoft Json and External json vulnerable because of Json.Net TypeNameHandling auto? for examples and discussion. If an attacker crafts JSON with an attack gadget type specified in the "ItemType" property supported by your converter, then it may end up instantiating the attack gadget and effecting the attack.
You can reduce your attack surface by only enabling support for polymorphic deserialization for known polymorphic properties or arrays items by applying PolymorphicConverter<T> (or [JsonProperty(TypeNameHandling = TypeNameHandling.All)] for that matter) just to those properties that are actually polymorphic in practice -- but if the polymorphic base type of those properties just happens to be compatible with an attack gadget, you're going to be vulnerable to attack.
Thus, no matter what mechanism is used, you're still going to need something like a custom SerializationBinder to filter out naughty types, no matter the details of how you encode type information in your JSON.
JSON file size. Json.NET encodes type information by adding a single property to the beginning of objects:
"$type" : "assembly qualified name of object type"
Your plan is to instead add:
"ItemType" : "assembly qualified name of object type"
It is unclear why there would be an advantage, unless your type names are somehow more compact.
Performance. You wrote,
My main concern is with possible performance issues with TypeNameHandling set to Objects due to more data to convert/serialize/transfer.
Firstly, why not just measure and find out? See https://ericlippert.com/2012/12/17/performance-rant/
Secondly, Newtonsoft has a setting MetadataPropertyHandling, that, when set to Default, assumes that the polymorphic property "$type" comes first in each object, and thus is able to stream them in without pre-loading the entire JSON into a JToken hierarchy.
If your converter unconditionally preloads into a JToken hierarchy to fetch the value of the "ItemType" property, it may have worse performance.
Regarding restricting polymorphic deserialization to only required properties, you wrote:
One more concern with the standard solution is performance issue, actually I just need to apply the custom converting logic to all objects of the exact type object, not to all other strongly typed objects
Either way, this is possible with a custom ContractResolver. Override DefaultContractResolver.CreateProperty and, when JsonProperty.PropertyType == typeof(object), set TypeNameHandling or Converter as required, depending on your chosen solution.

Json Deserialization and controlling the instantiation

I am converting code that was written using NewtonSoft.JsonNet. This is actually a custom Json Media Type Formatter. I have to change it because Json.Net has proven that its performance is very poor under load. Many comparison on the Internet is also proving this.
Anyway, I have a base type called CatalogueItem. Three types are derived from this type and are called ContainerItem, SectionItem, and RefresherItem. Based on a property in the Json object which is called itemType we decide which sub-class must be instantiated.
var type = (string)jsonObject.Property("itemType");
switch (type)
{
case "Container":
return new ContainerItem();
case "Section":
return new SectionItem();
case "Refresher":
return new RefresherItem();
}
We used to do this with creating a custom CustomCreationConverter, and adding it to Serializer.Converters collection of Json.Net.Serializer. Trying to get rid of Json.Net, I am using ServiceStack.Text, but I don't know how can I control the type that is being generated using it. Can anyone please help me with this?
p.s. I found this post on StackOverflow in which similar issue has been answered. However, I get the json from a third-party web service so I cannot include type names in it. Plus, I cannot use the generic version of JsConfig because MediaTypeFormatter does not have any generic methods.

I recommend avoiding trying to coerce your JSON Serializer to your models and just use DTO's that map 1:1 to the wire format than use plain C# to map the typed DTO's to your desired domain models.
With that said, depending on what the JSON and DTO's look like you may be able to use one of:
JsConfig<CatalogueItem>.RawDeserializeFn
JsConfig<CatalogueItem>.DeSerializeFn
JsConfig<CatalogueItem>.OnDeserializedFn
Otherwise you can parse JSON dynamically using JsonObject, here's an example.

JSON.NET - exclude properties of a specific type at runtime

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.

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.

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.

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);
}
}

C# Advanced XML Serializer that doesn't require domain object pollution

Are there any closed or open source projects for a XML serializer for C# that can serialize for the most part any object without the need to pollute my domain objects with tons of attributes? That will also handle serialization of collections built with the internal generics classes? A bonus would be that it can handle serializing an interface type property. Another bonus would be that it can serialize objects that have read-only properties (or atleast with the get accessor marked internal)

Well, first define "advanced", i.e. what specifically do you need that XmlSerializer doesn't have. In terms of POCO, XmlSerializer has an overloaded ctor that accepts all the attributes you could ever want to add, to avoid having to add them to your object model - but it does still require a public parameterless constructor, and only works on public read/write fields/properties. And you should cache/re-use the serializer if you use this approach.
I'm not aware of any like alternatives, simply because in most cases this is "good enough" - and it is often a mistake to try to brute-force your existing domain object into a DTO. It may be simpler and more maintainable to simply map your domain entities onto a new DTO(s) that are attributed (and have appropriate ctor/properties/etc).
Note that for the ctor/properties issue DataContractSerializer has some answers, but this doesn't have as much fine-grained control over what the xml looks like.

You can allow System.Xml.dll to access your internals by using the InternalsVisibleToAttribute.
Thus serializing internal types and/or internal members. Including internal .ctors.
You can also implement IXmlSerializable on classes to customize their serialization (like the container containing interface references).
You do not have to provide the XML serialization attributes on your classes, but provide them as XmlAttributeOverrides instead.
XmlSerializer is almost always exactly what people want, they just don't know that it is as flexible as it really is.