0

We've used the solution in this old topic ("WCF Service Reference generates its own contract interface, won't reuse mine"), but that only solves the problem of reusing interfaces. What we would like to do, if possible, is to also retain the use of config files to setup and configure various options on WCF client side using all the bells and whistles of <system.serviceModel> node.

The approach that was given forces us to do all that in code, and that already proved to be a problem at one point (we had to change a binding configuration parameter which forced us to go through an entire corporate change request approval process to alter two lines in the code base, which is a huge hassle compared to a request to change config file).

Is there a solution that combines these two worlds?

Community
  • 1
  • 1
mmix
  • 6,057
  • 3
  • 39
  • 65

2 Answers2

1

Lets say you have IService as your service contract and it is shared between the client and the server.

Then in client code you would have something like this:

ChannelFactory<IService> factory = new ChannelFactory<IService>("ServiceClient");
var channel = factory.CreateChannel();
var result = channel.GetData(1);

In Client app.cofnig you would have a section that looks like this:

<system.serviceModel>
  <client>
    <endpoint name="ServiceClient" address="http://localhost:51377/service.svc" binding="basicHttpBinding"
            contract="Common.IService"/>
  </client>
</system.serviceModel>

Briefly explained ChannelFactory creates Channel to access IService service using ServiceClient endpoint configuration in app.config.

You can expand serviceModel configuration as you wish. Just add additional code to properly close channel once operation is complete.

Enes
  • 1,115
  • 7
  • 12
  • ah, so its actually a parameter in `ChannelFactory` constructor. Gotcha, for some reason we completely missed that one... Thanks. – mmix Aug 07 '15 at 12:30
  • 1
    Yes. But it is also an optional one. If you know that you will have only one Common.IService client in that app you can use parameterless constructor and no endpoint name in configuration. – Enes Aug 07 '15 at 12:41
0

What exactly is it that you're trying to achieve? Seems like you're trying to reuse contracts, but have SVCUTIL/VS generate the ClientBase<T>-derived class and modify the .config file?

If so, I don't think that's a supported scenario, really. Honestly, if you need to reuse your service contract interfaces, you might as well implement the ClientBase<T>-based proxy class by hand. It's only a little bit of additional work, and will make your life easier in the long run.

There isn't a supported option in SVCUTIL/VS to only import the binding configuration rather than the entire thing, though, so you'd likely need to write your config file by hand as well (or copy it from a manual run of SVCUTIL).

tomasr
  • 13,683
  • 3
  • 38
  • 30
  • No, no, we don't want to use "Add Service" or SVCUTIL, we can create/modify config files manually or through "Edit WCF Configuration" Editor. We just want to avoid configuring WCF clients through code, while still retaining the ability to use shared service contracts. – mmix Aug 06 '15 at 16:06
  • Again, I'm not understanding.... using shared service contracts doesn't exclude using configuring your proxies through config. Why do you feel that isn't the case? – tomasr Aug 06 '15 at 16:51
  • Ok, good news, but how? I can't seem to wrap my head around it. In the SO question I linked, what do I need to do/change in that code to load complete binding from config and get an interface instance I can use? – mmix Aug 06 '15 at 17:19