Versioning
Services should be decoupled from their clients as much as possible, especially when it comes to versioning and technologies. Any version of the client should be able to consume any version of the service and should do so without resorting to version numbers (such as those in assemblies), because those are .NET-specific. When a service and a client share a data contract, an important objective is to allow the service and client to evolve their versions of the data contract separately. To allow such decoupling, WCF needs to enable both backward and forward compatibility, without even sharing types or version information. There are three main versioning scenarios:
New members
Missing members
Round-tripping, in which a new data contract version is passed to and from a client or service with an older version, requiring both backward and forward compatibility
By default, data contracts are version-tolerant and will silently ignore incompatibilities.
New Members
The most common change made to a data contract is adding new
members on one side and sending the new contract to an old client or
service. When deserializing the type, DataContractSerializer
will simply ignore
the new members. As a result, both the service and the client can
accept data with new members that were not part of the original
contract. For example, suppose the service is built against this data
contract:
[DataContract] struct Contact { [DataMember] public string FirstName; [DataMember] public string LastName; } ...
Get Programming WCF Services, 3rd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.