Why do WCF clients depend on the app.config file?

Like a lot of things, I'm sure there's a good reason for this, so please help me understand...

Why, by default, do WCF services store settings in app.config?

This has been so frustrating trying to work with multiple Silverlight class libraries. These class libraries are supposed to 开发者_如何学Pythonbe completely independent from each other, and this dependency on the app.config seems to cause the following headaches:

1. Single Responsibility Principle - I should be able to add a reference to a class library and go. If that class library uses a service reference, this idea is shot before I even start coding against it.
2. Muddy Configuration - To get other libraries to work, I have to copy and paste the service configurations into the "main" application configs. If an endpoint changes in any way, I can't just worry about a new version of that class DLL - I have to worry about anything that uses it, too.
3. Complex Alternatives - Programmatically creating the endpoint isn't pretty. Period.

There has to be a better way. Why doesn't WCF at least separate the service configurations into a ServiceName.config or something that gets copied to an output directory. What am I missing? How do you deal with this?

Because the alternatives aren't pretty either. The problem with "ServiceName.config" is that ServiceName also needs to be configurable.

The root problem is having Service references in libraries to start with. And a library component cannot dictate a binding for an App. So your SRP argument does not hold.

I concur with @Henk - library assemblies shouldn't have WCF references. If for some reason it does require one, i would use dependency injection, and pass the service reference in to the library function - this is vitally important for maximum testing benefit.

I also don't buy your argument of "Programmatically creating the endpoint isn't pretty". Creating and assigning an end point is just a couple of lines of code, and is a technique i use almost exclusively with my Silverlight components (e.g. if no address is specified within the ServiceReferences.ClientConfig file then i fall back to known service locations within the hosting application, in which case those endpoints are programmatically created).

Basically, if you don't mind the couple of lines of code required to programmatically create an end point, then you can store your address details anywhere, in any config file. You only need to store the addresses in the app.config if you are going for a purely declarative approach.