views:

235

answers:

2

I have a strong preference for working in code, leverage IntelliSense and opening up all of the power of the C# language to work with WCF but I want to make sure that I'm not moving in a direction that ultimately will limit the WCF feature set I can access. My experience is so limited with WCF that I don't understand the benefits of using the configuration files, especially if you can do everything in code (?).

Note: I'm using .NET 3.5.

Can you do 'everything' with WCF programmatically or are configuration files required for the full WCF feature set?

+5  A: 

You can do about 99.8% of things in code as well as config.

Some things can be done only in code - like setting user name and password on a call that requires those two for authentication.

And there appear to be a few things that can be done in config only - see this other recent SO question for one example.

But I think, if you prefer code, you should be fine for the vast majority of cases.

Marc

marc_s
Thanks, that's great to know, now I feel very comfortable moving forward with WCF using a code only approach.
CuriousCoder
+3  A: 

An overgrown comment...

Marc_s' answer and the question's perspective is good (two +1s from me).

I have no doubt that the following will not be news to either of you, but wanted to point it out in case someone encounters this and isn't aware of the cons of a purely programmatic approach.

Moving to programmatic configuration from config-file based setup means

  • you lose the ability to adjust (read: hack!) things in the field -- your only avenue of recourse will be to recompile and redeploy binaries. For many scenarios (including one of mine) this is not n.
  • you lose the ability to switch between multiple sets of configurations by juggling them in the config file.

I admit that both of the cited 'losses' are debatable - they can encourage bad habits and prevent you from reaching the most solid solution for your customers in the quickest manner possible.

UPDATE: I've implemented a mechanism where I use ChannelFactory<T> but pick up a customised config from the app.config if it's present, or provide a default if it isn't (my scenario is that I'm a guest in someone else's process and hence can't assume a config fuile is easy to update / has been updated, yet dont want to lose the option of tweaking settings after deployment)

Ruben Bartelink
You have a good point. I'd suggest using config files as much as possible.
Steven Sudit
The problem with config files is that they are hard to deploy. Telling your end users to edit their config files is one way to lose your hair and customers. The programmatic way lets the application figure it out for them.
Joel Rodgers
@Joel Rodgers: While that's not untrue, it's much harder to adjust a .exe file than a .config file. But the general point that you dont want to have people making changes to config files as a matter of course is well made.
Ruben Bartelink