I was curious if someone could outline which types of WCF contract (interface) changes on the server side would break a client trying to send in a message, and why. I believe W
Check out this article on dasBlonde: Versioning WCF Service Contracts
It lists what changes will break existing clients:
This article by Michele explains in more detail how you can design contracts to be more flexible.
OK. Question. Due to wrong naming syntax (parameter is specified with capital letter), I would like to adjust some code:
[OperationContract]
public void Foo(string Bar){}
to
[OperationContract]
public void Foo(string bar){}
Would adjusting the capital break contract?
Design recommendations for contracts
First version
1.1. Carefully choose names for all contracts (interfaces, methods, classes and properties). These will be hard to change in future versions.
1.2. Remember, that following cannot be changed in future: number of method parameters;type of parameters/return values/properties for types not under your control.
Next version
2.1. If already exists, do NOT change Namespace or Name parameter on any xxxContractAttribute.
2.2. If already exists, do NOT change Order property of the DataMemberAttribute.
2.3. Only following changes are allowed:
Add method (OperationContract) to interface (ServiceContract)
Rename method on interface
Rename class (DataContract)
Add property (DataMember) to class (DataContract)
Rename property on class
2.4. Any deletion breaks compatibility.
2.5. Any other change breaks compatibility.
Here are few useful links:
"Add/remove parameters from an OperationContract" in WCF is not always something that can break your client, but you have to know what you do. In particular, adding new parameters to an operation contract will cause legacy clients not to pass them, and on the service side they will be set with their default values. Moreover, removing parameters from an operation contract, will be silent from the client point of view, and they will be simply ignored on the service side. Of course, changing parameter's name/type will cause the client to break.
I think the best practice is to think of contracts as unbreakable, hmmm, contracts. Don't change them once they're published. It's easy enough to create a new contract with the changes you want, and to expose the new contract on a new endpoint.