appSettings против applicationSettings. appSettings устарели? [дубликат]

этот вопрос уже есть ответ здесь:

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

Appsettings: Заглянуть внутрь сеть.конфигурации

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

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

ConfigurationManager.AppSettings["key1"];

ApplicationSettings / Properties (автогенерируется с помощью вкладки "свойства" в проекте)
посмотреть в интернете.конфигурации

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

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

Properties.Settings.Default.TestEnvironment

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

оба заменяются в рамках проекта веб-развертывания.

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

4 51
c# asp.net-mvc dependency-properties appsettings web-deployment-project

4 ответа:

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

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

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

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

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

22

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

21

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

6

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

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

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

3