0

I've heard it's a good idea to be able to change config values in a production environment without recycling the app pool.

However, changing would touch the web.config and cause this *anyway.*

Is there any loss of flexibility or decrease in robustness by storing appSettings programmatically if an app pool recycle can't be avoided?

e.g in Pseudo code:

Application_Start() {
  AppSettingHelper.EmailOnException = ConfigurationManager.AppSettings[key];
}

then later, I use: AppSettingHelper.EmailOnException

williamsandonz
  • 15,864
  • 23
  • 100
  • 186

1 Answers1

3

Web.config is meant to be used in design time only. If your application changes it's settings in run time, you should really consider storing these settings somewhere else, like in the database.

Changing the web.config file will cause the application to recompile and you will lose all your static variable values and other things. This will also cause a temporary delay for the users. You will also have to manage concurrent updates to the file.

When you change the web.config file you are, in a certain way, changing the application source code.

Take a look at this thread for possibilities to store user settings: What is the best way to store user settings for a .NET application?.

Community
  • 1
  • 1
Andre Pena
  • 56,650
  • 48
  • 196
  • 243
  • Thanks for the reply. I'm using an environment file watcher/swapper system for keeping that stuff outside source control. I guess I'm mainly curious what is the industry standard, to store critical config in appSettings and endure an app pool recycle or not. – williamsandonz Dec 12 '13 at 02:09
  • 1
    I understand. Well, the industry standard is not altering the web.config file for user settings :) – Andre Pena Dec 12 '13 at 02:16
  • Thanks. Any recommendations? – williamsandonz Dec 12 '13 at 09:20
  • Sorry, I've forgotten you. Take a look at this thread: http://stackoverflow.com/questions/26369/what-is-the-best-way-to-store-user-settings-for-a-net-application – Andre Pena Dec 16 '13 at 12:53