Let me start out by saying that I'm aware that the way a class library is supposed to get its configuration is from the referencing project's configuration. In my case, the referencing project is an MVC web application.
Whilst this usually makes sense, I don't think it does when your class library is there just to provide access to a web service. Visual Studio has a feature when you right-click on the service reference to "Update Service Reference". This will update the app.config file in the class library, not the configuration file in the referencing project. Not very useful if the app.config file is just going to be ignored.
Of course, you can keep copying the new versions of the app.config file over to (in this instance) your web.config file in a different project, but it's a pain, and you have to keep remembering to do it. Whatsmore, I think it's semantically better to keep the config settings in the web service project. If that web service changed URLs, I'd want all things referencing the project to get the new URL. If something referencing the class library wanted to use a different URL, its configuration could override the class library's, but I'd still like the class library to have a default bunch of settings. I wouldn't want to have to change each referencing project's configuration.
With all that in mind, is there a way to force/hack/whatever .NET into using a configuration in a class library for WCF endpoints, etc., instead of looking at the values in the referencing project's configuration?
Basically, it is possible to have an app.config for a class library by doing a lot of work, like manually copying the app.config file to the bin directory when the project is built in a post-build event, and manually reading values from it and plugging them into your web service bindings. However I've decided to just give in and copy them over to my web.config file (in this instance, because I'm writing a web application), then manually updating them every time I refresh the web service from Visual Studio. I do still think it would be legitimate to do this if you actually had several different applications accessing a shared library, because you might want that library to just reference one web service and if it changed you'd only have to change that library's .config file instead of all the different applications' .config files.
It's a mystery to me as to why VS creates a file called app.config because I think it's highly misleading; it makes it looks like this file's configuration settings are going to be read when in fact they are going to be ignored. A more appropriate filename would be something more like "shouldBeCopiedIntoYourActualAppOrWeb.config".