views:

5188

answers:

4

DataContractSerializer requires classes and members to be marked with the DataContract and DataMember attributes. However, in my case the classes are auto-generated with the EFPocoAdapater framework and these attributes are not present.

How can I force serialization of all members using the DataContractSerializer without these attributes being present?

From Alexdej:

This changed in 3.5SP1, hope you saw that: http://www.pluralsight.com/community/blogs/aaron/archive/2008/05/13/50934.aspx

+3  A: 

You cannot - plain and simple. The attribute are needed for the DataContractSerializer to pick up which elements to serialize. In contract to the XmlSerializer, which basically just serializes everything (unless you explicitly tell it to ignore it), the DataContractSerializer is "opt-in" - you have to explicitly tell it (by means of the attributes) which fields and/or properties to serialize.

UPDATE: As several folks have pointed out, with .NET 3.5 SP1, Microsoft loosened those rules up a bit - any public read/write property will be serialized automatically by the DataContractSerializer. At the same time, your class also needs to have a parameterless default constructor - sounds like the exact requirements we had for XmlSerializer way back when....

Of course, this:

  • doesn't allow you to serialize something private - if you want to serialize it, you have to expose it as public read/write property
  • doesn't allow you to specify a defined chosen ordering of the parameters - it will just use them in the order they appear in the class
  • now requires you to have a parameterless constructor in your class again for deserialization

I still think these thing ought to be explicit and clear, making those no longer required opens up the path for lazy/sloppy programming - I don't like it. But if you want to, you can use it now without explicitly marking your properties with [DataMember].....

Marc

marc_s
I was really hoping you'd be wrong but after much googling I'm afraid you're right. Can't use XmlSerializer (circular reference problem working with the Entity Framework). Ah well, anonymous classes it is.
aleemb
Well, I was reading up a bit more on this today, and here I found that if your classes used by the DataContractSerializer are marked with [Serializable], then by default they will be serialized much like the old-style SOAP formatter - EVERY single field regardless of visibility is included. Could that be of help to you maybe?
marc_s
Well not really because my problem really is that I can't touch the auto-generated classes and I need to be able to externally ignore fields. I am using projections in my linq queries to get around this now which works fine.
aleemb
This answer is no longer correct (see alexdej's answer). Since it is accepted, it should probably be edited to reflect the changes in 3.5SP1.
NotDan
@Notdan: I still think it's better practice to have these things EXPLICITLY and CLEARLY in your code. But you're right - with 3.5 SP1 it's no longer required..... (welcome sloppy programming!)
marc_s
A: 

I believe it is possible. If you implement the ISerializable interface then the serializer users your implementation instead of the attributes. Although I think you will still have to mark the class [Serializable].

Its a little more work than adding attributes but it does work.

Jon Mitchell
+4  A: 

This changed in 3.5SP1, hope you saw that: http://www.pluralsight.com/community/blogs/aaron/archive/2008/05/13/50934.aspx

alexdej
awesome! have shifted to other projects since but this feature is a blessing... especially for with the Entity Framework which has circular graphs and the other serializers can get problematic.
aleemb
A: 

Just mark the class with the [Serializable] attribute. Any members you don't want serialized mark with [NonSerialized]. Note that [Serializable] causes all fields to be serialized by default, where [DataContract] serialized no fields by default except those marked with [DataMember].

ahzz