Creating Proxy at runtime for WCF Service

Here i am going to explain creating proxies at runtime for WCF Service. So basically we use to generate proxies using Add Service Reference and then giving the Url of the WCF service then generate proxy files at client side. Ok, what if something gets changed at service? Do we need to regenerate the proxy files? Yes of course, we have to. How to over come such limitation? Here comes WCF handy in creating proxies at runtime. So we need not to create proxy using Add Service Reference option.

Actually speaking we are not going to create proxy at runtime, we are just invoking calls to WCF service using ChannelFactory class which is available under System.ServiceModel namespace. But to achieve this we need to expose the Interface(which define the service and operation) to the client. This option is more suitable if both the service and client is in your control. Ok lets start implementing the same. I ll create an small calculator service.

Define an Service Contract and Operation Contract. Create an separate class library so that it can be exposed to client.

namespace CalculatorServiceContract



  public interface ICalculator



    int Add (int a, int b);



Next step is to implement the Interface in a class. Add reference to the CalculatorServiceContract dll in the Service class project. And implement as follows

namespace CalculatorService
    // Implementation of CalculatorServiceContract
    public class CalculatorService : ICalculator
        public int Add(int a, int b)
            return a + b;

Next step is to configure web.config at service.


          <!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
          <serviceMetadata httpGetEnabled="true"/>
          <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
          <serviceDebug includeExceptionDetailInFaults="false"/>

        <binding name="basicHttpBinding_AtServer"/>
      <service name="CalculatorService">
        <endpoint address="http://localhost/CalculatorSample/CalculatorService.svc"
                  binding="basicHttpBinding" bindingConfiguration="basicHttpBinding_AtServer"

    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />

Once done with the above steps, build the project and host in IIS. You can also use Visual Studio built-in web server by doing appropriate changes to web.config. For better flexibility i am using IIS.

Next is to create client project.

Create a Client project. It can be ASP.NET or Windows app or even console app. After creating new project try adding reference to CalculatorServiceContract dll. By doing this you are exposing the definition of service and operation to client. Also add reference to System.ServiceModel.

Configure the web.config(in case of ASP.NET app) or app.config(Windows app or console app).

      <endpoint binding="basicHttpBinding"
                contract="CalculatorServiceContract .ICalculator"

Then try to invoke the Service calls using ChannelFactory class. ChannelFactory class is used to create endpoint listener. You can also have multiple endpoint listeners by creating channels  of same instance multiple times but with different endpoint configuration. Below is the code for the same.

public static void main(string args[])
/*Create a ChannelFactory instance of type ICalculator.
You need to create an channel by specifying the binding
name which is defined at web.config in client project
which is shown above. So the the below code will
create an endpoint listener*/
ICalculator calc = new ChannelFactory<ICalculator>("basicHttpBind").CreateChannel();
 int A = calc.Add(12, 15);

Here ChannelFactory will be invoking the service calls by using the endpoint binding information. Endpoint can be of any type. If you want to use netTcpBinding, then appropriate changes need to be done in web.config(server) and web.config(client).

The main advantage of following the above method is whenever any changes is done at service methods, client need not to worry about it. But if any endpoint configuration changes happen in service then appropriate changes has to be done to config file at client because service calls happens only through the endpoint configurations.