Why would one use the ChannelFactory to instantiate a WCF proxy rather than a Service Reference?

Question

There seem to be two ways to instantiate WCF service proxies described here. My question is why would one want to use the ChannelFactory to instantiate a WCF proxy and what

Answer 1

The first option uses configuration settings provided in the web.config / app.config files to instantiate a proxy, however in certain situations its not feasible to put these settings in that file, for example if your application needs to use a different binding (maybe HTTP vs Named Pipes) depending on the scenario, or possibly your application may not even have a .config file.

The second option gives a lot more flexibility when creating proxies to programatically specify the configuration to use for each proxy as you instantiate it.

---

To give a more concrete example, supposing you wish to use Named Pipes for communication if communicating with the local machine, and HTTP if communicating with a remote host:

if (UseNamedPipes())
{
    EndpointAddress address = new EndpointAddress("net.pipe://localhost/Simple/BankService");
    return ChannelFactory<IBank>.CreateChannel(new NetNamedPipeBinding(), address);
}
else
{
    EndpointAddress address = new EndpointAddress("http://localhost:8000/Simple/BankService");
    return ChannelFactory<IBank>.CreateChannel(new BasicHttpBinding(), address);
}

Answer 2

One of the specific cases would while developing any office add-in or visual studio add-in projects where you don't have the app.config file.

Also , lets say in an organisation where you want to standardise on certain bindings and certain endpoint security patterns. you would want to create an API which developers can easily use to create a proxy, in this case you would encapsulate all the binding information using channelfactory.

Answer 3

If you are using assembly-sharing (which is, let's face it, hugely convenient if you own both ends of the pipe), then both ends already have a complete version if the interface etc. It seems redundant to run the svcutil tool (at command-prompt or via the IDE) just to get back a wrapper for what we already have. It also works very well when you want to code only to an interface, not to the wrapper class - and use some centralised code to get a channel to a particular interface at a given address. This is actually how I mainly use WCF.

The "client" approach works well for one-off services, or where it doesn't need to go through any central tooling. It also makes for very simple demos.