This project is read-only.
DotSerialize recognizes the existing attributes of DataContract and DataMember used by the DataContractSerializer and will use them when serializing. When DotSerialize encounters a class that is decorated with a DataContract attribute, it switches into whitelist mode. This means that by default DotSerialize ignores all fields and properties in the class for serialization. Only those fields or properties decorated by either a DataMember, XmlElement or XmlAttribute attribute will be included for serialization. DotSerialize will use any names and ordering supplied in DataMember attributes to determine the names and ordering of output xml elements.
[DataContract]
class User
{
   [DataMember(Order = 1)] string Name { get; set; }
   string Password { get; set; }
   [DataMember(Order = 3)] string Domain { get; set; }
   [DataMember(Name = "Dept", Order = 2)] string Department { get; set; }
   string Background { get; set; }
}
In the above example, only the properties Name, Domain and Department will be serialized. The serialized output of an example instance of the class above might look something like the following:
<?xml version="1.0" encoding="utf-16"?>
<User>
  <Name>Joe Thomas</Name>
  <Dept>Finance</Dept>
  <Domain>Code.com</Domain>
</User>
The exact output will differ a bit because DotSerialize adds various attributes to the output to deal with polymorphic and referential integrity concerns.
It is very important to note that the XmlRoot attribute has higher priority over DataContract. This means if you decorate your class with both, DotSerialize will take the information from the XmlRoot attribute. This is to allow classes to support data contracts will still allowing a different layout for DotSerialize (most likely a very rare case). Likewise the XmlElement and XmlAttribute attributes take priority over the DataMember attribute if both are present.

Last edited Feb 28, 2015 at 1:12 AM by WiredWiz, version 6