Programmically configuration of endpoints vs. web/app.config

Question

Has any put much thought into this? Personally, I think managing endpoints in configuration files are a pain. Are there any pros/cons to doing one over the other?

Answer 1

Only points in favour of configuration files from me.

Managing endpoints in configuration files mean that you don't have to update your application if (or perhaps I should say when) the endpoints change.

You can also have several instances of the application running with different endpoints.

Answer 2

Offhand, an endpoint in a config file doesn't need to be recompiled when it's changed. This also means that you just need to update your config file when moving an application from Development to UAT to Production.

If your just coding something for your own use at home, then there's no real difference. However in a business environment, having the enpoint defined in your config file saves all sorts of headaches.

Answer 3

It's just a question of how much flexibility you need. Usually I prefer the config file approach.

Answer 4

When using an app.config, your application does not need to be recompiled to adjust to a change. Also it can be resused in multiple situations with the exact same code. Finally, hardcoding your endpoints (or anything subject to change) is poor coding practice. Don't fear the configuration file, it's declarative programming. You say, "I want to use this endpoint." and it does the work for you.

Answer 5

I tend to like the config approach myself too, other than the config file can get pretty big.

The one thing I have noticed with WCF configuration is that there is a lot of stuff that you can do from code that you can't do in XML config without adding your own custom extensions. In other words, doing config in code will allow more flexibility, of course you could also just code your own extensions and use those from configuration.

However, do note that there is what I would consider a 'bug' in Visual Studio that if you start making your own extensions and including them in XML, then VS won't like your config file any more and will tag them as errors, and then if you try to add a new service through the wizards, it will fail to add the endpoint to the configuration.

---

This is sort of a followup to my own answer:

After months of having everything in xml configuration, I'm changing everything to construct the endpoints and bindings in code. I found a really good case for having it in code;

When you want to have a deployable / sharable .dll that contains WCF clients.

So for example if you have a CommonClients.dll that contains all your WCF interfaces and contracts to communicate with some remote server, then you don't want to also say "here is 100 lines of xml that you also have to drop into your app.config for every client to make it work". Having it all constructed in code works out much better in this case.

There is also a "feature" of .NET 3.5 where if you have some wcf extensions, you have to specify the fully qualified assembly name. This means that if your assembly containing the extensions changes the version nnumber, you have to go change the assembly name in the config file too. It is supposedly fixed in .NET 4 to use a short assembly name and not require the full name.

Answer 6

I generally do programmatic configuration, as I don't want to expose my applications internal structure the the user. The only thing I keep configurable is service address, but even this I keep in userSettings section, not system.ServiceModel.

Answer 7

I prefer and recommend the configuration file approach. It offeres a lot of flexibility by allowing to make change to your server without the need to recompile the applcation. If you need security, you can encrypt the config file.

The biggest worry with plain config files could be that it can be accidentally (or on purpose) modified by the end user causing your app to crash. To overcome this you could make some tests in code to check the configuration is ok in the config file and if not, initialize it programatically to some defaults. I presented how you could do that in another answer to this question.