93

My desktop application serializes objects using XmlSerializer. I was suggested to leverage DataContractSerializer instead.
Under which scenarios should I use DataContractSerializer?

Many thanks

Comments.
1. The output XML file is stored locally. No other applications deserialize objects from that XML file.
2. My application runs with .NET Framework 3.5 SP1.

Vitali Climenco
  • 1,294
  • 1
  • 12
  • 18
  • Also see [datacontract-vs-xmltype](http://stackoverflow.com/questions/624111/datacontract-vs-xmltype) – nawfal Jul 10 '14 at 12:20

1 Answers1

124

Dan Rigsby has the ultimate post on this - go read it!

XmlSerializer vs. DataContractSerializer (web archive)

He says all there is to say, and in a very convincing way.

In short:

XmlSerializer:

  • has been around for a long time
  • is "opt-out"; everything public gets serialized, unless you tell it not to ([XmlIgnore])

DataContractSerializer is:

  • the new kid in town
  • optimized for speed (about 10% faster than XmlSerializer, typically)
  • "opt-in" - only stuff you specifically mark as [DataMember] will be serialized
  • but anything marked with [DataMember] will be serialized - whether it's public or private
  • doesn't support XML attributes (for speed reasons)
Alexander Derck
  • 13,818
  • 5
  • 54
  • 76
marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
  • 2
    @Paul-SebastianManole: the DataContractSerializer doesn't support XML attributes - for speed reasons. What's to elaborate? – marc_s Jun 15 '13 at 15:20
  • Well, I'm new to .NET. I was about to go on using XmlSerializer since I found a few tutorials online. But then I found DataContractSerializer on MSDN which seems to be linked to WCF. What I want to do is, deserialize some XML into a plain object which would allow me access to an XML element and its attributes because I want to serialize those objects later, back into an XML document, after I calculate some values for the attributes. – Paul-Sebastian Manole Jun 15 '13 at 15:24
  • 6
    @Paul-SebastianManole: if your source XML contains attributes on XML elements (like ` ...` ) then you're only option is using the XML serializer – marc_s Jun 15 '13 at 15:25
  • 2
    This might be useful, taken from MSDN: _The XmlSerializer class supports a much narrower set of types than the DataContractSerializer class, but allows much more control over the resulting XML and supports much more of the XML Schema definition language (XSD) standard. It also does not require any declarative attributes on the serializable types... The XmlSerializer class does not support data contract types._ [MSDN](http://msdn.microsoft.com/en-us/library/ms733901.aspx). – Paul-Sebastian Manole Jun 15 '13 at 15:31
  • You should probably add this to SO as your own question - explain what you want to do, show what you've tried so far, explain where you're stuck or unsure - I'm sure someone will provide an answer! – marc_s Jun 15 '13 at 15:34
  • @marc_s No longer opt-in for .NET 3.5 SP1 and above. – O.O Nov 10 '13 at 18:58
  • 1
    @O.O: not **only** opt-in, in .NET 3.5 SP1 and newer - but for me, it's still the **preferred way** of doing things. Allows you to set properties that otherwise cannot be set (like order of serialization, namespaces and much more!) – marc_s Nov 10 '13 at 21:31
  • @marc_s - hmm, for some reason I am getting properties that have values show up in the xml that do not have [DataMember] attribute. I guess I don't understand the only part of your comment. – O.O Nov 11 '13 at 03:56
  • DCS can serialize private members too which I think is worth mentioning. – nawfal Jul 10 '14 at 07:48
  • @nawfal: right - anything marked with the `[DataMember]` attribute will be serialized – marc_s Jul 10 '14 at 07:52
  • 25
    Biggest warning about the DataContractSerializer - when deserializing, it cares about the order of the elements and fails silently if they're not in the correct order. Imho, unless you're using the exact same assemblies at both ends, this makes it unusably dangerous. – Pxtl Feb 12 '15 at 22:37
  • @Pxtl: that's not really a "shortcoming" of the DataContractSerializer - that's the way the XML schema handles `` constructs...- – marc_s Feb 13 '15 at 05:44
  • 2
    It's still pretty unexpected behavior if you're used to the more permissive nature of the XmlSerializer. In this day and age, the user might assume the more Json-like behavior of – Pxtl Jul 30 '15 at 17:03
  • 2
    I second @Pxtl, I am serializing to file with a changing schema where there is refactoring on the inherited base classes - I don't care about the order I don't care about web services - I only want backward compatibility in my classes - this is a silent showstopper for me I barely realized before going into production and I am simply thankful for it. – user3141326 Sep 04 '16 at 15:20
  • 1
    Note: XmlSerializer does not support the DateTimeOffset type. Just got bitten by this. – Onots Oct 05 '16 at 08:46
  • 4
    After getting burned by a few things (mainly deserilization order) by the DataContractSerializer, I would recommend staying away from it unless you control both ends of the service and you need your service to be extremely fast. If you control only the one end and you can't control what the other side is doing the safe bet is the XMLserializer plus those XML attributes that can be seen make documentation of your service a lot easier. – infocyde Jan 14 '19 at 19:34