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 ?
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