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

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

Ответ 1

Об этом было сказано выше: Плюсы и минусы appSettings vs applicationSettings (.NET app.config).

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

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

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

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