Hierarchy flattening of interfaces in WCF

Alright, so say I have my service contract interface as below:

   1: [ServiceContract]

   2: public interface ILearnWcfService

   3: {

   4:     [OperationContract(Name = "AddInt")]

   5:     int Add(int arg1, int arg2);

   6: }

Say I decided to add another interface with a similar add “feature”.

   1: [ServiceContract]

   2: public interface ILearnWcfServiceExtend : ILearnWcfService

   3: {

   4:     [OperationContract(Name = "AddDouble")]

   5:     double Add(double arg1, double arg2);

   6: }

My class implementing the ILearnWcfServiceExtend ends up as:

   1: public class LearnWcfService : ILearnWcfServiceExtend

   2: {

   3:     public int Add(int arg1, int arg2)

   4:     {

   5:         return arg1 + arg2;

   6:     }

   7:  

   8:     public double Add(double arg1, double arg2)

   9:     {

  10:         return arg1 + arg2;

  11:     }

  12: }

Now when I consume this service and look at the proxy that gets generated, here’s what I see:

   1: public interface ILearnWcfServiceExtend 

   2: {

   3:     [System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/ILearnWcfService/AddInt", ReplyAction="http://tempuri.org/ILearnWcfService/AddIntResponse")]

   4:     int AddInt(int arg1, int arg2);

   5:         

   6:     [System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/ILearnWcfServiceExtend/AddDouble", ReplyAction="http://tempuri.org/ILearnWcfServiceExtend/AddDoubleResponse")]

   7:     double AddDouble(double arg1, double arg2);

   8: }

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.