Очень часто я вижу ответ на вопрос: "Как мне сохранить настройки в моем приложении .NET?" это отредактировать файл app.config, вручную добавив записи в app.config (или web.config) следующим образом:

<configuration> 
  <appSettings>
    **<add key="ConfigValueName" value="ABC"/>**
  </appSettings>
</configuration>

Затем доступ к ним, как:

string configValue = Configuration.AppSettings["ConfigValueName"];

Я буду называть подход, изложенный выше, как «app.config». подход. Очень редко я вижу людей, которые рекомендуют добавлять & quot; Настройки & quot; файл в проект. Я видел это очень много раз в Интернете и в стеке потока ... Я начинаю задумываться, не упустил ли я что-то ... потому что я не уверен, почему вы используете этот метод вместо "& quot;" Настройки & Quot; файл. Я не входил в .NET до VS2005, поэтому у меня есть одна теория: как все было сделано в VS2003, и люди никогда не переключались?

Примеры людей, рекомендующих подход app.config:

Simplest way to have a configuration file in a Windows Forms C# Application Best-Practices : how should I store settings in C# (Format/Type)?

С моей точки зрения, естьfollowing advantages of the "Settings file" approach:

Can be used for both Application Settings (those that are common to all users) and User settings from the same interface. Ability to use the Settings designer support in visual studio. Less error prone then editing an XML file directly IMHO. Refactoring - you can rename a particular setting name and it will automatically update references in your code. Compile type checking. Auto-completion support. Property-Grid Capabilities. I have found that the PropertyGrid control is a very easy way to make a quick options form. You just do propertyGrid1.SelectedObject = Settings1.Default; and you're done.

Если вы не уверены, что я имею в виду под & quot; Настройки & quot; Подход к файлу см.эта почта Это один из немногих примеров, когда кто-то рекомендует использовать файлы настроек вместо app.confg.

EDIT: Please understand: The intention of this topic is to figure out why people would use the app.config approach outlined above over the Settings file approach. I have encountered the limitations of the Settings file approach and have been forced to roll my own custom solution at times. That's an entirely different discussion.