appSettings vs applicationSettings. appSettings устарел?

Question

У меня есть некоторые вопросы о двух способах сохранения настроек в web.config.

AppSettings: Посмотрите в web.config

<appSettings> 
<add key="key1" value="value1"/> 
<add key="key2" value="value2"/> 
</appSettings> 

Использование в код-за:

ConfigurationManager.AppSettings["key1"]; 

ApplicationSettings/Свойства (автогенерируемые с помощью «properties'-вкладка в проекте)
Посмотрите в web.config

<applicationSettings> 
    <Projectname.Properties.Settings> 
     <setting name="TestEnvironment" serializeAs="String"> 
      <value>True</value> 
     </setting> 
    </Projectname.Properties.Settings> 
</applicationSettings> 

Использование в коде-за:

Properties.Settings.Default.TestEnvironment 

Итак, в чем разница между этими двумя хранения возможности настроек в web.config?
Насколько я вижу, недостатком appSettings является то, что вы изменили файл web.config самостоятельно, а параметры приложения не были напечатаны строго, где в качестве параметров приложения.

Оба варианта могут быть заменены в рамках проекта развертывания сети.

Что касается меня, то не использовать для appSettings. Я что-то упустил? Что изначально считается старым?

Answer 1

Об этом ранее говорилось: Pros and cons of appSettings vs applicationSettings (.NET app.config).

Что касается ваших вопросов: более старый - <appSettings>, было около 2.0, <applicationSettings> стал доступен в версии 2.0.

Преимущество? Когда я редактирую значение или добавляю значение на сервере, где лучшим инструментом является блокнот <applicationSettings> is very verbose, а иногда я просто хочу строку. Может быть, глупый пример, но когда я настраиваю настройки конфигурации между уровнями, чтобы правильно настроить автоматическое развертывание, очень полезно, что это просто.

Я должен согласиться с marc_s из другой дискуссии, хотя, если вы делаете все, что действительно сложно, вы, вероятно, приближаетесь к точке, в которой вы должны иметь свой собственный раздел конфигурации. Поскольку вы запускаете сериализацию в свой тип конфигурации при запуске ... вы получаете тот же тип проверки таким образом, просто через XML-сериализатор напрямую зависит только одно.

Это также имеет преимущество мне делать Config.LDAPServer или, может быть, один конфигурации для различных областей каждый, как Security.Config и Themes.Config (угадывание здесь!), Вы можете получить действительно полезную/четкую схему именования в там, как побочный эффект.

Answer 2

Одна вещь, которую я заметил, это то, что значения AppSettings можно ссылаться на встроенные теги <%$ AppSettings: name %> на страницах aspx, но, похоже, нет эквивалентного способа доступа к значениям ApplicationSettings с помощью встроенных тегов.

Answer 3

ApplicationSettings имеют пространство имен, поэтому две разные сборки могут иметь параметр «тайм-аут» без конфликтов, а ApplicationSettings являются необязательными, поскольку значение по умолчанию устанавливается с помощью атрибута в настройке в коде.

Answer 4

Я хотел бы добавить, что IIS 8.0 GUI (и предыдущие версии, а) не может редактировать раздел <applicationSettings> (она невидима, то есть появляется, как будто никакие параметры не могут быть настроены), тогда как <appSettings> являются изменяемыми с IIS 8.0.

Было бы хорошо, если бы VS2012/IIS 8.0 полностью использовали одну и ту же конфигурационную систему GUI, но продукты, похоже, не синхронизированы в этом аспекте. Так или иначе, возможно, вам придется отредактировать настройки приложения с помощью блокнота.

Строка соединения появляется в обоих ГПИ, но при использовании <applicationSettings> в IIS, они включают в себя полный путь (пространства имен .Properties.Settings. ConnectionStringName).