appSettings vs applicationSettings. appSettings outdated? [duplicate]

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.

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.

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.