Effects of XmlIncludeAttribue when it's used in WCF DataContract

0
votes

1) Does Binding use while creating ChannelFactory makes any difference to how serialization/deserialization works? (I know that binding used should match the server side binding of the service.)

I am using KnownType attribute in one of my DataContract but it does not work. But if I use XmlIncludeAttribute, it works! (I am migrating my ASMX services to WCF.. But I am not using any MessageContracts since I have freedom to update client side proxies too.)

[XmlInclude(typeof(Males))] [DataContract] public abstract class Person { [DataMember] public int Name { get; set; } }

2) If I use any Attribute ( to be specific - XmlInclude)) that uses XmlSerializer for the WCF DataContract, does WCF use XmlSerializer instead of DataContractSerializer?

1
wcfinheritancedatacontractserializerxmlserializerknown-types
This question can be closed as question is too localized. The Use of binding has no effect on the serialization/de-serialization. XmlInclude uses XmlSerializer and KnownType uses DataContractSerializer. So it's not necessary to mix the two. I needed to use KnownType correctly to get rid of the problmes. – Learner

1 Answers

-1
votes

DataContractSerializer supports everything that XmlSerializer supports, but the reverse is not true. But if a type is decorated with [DataContract], it switches over completely to the new DataContract programming model, completely throwing away support for [Serializable], IXmlSerializable, etc. types that it otherwise would have had.

So your [XmlInclude] magic works only if you're using ASMX and the traditional XmlSerializer. If you're using DataContractSerializer, you have to do known types, and XML-isms like [XmlInclude] and XML attributes are simply not supported. You can still use XmlSerializer instead of DataContractSerializer if you want to, though; all you need to do is decorate the service or operation you want to switch over to XmlSerializer with [XmlSerializerFormatAttribute.]

Hope this helps!