<appSettings> in another file (not web.config)

[Jeff Robichaud]

Hello,

Since it is possible to put application settings in a file other than
web.config, I was wondering what is the best practice in doing so vs.
putting these settings directly in web.config. My point is that when I
deploy an application, I want to overwrite web.config all the time, because
the contents of this file has a direct impact on the application's overall
behavior. For example, the execution timeout for my app is 60 seconds, and
this is by design, this is what I've decided that fits with the
application's purpose. So I don't want anybody opening the web.config file
and deciding that it's 45 seconds, right ? If I know someone has tampered
with the web.config file, I cannot guarantee that everything is going to
behave well.

So, is it a good thing to consider two kinds of configuration settings : 1.
The global settings (like execution timeout) that are never accessed in
code; 2. The application settings, that are accessed in code. The second
kind behind held in a different file than web.config. So when you deploy you
ask no question and overwrite the existing web.config file, knowing that the
newest web.config file might contain some information that you really want
to have because it is intrinsic to the application's design. The app
settings file remaining unchanged unless it has to be updated.

I don't know if this is clear enough but hey it's friday...

Thanks for anyone trying an answer...!!

 

[DalePres]

My experience has been that most times when you try to do something outside
the norm, the design, or the standard, you will regret it and either go back
and change it or wish you could go back and change it. You should use the
web.config file for changeable application settings. If the settings get
changed to invalid or unsupportable values, just validate them in code when
retrieving the values or handle the errors.

If you put your settings in a different file, you will still have the risk
of them being modified outside acceptable parameters so you haven't solved
anything and you have added a coding and maintenance headache that will
outweigh any benefit.

For settings that you don't want changed, such as the execution timeout you
mention in your post, just hard code them - though generally you'll wish you
hadn't done that later as well.

I think the best solution is to use the configuration files as intended,
including machine.config and web.config at various levels of your
application and to protect those files from modification by setting
appropriate permissions and policies.

Just my humble opinion,

DalePres
MCAD, MCDBA, MCSE

 

[jongalloway]

We've use this approach at my work for over a year and it's worked
well. The benefit is that you can version your settings for each
environment. I respectfully disagree with Dale - putting app settings
in a separate file is supported in web.config:
<appSettings file="config\prod.config" />

This allows you to put your application specific settings into separate
files within a config folder - dev.config, qa.config, and prod.config
for example. You can check the current version of all your config files
into VSS or whatever source control system you use. Then your
web.config should be as close as possible between all environments
(although system.web settings usually prevent them from being exact
copies).

One thing to keep in mind is that the web application will
automatically restart when web.config is updated, but will not detect
changes to referenced files like prod.config. You need to edit the
web.config (add a space or something) to update the app settings for
the application.

- Jon
http://weblogs.asp.net/jgalloway

 

[DalePres]

Interesting point. I wasn't aware of the "appSettings file =" setting. It
allows you to accomplish the same thing in separate files and provide a
cleaner and more readable solution.

DalePres