WCF uses a serialization engine called DataContractSerializer by default, to serialize and deserialize data. If we want to add new complex data types (that will be transferred in service operations) in a WCF service, we need to define it as a DataContract type so as to make it friendly to the DataContractSerializer engine. A .NET serialization system supports backward-compatibility on custom data types naturally. However, sometimes we also need forward-compatibility for data types used in a WCF service. Suppose that you have a service that exchanges some custom data types between clients. If one side updates the custom data type (adds some fields or properties) or uses a newer version, it is important to make sure that the other side (without using the updated version of data) can still work correctly with the updated data type instances.
- Make the custom data type (we will use in our service communication) implement the
IExtensibleDataObjectinterface.[DataContract] public class FCQuestion : IExtensibleDataObject { [DataMember] public string Subject { get; set; } [DataMember] public string Answer { get; set; } public ExtensionDataObject ExtensionData { get; set; } }
- Make sure you haven't enabled the
IgnoreExtensionDataObjectproperty onServiceBehaviorAttributeapplied on your WCF service (this property is disabled by default).You can have a look at the article ServiceBehaviorAttribute.IgnoreExtensionDataObject Property for more information and is available at:
After the DataContract type implements the IExtensibleDataObject interface, an ExtensionDataObject property is added; this property plays an important role in forward-compatible serialization. WCF will use DataContractSerializer for DataContract type serialization/deserialization. When DataContractSerializer finds that a certain type (used for operation parameters or return value) has implemented the IExtensibleDataObject interface, it will store any data (this is obtained from the message stream during deserialization) that doesn't have corresponding property/fields in the type definition into the ExtensionDataObject property so that these data will not get lost. And if the deserialized instance (with some unknown data stored in ExtensionDataObject) is serialized into the message later, DataContractSerializer will write out ExtensionDataObject into the message stream again. This ensures that the data in the new version of DataContract can be consumed by the service/client with the old type definition correctly, instead of raising unexpected type, mismatching, or serialization exceptions.
The following modified data type can be consumed by the service/client that has the old definition, as explained earlier, without synchronizing the DataContract type definition:
[DataContract]
public class FCQuestion : IExtensibleDataObject
{
[DataMember]
public string Subject { get; set; }
[DataMember]
public string Answer { get; set; }
[DataMember]
public string Comment { get; set; }
public ExtensionDataObject ExtensionData
{ get; set; }
}
Currently, using the IExtensibleDataObject interface can make the DataContractSerializer preserve unknown data properties/fields when deserializing/serializing custom data types. However, the ExtensionDataObject property is an opaque object to developers and we do not have means to manually read the data stored in it. In case we want to manually extract the additional unknown property/fields, we can consider directly accessing the underlying SOAP message via MessageInspector or other extension points.
- Altering an operation message via MessageInspector in Chapter 9.
- Complete source code for this recipe can be found in the
\Chapter 1\recipe2\folder