Settings.settings vs. app.config в приложении .NET для настольных компьютеров

Возможный дубликат:
В чем разница между файлом app.config и файлом XYZ.settings?

Меня совершенно смущает очевидная избыточность этих двух механизмов в Visual Studio для хранения и управления настройками настольных приложений:

  • Вы можете использовать файл XML app.config, добавляя элементы в раздел <appSettings>. Они могут быть извлечены из кода с помощью класса ConfigurationManager.
  • В качестве альтернативы вы можете использовать файл Settings.settings для добавления отдельных настроек через редактор. Visual Studio создаст класс Settings для безопасного поиска по типу параметров во время выполнения.

Эти два механизма, похоже, служат одной и той же (или почти той же) цели. Я знаю, что есть некоторые различия, но я также озадачен перекрытием и его последствиями. Например, когда я использую Visual Studio для добавления параметров в файл Settings.settings, вся информация, которую я вставляю, заканчивается как записи в файле app.config. По-видимому, существует механизм синхронизации: если я изменяю параметр в файле app.config, Visual Studio предлагает мне обновить файл Settings.settings при следующем открытии его в редакторе.

Мои вопросы:

  • Почему два механизма, а не только один?
  • Каковы наиболее распространенные сценарии использования app.config над Settings.settings и наоборот?
  • Что произойдет, если мое приложение использует Settings.settings и я изменил значение в app.config после его развертывания? Синхронизация Settings.settings не может произойти, поскольку она уже скомпилирована и распределена.

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

Примечание 2. Я знаю, что app.config - это имя файла времени разработки, и я знаком с динамикой копирования и переименования Visual Studio в исполняемую папку.

ОТВЕТЫ

Ответ 1

С точки зрения .NET Framework (не говоря уже о инструментах - Visual Studio - на данный момент), исторически было только [app.exe].config (на самом деле это то, что AppDomain определяет как файл конфигурации. определяемый AppDomain, почему он web.config для веб-приложений...) и machine.config. "приложение" развертывается вместе с приложением, "машина" предназначена для всей машины. Предполагалось, что они будут "вполне" доступны только для обычного пользователя. Возможно изменить их, но это была не идея.

Но как я могу сохранить настройки конечного пользователя? Вот почему [user].config был представлен (я верю в .NET 2). Официальная документация говорит об этом:

Система конфигурации, которая была первоначально выпущена с помощью .NET. Framework поддерживает предоставление статических данных конфигурации приложения через файл локального компьютера machine.config или внутри app.exe.config, который вы развертываете с вашим приложением. Класс LocalFileSettingsProvider расширяет эту встроенную поддержку в следующими способами:

1) Параметры области приложения могут быть сохранены либо в файле machine.config или файлы app.exe.config. Machine.config всегда доступен только для чтения, тогда как app.exe.config ограничивается соображениями безопасности только для чтения для большинства приложений.

2) Параметры пользователя могут быть сохранены в файлах app.exe.config, в которых в случае, если они рассматриваются как статические значения по умолчанию.

3) Настройки, не зависящие от параметров по умолчанию, хранятся в новом файле, user.config, где пользователь - это имя пользователя в настоящее время выполнение приложения. Вы можете указать значение по умолчанию для пользовательской области с параметром DefaultSettingValueAttribute. Поскольку пользовательский настройки часто меняются во время выполнения приложения, user.config всегда читать/писать.

Итак, с точки зрения .NET Framework существует только один трехслойный механизм.

Теперь Visual Studio просто пытается помочь вам, создав безопасный код для окончательных настроек чтения/записи. В большинстве случаев этот файл [user].config не существует, и значение параметра будет определяться тем, что в DefaultSettingValueAttribute (определено для каждого параметра), или использовать то, что было определено статически в app.config. Вот почему Visual Studio также обновляет файл app.config, чтобы вы могли определить статические значения по умолчанию для параметров. Но вы можете полностью удалить все файлы app.config.

Ответ 2

Почему два механизма, а не только один?

Они служат для разных целей. API настроек предлагает доступ для чтения/записи из приложения, тогда как конфиг только для чтения (если вы не пишете файл в коде).

Настройки могут быть определены для каждого пользователя или для каждого приложения и предназначены для того, чтобы быть неустойчивыми. Пользовательские настройки записываются в скрытую папку в хранилище профилей пользователей, которая разрешена в UAC.

App.config предназначен только для каждого приложения. Изменения в App.config автоматически не подбираются. Для обновления значений требуется перезапуск или код. Под UAC пользователям не разрешается писать в каталоги приложений, такие как Program Files, поэтому этот файл следует считать статическим readonly.

Каковы наиболее распространенные сценарии использования app.config Settings.settings и наоборот?

Вы можете использовать Настройки в настольном приложении для хранения пользовательских настроек или параметров, которые изменяются во время выполнения.

Вы бы использовали App.config для более общих статических настроек, таких как строки подключения и т.д., или для определения конфигурации компонентов, используемых в вашем приложении.

Что произойдет, если мое приложение использует Settings.settings, и я меняю значение в app.config после его развертывания?

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

Если вы добавите новые настройки, они будут подняты. Фактически значения по умолчанию запекаются в классе "Настройки", поэтому, даже если app.config пуст, настройки все еще функционируют.