Forward-Compatible Data Contracts
A feature of the Windows Communication Foundation (WCF) data contract system is that contracts can evolve over time in nonbreaking ways. That is, a client with an older version of a data contract can communicate with a service with a newer version of the same data contract, or a client with a newer version of a data contract can communicate with an older version of the same data contract. For more information, see Best Practices: Data Contract Versioning.
You can apply most of the versioning features on an as-needed basis when new versions of an existing data contract are created. However, one versioning feature, round-tripping, must be built into the type from the first version in order to work properly.
Round-tripping occurs when data passes from a new version to an old version and back to the new version of a data contract. Round-tripping guarantees that no data is lost. Enabling round-tripping makes the type forward-compatible with any future changes supported by the data contract versioning model.
To enable round-tripping for a particular type, the type must implement the IExtensibleDataObject interface. The interface contains one property, ExtensionData (returning the ExtensionDataObject type). The property stores any data from future versions of the data contract that is unknown to the current version.
The following data contract is not forward-compatible with future changes.
To make the type compatible with future changes (such as adding a new data member named "phoneNumber"), implement the IExtensibleDataObject interface.
When the WCF infrastructure encounters data that is not part of the original data contract, the data is stored in the property and preserved. It is not processed in any other way except for temporary storage. If the object is returned back to where it originated, the original (unknown) data is also returned. Therefore, the data has made a round trip to and from the originating endpoint without loss. Note, however, that if the originating endpoint required the data to be processed, that expectation is unmet, and the endpoint must somehow detect and accommodate the change.
The round-tripping feature may be turned off, either by setting ignoreExtensionDataObject to true in the DataContractSerializer constructor or by setting the IgnoreExtensionDataObject property to true on the ServiceBehaviorAttribute. When this feature is off, the deserializer will not populate the ExtensionData property, and the serializer will not emit the contents of the property.