3

first of all this is not duplicate. I have a little bit different question.

Is it good practice to get rid of WCF's config in App.config file in the client (or clients in case of cross-platform project) and replace it with injected Proxy class (from different dll, shared for all clients)?

I'm just starting so my config file is not big, but here is an example:

App.config (WCF part):

<system.serviceModel>
  <client>
    <endpoint address="net.tcp://localhost:8002/MyService"
              binding="netTcpBinding"
              contract="CallbackExample.Client.IMyService" />
  </client>
</system.serviceModel>

I must have this code copy and pasted into every client I made. Working with Xamarin I can have many clients written in C# in single VS solution. So I though, why not just get rid of system.serviceModel section and do that:

MyServiceProxy.cs:

public class MyServiceProxy : ClientBase<IMyService>, IMyService
{
    public MyServiceProxy()
        : base(new NetTcpBinding(), new EndpointAddress("net.tcp://localhost:8002/MyService"))
    {
    }

    public int JustAMethod()
    {
        return Channel.JustAMethod();
    }
}

This way, I will have my configuration in single place.

So, my question is: Is it considered as a good practice? Is there a better way? I'm not sure, cause WCF is all about flexibility and easy config through App.config flie.

Community
  • 1
  • 1
Tom
  • 47
  • 7

2 Answers2

1

If there is no need for additional configuration, I always go for pure code solutions.

Back in the day WCF was slightly more complex to configure, via app.conf. With the ServiceHost you can even configure a WCF service in pure code.

The same applies to a WCF client imo; if you don't have the need to configure it via a config file for your users: I'd say go for the pure code solution.

Here another discussion of the same topic. (kind of the same reasoning, the question remains; do you need the configuration flexibility).

Community
  • 1
  • 1
bas
  • 13,550
  • 20
  • 69
  • 146
  • Thanks, Can you give me an example when I do the need to configure it via a config? When using App.config is better? – Tom Dec 05 '15 at 13:02
  • @Tom, see the related SO topic. I just wrote a WCF client/service for a zwave controller solution. There I don't have any requirements for users to change ports and stuff. The just need to use my whole software stack as is on a dedicated device. I guess these kind of requirements matter for your decision. If you plan to distribute your client/service app then it makes sense to let your users decide which port the open – bas Dec 05 '15 at 13:04
1

One potential downside to doing everything in code is that you lose the flexibility to configure not just the endpoint, but also the binding, without recompiling and redeploying. The binding includes some important network-related attributes (timeouts, transport protection levels, authorization schemes, etc) that you may want to tweak depending on the environment in which some of your client programs can run.

Note that you don't necessarily have to have a separate *.exe.config file for every client application. You can have a common .config file that each application can load explicitly. See ConfigurationManager.OpenMappedExeConfiguration

lesscode
  • 6,221
  • 30
  • 58