-1

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?

Jez
  • 27,951
  • 32
  • 136
  • 233
  • 1
    Flaw in your question: "That web service isn't going to change URLs"; in internal/corporate environments this is absolutely not true. Also, it's *very* possible in these environments that one application would point to one endpoint, while another would point to a *different* endpoint. Assuming that all applications are always going to go the *same* URL is *fundamentally wrong*. – casperOne Mar 13 '13 at 17:08
  • That said, just configure the endpoint/bindings in code, and pull the values from your extra config file. This is more of a "how do I read values from a file and assign those values to a binding I create in code" question. – casperOne Mar 13 '13 at 17:10
  • @casperOne OK, so I've changed the question a bit to reflect that the referencing code might want to *override* the 'defaults' in the class library, but otherwise it would default to what was there. – Jez Mar 13 '13 at 17:11
  • You'd simply have to create the bindings manually then, taking the values from your config file. There's no magic in doing this. – casperOne Mar 13 '13 at 17:12
  • 1
    To whoever voted to close: how on earth is this too localized? It applies to anyone wanting a standard configuration for a web service project. – Jez Mar 13 '13 at 17:18

2 Answers2

0

Sorry, this isn't how it works.

The location of your service, and other parameters, can change from one environment to the next. Those changes must be reflected in the web.config of the environment.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • They *can*, but in some situations, they may stay the same for all referencing code and it's a lot more convenient to store the settings in the class library itself. Why not have an 'override' mechanism where the referencing code can override the default settings in the class library, but yet the class library can be changed to change the default settings? – Jez Mar 13 '13 at 17:13
  • 1
    Why not? Because that's just not how .NET works. It has never worked that way, and this issue is not specific to WCF. – John Saunders Mar 13 '13 at 17:15
  • And I'm asking for a way to get round the default .NET behaviour and providing a rationale for doing so. "It's always been this way" is a bit of a non-argument from tradition. It looks like manually creating bindings might be a decent solution to the problem. A bool could be passed into the class to tell it whether to manually create the bindings and use the class library's `app.config`, or use the referencing code's configuration. – Jez Mar 13 '13 at 17:18
  • Where will you store the class library's app.config? – John Saunders Mar 13 '13 at 17:22
  • In something like `ClassLibrary.dll.config`? – Jez Mar 13 '13 at 18:23
  • At what location in the file system? – John Saunders Mar 13 '13 at 18:34
  • Probably in a shared libraries folder. – Jez Mar 13 '13 at 20:34
  • 1
    Well, you go figure that out. I assume you've got only one library for the service, and that all instances of the service will always use the same configuration and that all consumers of the service will use the same configuration, and that, when it's necessary to change the configuration, you will have documented the location so that someone can find the config file and be certain they're changing the correct file. Or you could stop being unique and do what everyone else does, and what your users will _expect_ to do. – John Saunders Mar 13 '13 at 20:36
  • Why does VS, when updating the service reference, create a file called `app.config` that looks for all the world like an app configuration file when its contents are meant to be copied to a real configuration file? For the avoidance of confusion, shouldn't it generate a file called something like `ServiceConfig.xml` instead, and have a comment at the top saying that this should be copied into the referencing code's config file? – Jez Mar 13 '13 at 22:15
  • As I said before, it has been that way for over a decade. – John Saunders Mar 13 '13 at 22:15
  • That doesn't explain why they initially thought that filename was a good idea. – Jez Mar 13 '13 at 22:16
  • Go ask them. That's the only way to get the question answered. – John Saunders Mar 13 '13 at 22:18
0

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".

Jez
  • 27,951
  • 32
  • 136
  • 233