55

I've got some questions about two ways to save settings in the web.config.

Appsettings: Look in web.config

<appSettings>
 <add key="key1" value="value1"/>
 <add key="key2" value="value2"/>
</appSettings>

Usage in code-behind:

ConfigurationManager.AppSettings["key1"];

ApplicationSettings/ Properties (autogenerated by using the 'properties'-tab in the project)
Look in web.config

<applicationSettings>
    <Projectname.Properties.Settings>
        <setting name="TestEnvironment" serializeAs="String">
            <value>True</value>
        </setting>
    </Projectname.Properties.Settings>
</applicationSettings>

Usage in code-behind:

Properties.Settings.Default.TestEnvironment

So, what's the difference between these two storage possibilities of settings in the web.config?
As far as I can see, a downside of the appSettings is that you have modify the web.config yourself and the appSettings are not strong typed, where as the applicationSettings are.

Both are replaceable within a web deployment project.

As far as I am concerned, there is no use for appSettings. Am I missing something here? Which is the historically seen older one?

KyleMit
  • 45,382
  • 53
  • 367
  • 544
citronas
  • 17,809
  • 26
  • 85
  • 155

4 Answers4

25

This has been discussed before here: Pros and cons of appSettings vs applicationSettings (.NET app.config).

As for your questions: The older one is <appSettings>, it was around before 2.0, <applicationSettings> became available in 2.0.

Advantage? When I'm editing a value, or adding a value on a server where the best tool is notepad <applicationSettings> is very verbose, and sometimes I just want a string. Maybe a dumb example, but when I'm tweaking the config settings between tiers to get the automatic deployment setup correctly, it's tremendously useful that it's simple.

I have to agree with marc_s from the other discussion though, if you're doing anything that's really complex, you're probably approaching the point you should have your own configuration section anyway. Since you're de-serializing into your config type on startup...you get the same type checking that way, just via the XML Serializer directly is the only difference.

This also has the advantage of me doing Config.LDAPServer or maybe one config for different areas each, like Security.Config and Themes.Config (guessing here!), you can get a really useful/clear naming scheme in there as a side benefit.

Community
  • 1
  • 1
Nick Craver
  • 594,859
  • 130
  • 1,270
  • 1,139
23

ApplicationSettings are namespaced so two different assemblies can both have a setting for "timeout" without conflicts, and ApplicationSettings are optional since the default value is set via an attribute on the setting in code.

Bernhard Hofmann
  • 9,825
  • 12
  • 59
  • 78
  • 4
    Probably the only answer that points out a few important differences and reasons to use or not use applicationSettings. – Mircea Ion Apr 11 '12 at 19:31
6

One thing I have noticed is that AppSettings values can be referenced via <%$ AppSettings: name %> inline tags in aspx pages, but there seems to be no equivalent way to access ApplicationSettings values through inline tags.

sra
  • 23,629
  • 7
  • 52
  • 88
Loophole
  • 164
  • 2
  • 5
  • 3
    Thank you for this info! I read the internet to find this answer. – Germstorm Mar 25 '12 at 15:08
  • Thanks for this answer. I was wondering why I cannot access stuff stored in ApplicationSettings in a View using ASP.NET MVC. – user850010 Aug 21 '12 at 10:06
  • It seems that library dlls can access the old-style key-value appSettings in the main config file but not the newer strongly typed ApplicationSettings. If you want to keep all your config parameters (for both the app and its libraries) strongly typed and in one place, you have to pass the libraries' needs via properties or constructors. If you have a static library class, e.g. one that sends emails and has many config parameters, it's easier to pass them once using the old appSettings block. IMHO... – Jeffrey Roughgarden Mar 31 '15 at 20:06
3

I would like to add that IIS 8.0 GUI (and previous versions as well) cannot edit the <applicationSettings> section (it is invisible, i.e. it appears as if no parameters can be configured) whereas <appSettings> are editable with IIS 8.0.

It would have been nice if VS2012/IIS 8.0 used the same GUI configure system all the way, but the products do not seem to be synchronized in that aspect. One way or the other, you may have to edit the application settings with notepad.

The connection strings do appear in both GUIs but if using <applicationSettings> in IIS they include full path (Namespace.Properties.Settings.ConnectionStringName).

galmok
  • 819
  • 8
  • 21