Is there a way to make DataContractSerializer output cleaner XML?

Question

Using the DataContractSerializer to serialize my object I get an output similar to

 <?xml version="1.0" encoding="utf-8" ?> 
 <AgentNotification xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/The.name.space.Notifications">
  <_x003C_Created_x003E_k__BackingField i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/The.name.space" /> 
  <_x003C_Id_x003E_k__BackingField i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/The.name.space" />        
 <_x003C_Email_x003E_k__BackingField>[email protected]</_x003C_Email_x003E_k__BackingField> 
  <_x003C_Name_x003E_k__BackingField>Random Person</_x003C_Name_x003E_k__BackingField> 
 <_x003C_Policies_x003E_k__BackingField>
 <PolicyNotification>
  <_x003C_Created_x003E_k__BackingField i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/The.name.space" /> 
  <_x003C_Id_x003E_k__BackingField i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/The.name.space" /> 
  <_x003C_ConfirmationNumber_x003E_k__BackingField>Some number</_x003C_ConfirmationNumber_x003E_k__BackingField>   
  </PolicyNotification>
 <PolicyNotification>
  </_x003C_Policies_x003E_k__BackingField>  
  </AgentNotification>

Is there any way for it to output tags that are just

<Id>
<Name>

etc, without the need to cover my classes with attributes?

If there's not a way the output of this is guaranteed to be the same every time correct? So that if I use this to render my object graphs are XML to mash up with an X* document for file generation that I'll never run into an issue where my nodes change names and the document comes out blank correct?

Lingonberry

No. And stop worrying about how your xml looks. It only leads to heartbreak. – Dunois

You should make that an answer Will. – Lingonberry

Answer 1

This is happening because you must have marked your types (e.g. AgentNotification) with [Serializable]. When DataContractSerializer encounters a type marked with [Serializable] but no explicit [DataContract], it generates a default contract for the type that matches how BinaryFormatter serializes a class, which is to serialize all member variables of a class — even variables marked as private — by name. For auto-implemented properties, this means the secret backing fields get serialized by name; their names are the peculiar element names you are seeing.

The easiest way to solve this is to remove the [Serializable] attribute from your classes. You almost certainly don't need it unless you are actually using BinaryFormatter or SoapFormatter. Having done so, DataContractSerializer will now serialize your public properties and fields by name, rather than public and private fields by name.

Butcher

That probably would have been what i wanted 6 years ago. But at some point i just stopped using XSLT and started using Postal + RazorViewEngine to generate email content. – Lingonberry

In my case, add [DataContract] in addition of [Serializable] (which was mandatory) solves the case – Camisole

Answer 2

The long element names (such as, _x003C_Created_x003E_k__BackingField) are created by .NET when you use autoproperties.

If you changed them to properties with backing fields, they would instead use your backing field names. You can do that without adding any attributes to your code.

(Beyond that, simply adding a [DataContract] attribute to your class definition will tidy up your XML a lot -- though not completely.)

Evin

I'll have to check what difference that makes, I can accept placing an attribute at the class level especially since these classes are datacontracts even if they aren't exposed through WCF – Lingonberry

I'm interested in your experience. Serialization seems poorly defined, and suffers from multiple solutions. – Evin

Answer 3

The DataContractSerializer will serialize either all public properties (if you don't specify anything - possible as of .NET 3.5 SP1), or (the approach I prefer) anything you label with a [DataMember] attribute.

So the best you can do is mark your class with a [DataContract] attribute, and all the members (properties, fields, etc.) that you really want in your data contract with a [DataMember] attribute.

The DataContractSerializer doesn't really allow much more control than that - you can define quite clearly (using this explicit "opt-in" approach) what gets serialized, but you have little or no control over how it gets serialized.

But do you really need that? REALLY?

If so, you'll probably have to use the XmlSerializer for that serialization process instead - there you can get more control over how things are serialized (but as a drawback, the XmlSerializer will serialize every public property that's not explicitly marked with a [XmlIgnore] attribute - an "opt-out" scheme).

Check out Dan Rigsby's blog post on the differences between DataContractSerializer and XmlSerializer and what each of them has to offer.

Mer

I do want it to serialize all the properties, XMLSerializer isn't even an option since my object has an IList in it. I was asking about the naming scheme as it would be easier in my transform docs if the properties exactly matched my class objects. – Lingonberry

have you decorated your class and properties with [DataMember] attributes? You can define a name with those: [DataMember(Name="xyz")] - does that help in your case? – Mer

have you decorated the classes that will end up inside your IList with the [DataContract] and [DataMember] attribute? It almost looks as if you didn't... – Mer

Correct, I have not used any attributes that is what my entire question is pivotal on, I refuse to pollute my domain model for presentation which is why I serialize to XML to do XSLT transforms for document generation. – Lingonberry

Answer 4

I met the same trouble, at last, so you just need to add [DataContract]和[DataMember] to the model.

Bacciform

This answer was automatically flagged as low-quality because of its length and content. Brevity is acceptable, but fuller explanations are better. – Gyration