Alright, so say I have my service contract interface as below:
Say I decided to add another interface with a similar add “feature”.
My class implementing the ILearnWcfServiceExtend ends up as:
Now when I consume this service and look at the proxy that gets generated, here’s what I see:
Only the ILearnWcfServiceExtend gets ‘listed’ in the proxy class and not the (base interface) ILearnWcfService interface.
But then to uniquely identify the operations that the service exposes, the Action and ReplyAction properties are set. So in the above example, the AddInt operation has the Action property set to ‘http://tempuri.org/ILearnWcfService/AddInt’ and the AddDouble operation has the Action property of ‘http://tempuri.org/ILearnWcfServiceExtend/AddDouble’. Similarly the ReplyAction properties are set corresponding to the namespace that they’re declared in.
The ‘http://tempuri.org’ is chosen as the default namespace, since the Namespace property on the ServiceContract is not defined.
The other thing is the service contract itself – the Add() method. You’ll see that in both interfaces, the method names are the same. As you might know, this is not allowed in WSDL-based environments, even though the arguments are of different types. This is allowed only if the Name attribute of the ServiceContract is set (as done above).
This causes a change in the name of the service contract itself in the proxy class. See that their names are changed to AddInt / AddDouble respectively.
Lesson learned: The interface hierarchy gets ‘flattened’ when the WCF service proxy class gets generated.