appSettings против applicationSettings. appSettings устарел?

У меня есть вопросы о двух способах сохранения настроек в 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 нет смысла. Я что-то упустил? Какой исторически более старый?


c# properties asp.net appsettings web-deployment-project
person citronas    schedule 28.02.2010    source источник

Ответы (4)


arrow_upward
25
arrow_downward

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

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

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

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

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

person Nick Craver    schedule 28.02.2010

arrow_upward
23
arrow_downward

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

person Bernhard Hofmann    schedule 26.10.2011
comment
Вероятно, единственный ответ, который указывает на несколько важных различий и причин использовать или не использовать applicationSettings. - person Mircea Ion; 11.04.2012

arrow_upward
6
arrow_downward

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

person Loophole    schedule 26.10.2011
comment
Спасибо за эту информацию! Я читал в Интернете, чтобы найти ответ. - person Germstorm; 25.03.2012
comment
Спасибо за этот ответ. Мне было интересно, почему я не могу получить доступ к материалам, хранящимся в ApplicationSettings, в представлении с использованием ASP.NET MVC. - person user850010; 21.08.2012
comment
Кажется, что библиотечные dll могут получить доступ к старым параметрам "ключ-значение" appSettings в основном файле конфигурации, но не к более новым строго типизированным ApplicationSettings. Если вы хотите сохранить все параметры конфигурации (как для приложения, так и для его библиотек) строго типизированными и в одном месте, вам необходимо передать потребности библиотек через свойства или конструкторы. Если у вас есть класс статической библиотеки, например тот, который отправляет электронные письма и имеет много параметров конфигурации, их проще передать один раз, используя старый блок appSettings. ПО МОЕМУ МНЕНИЮ... - person Jeffrey Roughgarden; 31.03.2015

arrow_upward
3
arrow_downward

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

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

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

person galmok    schedule 07.08.2013