3

I'm trying to understand Application Settings / AppSettings.

My understanding is that AppSettings (which are within the app.config file) are accessed via ConfigurationManager.AppSettings, and this is considered deprecated functionality.

I understand Application Settings are accessed via Properties.Settings.Default, and are usually created as .settings files (in Visual Studio this can be done in Project Properties).

If this is correct (please confirm), my question is why do all projects in Visual Studio automatically create an App.config file? Can / should I delete this file and create a Settings.settings file instead? Should I use both? (why?) Can I access the app.config file using Properties.Settings? If so, how?

Also, if Properties.Settings.Default accesses the "default" settings file, how / why would you access a file other than the default one?

Edit: This question is not answered by the AppSettings vs Application Settings threads, because my specific question is why I need an App.Config file.

Haighstrom
  • 577
  • 5
  • 16
  • 1
    http://stackoverflow.com/questions/2350893/appsettings-vs-applicationsettings-appsettings-outdated – Haighstrom May 09 '15 at 15:52
  • Is the answer that I can use both .config and .settings files, and although .settings are newer, both still have utility depending on situation? – Haighstrom May 09 '15 at 15:53

1 Answers1

1

ApplicationSettings are preferred over AppSettings as they are strongly typed, but there are times (such as in Azure) where AppSettings are preferred as they can be set from the Azure control panel on an instance by instance basis.

That said, let's look at the other part of your question relating to Settings.Default vs. App.Config.

I would not remove the App.Config from every project, as it gets automatically updated when you update your settings. The settings file has the default values in code, but the App.Config file can override those at runtime. This is nice to be able to copy the relevant sections to new applications (into their app.config or web.config) that are going to consume a library.

The only app.config file from your projects that gets executed is the startup project, and the values in that app.config (or web.config as it may be) are the ones used at runtime.

Hopefully this clears up some confusion around the relationship of the files.

Sample Structure of Configuration Files:

ProjectA
- ProjectA.Settings
- App.Config // VS syncs with Settings file
ProjectB
- ProjectB.Settings
- App.Config // VS syncs with Settings file
ProjectC (Startup Project
- ProjectC.Settings
- App.Config
    // Can contain override settings for ProjectA.Settings and ProjectB.Settings
Martin Noreke
  • 4,066
  • 22
  • 34
  • So I hadn't appreciated that the .settings file and app.config update each other. But I'm still not sure I understand the purpose of each. Why have two files doing the same thing (i.e. holding user/application data)? Is because unlike app.config, the settings file is associated with a namespace, so you could have multiple settings files being controlled by one App.Config file? – Haighstrom May 09 '15 at 16:30
  • Correct. In the end, your starting application App.Config may contain sections for multiple *.Settings file configurations in order to override the defaults. – Martin Noreke May 09 '15 at 16:34
  • But why not just have the several .settings files, and no App.Config file? Is a .settings file just a user-friendly way of modifying the app.config file, or are both actually accessed during runtime? – Haighstrom May 09 '15 at 16:37
  • At runtime, the settings file is overridden by the startup projects app config if defined. The settings file contains the defaults, and the app.config the final values. This allows you to change environmental settings through the App.Config at run time as the settings file gets compiled into the code and cannot be changed without recompile/redeploy. – Martin Noreke May 09 '15 at 16:39
  • 1
    Yes with your edit above, it's clearer. App.Config and .Settings will be aligned within a single project, but in your example above, if you modify App.Config C, when you run the application ProjectA.Settings and ProjectB.Settings would be changed. I understand now, thank you. – Haighstrom May 09 '15 at 16:40