Programming WCF Services

Versioning

Services should be decoupled as much as possible from their clients, 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 version is passed to and from an old 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 done with data contracts is adding new members on one side and sending the new contract to an old client or service. The new members will simply be ignored by DataContractSerializer when deserializing the type. As a result, both the service and the client can accept data with new members that were not part of original contract. For example, the service may be built against this data contract:

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

   [DataMember]
   public string LastName;
}

and yet the client may send it this data ...