views:

38

answers:

1

Hi,

I have an existing set of classes that use the [Serializable] attribute. I need to expose them in a WCF service and so I need them to have the [DataContract] attribute. It works with just Serializable but then the properties get funny names like ...k__BackingField.

These classes are also used elsewhere and I'm wondering whether I risk breaking anything by replacing the attribute. Also, it is possible and is it a good idea to have them both?

Thanks.

+4  A: 

When you just specify a DataContractAttribute but do not specifically attribute the members that you want included, the default behavior is to serialize all fields of the class, including private ones. So the names you are getting are because you are using automatically implemented properties, I assume.

So in other words, change the class definition to resemble the following. Note the DataMember attributes on the properties that I want serialized.

[DataContract]
public class MyClass {

    [DataMember]
    public string SomeString {
        get;
        set;
    }

    [DataMember]
    public int SomeInt {
        get;
        set;
    }

    public string DontSerializeThis {
        get;
        set;
    }

}

This will cause the DataContractSerializer to serialize the properties and not their compiler-generated backing fields. However, it does require that the properties be read/write public properties because it's going to go through these property accessors to get and set the serialized data.

The other option is to change your automatically implemented properties to "normal" properties which means adding your own backing fields. Then you can either leave all the DataMember attributes off which means they'll all be serialized, or you can add the DataMember attributes to the new fields you created which lets you rename them in the serialized output if you want.

Finally, to your point about whether it's a good idea to make a class serializable in both systems, not really. If you want the class to participate in classic serialization using something like BinaryFormatter or XmlSerializer, then you should just target that scenario since the DataContractSerializer can already serialize these classes.

If your goal is fast, efficient, .NET 3+ to .NET 3+ (or Silverlight) communication, DataContract is the way to go. If your goal is interoperability and/or control over the XML represenation, stick with the XML serialization attributes.

Josh Einstein
Thanks - I have to keep compatibility with existing code that may be using XmlSerializer so I guess my only option is to expend the automatic properties. Can you give me details on what issues might arise if I use both attributes? I would expect the XmlSerializer to ignore DataContract attributes and the other way around?
Xavier Poinas
To my knowledge, there should be no conflict with the attributes. But the two serializers have very different behavior when it comes to things like serializing references, default values, supported types, whitespace preservation, etc. And the extra attributes can junk up your class. But technically I wouldn't expect any conflict.
Josh Einstein