Programming WCF Services, 2nd 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 allowing 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, where 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, the service may be built against this data contract:

[DataContract]
struct Contact
{
   [DataMember]
   public string FirstName;

   [DataMember]
   public string LastName;
}

yet the ...