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

Question

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

Настройки приложения: посмотрите в 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 не являются строго типизированными, как, например, applicationSettings.

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

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

Answer 1

Это уже обсуждалось здесь: плюсы и минусы appSettings против applicationSettings (.NET app.config).

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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