Making Backward-Compatible WCF Services

Question

TLDR: How do I create WCF services that are backward compatible -- that is, when I deploy a new version of the service on the server-side, all the clients on the older versions can still use the service.

---

I'm creating a web service that will allow the client applications to fetch a listing of plugins. I will at least have one operation like FindPlugins(string nameOrDescription) which will, on the server, do a search and return a list of objects.

Unfortunately, I cannot guarantee that my clients will all be updated with each new release of my service; nay, I am sure that many of them will be trailing the latest version, and will have old versions -- how old, I cannot be sure, but I know they will be old :)

If I create a new service operation, change the schema, or make some sort of breaking operation on the server side, I'm done. I need to engineer backward compatibility at all times.

Here's one example. Say I return a list of Plugins, each which has a name and description, and I deploy v0.1 of my service. Then, I add a download link, and deploy that as v0.2 of my service.

---

Some options which I see are:

• Force clients to update to the latest service (not feasible)
• Break the service for old clients (not feasible)
• Append a version number to each operation and only consume the version-specific operations (eg. FindPluginsV1, FindPluginsV2) -- doesn't seem practical with multiple operations
• Provide a new service with each new version -- doesn't seem practical

Answer 1

WCF is backwards-compatible by default.

The following MSDN link contains a list of all the possible changes of a WCF contract and describes their effect on old clients:

• WCF Essentials: Versioning Strategies

Most importantly, the following operations will not cause old clients to break:

Service contracts (methods)

• Adding method parameters: The default value will be used when called from old clients.
• Removing methods parameters: The values sent by old clients will be ignored silently.
• Adding new methods: Obviously, old clients won't call them, since they don't know them.

Data contracts (custom classes for passing data)

• Adding non-required properties.
• Removing non-required properties.

Thus, unless you mark the new DownloadLink field as IsRequired (default is false), your change should be fine.