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?
AppSettings is cached. You can improve performance by further caching to limit namevaluecollection lookups.
Gets the AppSettingsSection data for the current application's default configuration.
The <appSettings> element stores custom application configuration information, such as database connection strings, file paths, XML Web service URLs, or any other custom configuration information for an application.
Locate the web. config file in the root directory of your application (or create one if it does not already exist). Add an <appSettings> element. Add <add> child elements along with key / value pairs to the <appSettings> element as required.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With