Does adding a method to a WCF ServiceContract break existing clients?

Question

We have an existing ServiceContract

[ServiceContract(Namespace = "http://somesite.com/ConversationService")]
public interface IConversationService
{
        [OperationContract(IsOneWay = true)]
        void ProcessMessage(Message message);

        [OperationContract(IsOneWay = true)]
        void ProcessMessageResult(MessageResult result);
}

and we need to add a method to it

[ServiceContract(Namespace = "http://somesite.com/ConversationService")]
public interface IConversationService
{
        [OperationContract(IsOneWay = true)]
        void ProcessMessage(Message message);

        [OperationContract(IsOneWay = true)]
        void ProcessMessageResult(MessageResult result);

        [OperationContract(IsOneWay = true)]
        void ProcessBlastMessage(BlastMessage blastMessage);
}

Will this break any existing wcf clients that are using this service? Or will we have to update all existing wcf clients?

EDIT: This service is using both netTcpBinding and netMsmqBinding

Answer 1

I just tested this with a WCF client Windows app (UWP) and it continued to work after updating the WCF service application. So no: as previously answered, your clients will not break when you add a method.

I thought it was worth mentioning, however, how easy it is to update your service clients with Visual Studio 2015:

1. Make sure your WFC service is running.

2. Simply go to the Solution Explorer,

3. Expand Service References

4. Right-click on your service reference

5. Click Update Service Reference

6. If you get an error message, repeat the last step. I had to try a few times for some reason.

Answer 2

I think your existing clients will continue to work. After all this is very similar to SOAP and web services in that the client will connect to the given URL and request a specific service. If you take methods away you will risk breakage (only if the method is used I believe) but adding should be pain free.

I've only dabbled in WCF but have used the ASP.NET web services in this way to great success.

Answer 3

No, I wouldn't expect that - adding new functionality / new service methods that does NOT alter any of the existing methods / function calls will not affect "old" clients. Of course, they won't know about the new methods until their proxies have been recreated from metadata, or adapted manually.

But existing calls should be unaffected, as long as their signature (the data they exchange) stays the same.

Marc

Answer 4

I take the more extreme view on this. Why ever change anything? Instead, why not create a new contract, inheriting from the old, and adding the new operation? The new contract can be exposed in a separate endpoint in the same service.

It may be paranoia uninformed by formal proof, but it seems to me that, if it's possible to construct a client that can tell the difference, then it's possible that some client will "break" when you make the change. Consider that, when you change the service contract you're not just changing service code - you're changing the proxy code in any client that happens to update his service reference. Some, more conservative customers, might consider that a reason to re-test their client code - after all, they may well have rules that say they have to retest their code whenever any change is made to it.

The existing client will be referring to the original endpoint, so will not be affected by adding a new endpoint - no code would change if an "Update Service Reference" was performed.

Besides, why even think about it, if you don't have to?

Answer 5

In general, adding to a message in SOA solutions does not break the contract. I believe that as long as you're not using a binary protocol (net.tcp), you'll maintain backward compatibility.

I'm not sure about whether or not it will break your clients using binary bindings, though?