Is using a const in a class in App_Code quicker/faster than using appSettings in config.web on a webforms asp.net app?

im wanting to know the fastest way to access my globals... they will only change in the beta testing phase. before we go live. from then on they wont change ever.

im thinking that there is an overhead in getting stuff from web.config also its neater code wise to write App.HostUrl instead of ConfigurationManager.AppSettings["HostUrl"].ToString()

app.cs

public class App {
    public const string HostUrl = "http://www.{domain}.co.uk";
    public const string iHostUrl = "http://img.{domain}.co.uk";
}

or

web.config

<appSettings>
<add key="HostUrl" value="http://www.{domain}.co.uk" />
<add key="iHostUrl" value="http://img.{domain}.co.uk" />
<appSettings>

From stackoverflow

• Web.config is parsed by your application anyway, so in practise there's no extra overhead associated with it. Whether it has appsettings or not, the file is still opened, read and parsed.

  You should be worrying about real performance bottlenecks in your application rather than something it does once when it starts up. You're not going to achieve a noticeable boost in performance by not storing your settings in web.config.

• A const will be faster but that limits our deployment options. As an alternative, why don't you create a static variables and put the appsetting in there in your Application_Start (in global.asax).

  public class App {
      public static string HostUrl;
      public static string iHostUrl;
  }
  

  In Global.asax.cs:

  void Application_Start(object sender, EventArgs e)
  {
      App.HostUrl = ConfigurationManager.AppSettings["HostUrl"].ToString();
      App.iHostUrl = ConfigurationManager.AppSettings["iHostUrl"].ToString();
  }
  

  Matt Peters : thank you for the quick responce. in what way does it limit the deployment options.. am i missing something? do we pay unboxing when we use Application State? or is that neglegable?

  Keltex : For example, if you are pre-compiling your application it's far easier to update the web.config than redeploy the entire app.

• I use classes with constants for things that will really be constant (i.e. primary keys of values in lookup tables that never change). The stuff you have in your example looks like it might actually change between a test environment and a production environment, which is exactly the kind of stuff that I think makes sense to put into a .config file of some kind. Then those files can be kept in your source control/configuration management system for each of the environments to which you deploy.

  As far as the ugliness of having to do 'ConfigurationManager.AppSettings["HostUri"]', you can always wrap those into static properties with getters in a class in your app_code or external library so you could just say 'App.HostUrl'.

  As far as performance, I'm fairly sure that the values in configuration get cached in memory when the app is initialized and/or the first time the values are called out of the configuration system, so the performance difference is probably pretty negligible.