views:

742

answers:

2

Why does adding a web reference to a library assembly project create an app.config file for the project? it will not be used at run time, right ? - as there can only be one root config file per host process (executable), - That's why only executables get their app.configs renamed to "projectName.exe.config" and deployed to output folder during compile process.

In any event, the only thing that's in there is a applicationSettings section with one configuration setting with the url to the web service, which generally is going to be dynamically set by ops using a separate configuration setting anyway...

Also, if a host process has several dependant library assemblies with web references, what's the point? Which of the many settings (one per each dependant library assembly) would get used?

Anyway, I want to get rid of these app.configs, to avoid the exception when the configuration system cannot find the setting at runtime, but as I'm not clear on why it's there in the first place... Am I missing something ?

A: 

You answered your question already - the app.config is added because the web reference needs to store the URL to the service somewhere. It's better stored in a config file rather than hardcoded into your *.cs file, no?

If you have dependant assemblies all used from a main app, only the main app's app.config (renamed to mainapp.exe.config) will be used - the dependant assemblies will use the main app's config file. The app.config created by adding a web reference only exists as a place where you can check out what settings need to go into your main app.config.

If you have a separate place where you configure all your webservice URL's (e.g. a database table or something), you can toss out the generated app.config's - no problem there.

Marc

marc_s
+2  A: 

Mark the web reference as static (right-click reference -> properties -> URL Behavior). Then the url will be stored in the reference.cs file instead of the .config file.

When an assembly with its' own app.config is loaded into an application that has a separate .config file, I believe that it merges the .config files much the same way that the machine.config is merged with the web.config (I could be wrong on this point though).

Josh E
First of all, hardcoding an URL into a code file seems like a really really bad idea. Also, .NET assemblies do *NOT* normally (without user inventation) load their own app.config files at all.
marc_s
yes, I agree it's a bad idea, but that's what the OP asked about doing. As for it loading the config settings, anything that calls the configurationmanager.x within an assembly will probaby end up loading that assembly's app.config - this can include non-user initiated calls too!
Josh E
I don't really care where it puts it.. at runtime I won't be using it anyway, (I set the url in code based on a separate custom config section) I just don't want the runtime to be coded to "look" for a configuration section that doesn't exist, and generate an exception when it can't find it...
Charles Bretana
In my code I am using the Url property of the web service object to dynamically set the url based on my own custom configuration settings... Setting the URL Behavior property to static will not stop me from being able to do that will it ?
Charles Bretana
no it won't change how you currently do it.
Josh E