Programming WCF Services, 3rd Edition

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; } ...