Are there any recommendations on when to use Application settings (not per user settings) vs. .config file <appsettings>?
Update
Looking to understand some of the finer and important differences because they're both effectively key/value stores. For example, I know modifying appsettings in web.config will recycle the web application.
Settings have been in .NET for a while now and I haven't bothered to look at them - maybe one is somewhat redundant, or using both at the same time doesn't make sense... that's the kind of detail I'm looking to understand and the reasons.
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.
By adding an application configuration file (app. config file) to a C# project, you can customize how the common language runtime locates and loads assembly files. For more information about application configuration files, see How the runtime locates assemblies (. NET Framework).
The ~/Configuration/AppSettings. config file allows you to configure the location of asset folders, the state file storage, and the security model.
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.
The question is a bit old but I stumbled upon it and thought to add some clarity in case someone else also stumbles upon it...
The settings option (as opposed to the raw <appSettings> section) has strong support in the framework:
Settings are strongly typed (i.e. bool, int, ConnectionString, etc) instead of all being returned as string to be parsed by your code if needs be.
Settings can be scoped to be a) Internal or Public, and b) Per User or Per Application (the latter essentially meaning Per Machine).
Your application would need to supply its own interface for changing the settings, but that's fairly trivial as the setting properties are read/write in code, and the generated class supplies functionality for saving the changes.
The app.config (or web.config) file that is deployed, only stores the default values (see below for how runtime changes are handled) - which means that changing settings and saving them at runtime doesn't change the .config file - and by extension doesn't cause a restart of your application.
Changes at runtime are saved to a local location (somewhere in either c:\ProgramData.. or c:\Users\MyUser\AppData\Local..) depending on the scope chosen. As such, subsequent releases of your application can safely introduce new settings without fear of trashing previously customized values, as they are safely stored away.
Hope that helps to clear things up a bit.
One point that seems to be overlooked from the answers so far is that .config files can be transformed using Transformation files. These are available for Web.config files by default (in Visual Studio) and are enabled for arbitrary .config files with the SlowCheetah - XML Transforms add-in for Visual Studio (SlowCheetah also adds a previewer and applies transformations on build rather than just on deploy.
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