Why is XmlSerializer so hard to use?

Question

I imagine to use XML serialization like this:

class Foo {
    public Foo (string name) {
        Name1 = name;
        Name2 = name;
    }

    [XmlInclude]
    public string Name1 { get; private set; }

    [XmlInclude]
    private string Name2;
}

StreamWriter wr = new StreamWriter("path.xml");
new XmlSerializer<Foo>().Serialize (wr, new Foo ("me"));

Edit: I know this code is wrong. It was just to display how I would like to use it.

But this does not work at all:

• XmlSerializer is not generic. I have to cast from and to object on (de)serialization.
• Every property has to be fully public. Why aren't we just using Reflection to access private setters?
• Private fields cannot be serialized. I'd like to decorate private fields with an attribute to have XmlSerializer include them.

Did I miss something and XmlSerializer is actually offering the described possibilities? Are there alternate serializers to XML that handle these cases more sophisticatedly?

If not: We're in 2010 after all, and .NET has been around for many years. XML serialization is often used, totally standard and should be really easy to perform. Or is my understanding possibly wrong and XML serialization ought not to expose the described features for a good reason?

Edit: Legacy is not a good reason imo. Listwas nongeneric at first, too.

(Feel free to adjust caption or tags. If this should be CW, please just drop a note.)

Answer 1

1: legacy. XML Serializer predates generics. It as in with .NET 1.0.

2: Design decision. XML serializer is supposed to work with very limtied rights, compared to other solutions.

3: same as 2.

You can use WCF DataContract serializer in parts.

Your assumption is "limited wrong". XML serialization is supposedly for transfer documents, which - in my projects - are always separate classes doing nothing more. As such, I have no problem with all the limitations.

Answer 2

See XmlSerializer class. You'll see you're using it wrong. XmlInclude has a totally different purpose.

You're right. The XML Serializer has been around since .NET 1.0. That's before we had generics, BTW, so it's unlikely to support them.

Also, better technologies have arrived since then:

• The DataContractSerializer is faster, and supports serializing as binary
• LINQ to XML can be used in many serialization scenarios, and is much more flexible

The XML Serializer is unlikely to be enhanced in the future. I recommend you learn the other alternatives.

Answer 3

You don't need the [XmlInclude] Like you have it. You can use [XmlElement] [XmlAttribute] ... To describe the way the class is serialized.

Take out the [XmlInclude] and see if that works.

class Foo { 
    public Foo (string name) { 
        Name1 = name; 
        Name2 = name; 
    } 

    [XmlAttribute] 
    public string Name1 { get; set; } 

    [XmlAttribute] 
    public string Name2; 
} 

Foo myFoo = new Foo("FirstName", "LastName");
StreamWriter wr = new StreamWriter("path.xml"); 
XmlSerializer serializer = new XmlSerializer(typeof(Foo));
serializer.Serialize(wr,  myFoo);

Updated, the serialized properties should be public.

Answer 4

First the fixed code, then the answers to your questions:

public class Foo {
    public Foo() : this("") {}
    public Foo (string name) {
        Name1 = name;
        Name2 = name;
    }
    // note only this will be serialized
    public string Name1 { get; private set; }
    // this won't
    private string Name2;
}

or in 3.0:

[DataContract]
class Foo {
    public Foo (string name) {
        Name1 = name;
        Name2 = name;
    }
    [DataMember]
    public string Name1 { get; private set; }
    [DataMember]
    private string Name2;
}

(and use DataContractSerializer instead of XmlSerializer)

XmlSerializer is not generic. I have to cast from and to object on (de)serialization.

That is common for serializers. I have my own serializer, and initially I did make it fully generic. And it turned out to be a big design mistake. Huge. No, seriously. I'm currently in the process of re-writing every line of code to switch it out.

Simply; serializers generally involve some level of reflection (either for code-gen or for the actual work, depending on the implementation). Reflection and generics don't play nicely, especially on some of the frameworks like WCF. Having your code do the final cast is a fair compromise. I have a number of blog entries on this if you really want...

Every property has to be fully public.

That is indeed a limitation of XmlSerializer (although a list/colletion without a setter is fine, it will throw if you have a public get and private set). Also, the type needs to be public and have a parameterless constructor.

Why aren't we just using Reflection to access private setters?

For performance, XmlSerializer builds an assembly on the fly to do what you want. It doesn't have automatic access to your code's internals. For info, I'm doing something similar but I offer 2 levels of generation; fully static (into a deployable dll), which then only works with public members, or in-memory, which can still access private members. I guess they wanted to settle on only 1 model, which makes sense - and they needed "sgen", which dictates the first model.

Private fields cannot be serialized. I'd like to decorate private fields with an attribute to have XmlSerializer include them.

Then use DataContractSerializer, which will serialize any member (including private) marked [DataMember].

Answer 5

By the way DataContract never supports binary serialization , it serializes to xml but supports binary encoding.