Как использовать различные .settings файлы для различных сред в.NET?

.NET позволяет Вам использовать .settings файлы для управления параметрами настройки приложения. Я хотел бы сохранить Производство, настройки Development и Test отдельно способом, что я могу сделать что-то вроде этого:

EnvironmentSettings environmentSettings;

// get the current environment (Production, Development or Test)
ApplicationEnvironment Environment = (ApplicationEnvironment)
    Enum.Parse(typeof(ApplicationEnvironment), Settings.Default.ApplicationEnvironment);

switch (Environment)
{
    case ApplicationEnvironment.Production:
        environmentSettings = Settings.Production;
        break;
    ...
}

string reportOutputLocation = environmentSettings.ReportOutputLocation;

В основном я хочу два отдельных класса Настроек: общий класс Настроек, который хранит выбранную среду и несреду определенные свойства и 3 статических экземпляра второго класса под названием EnvironmentSettings. Используемый экземпляр должен зависеть от среды, указанной в общем классе Настроек.

Там какой-либо путь состоит в том, чтобы сделать это за исключением ручного устанавливания значений для всех этих настроек в статическом конструкторе или чем-то? Если я должен сделать это, у меня просто был бы один большой класс Настроек со свойствами как "DevOutputLocation", "LiveOutputLocation", и т.д.

У меня может быть несколько .settings файлов в моем проекте, но это просто создает отдельные классы, которые не происходят друг от друга. Таким образом, я мог сделать DevelopmentSettings.settings, ProductionSettings.settings и файлы TestSettings.settings и дать им те же свойства, но затем мне будет нужен набор операторов переключения везде для определения, какой класс использовать, потому что они не происходят из общего класса.

11
задан Carl 11 February 2010 в 19:38
поделиться

6 ответов

Я использую этот подход для файлов .config, я уверен, что и вам это поможет. Просто посмотрите сообщение в блоге Скотта Хансельмана и этот вопрос . Идеология чертовски проста, но работает неплохо. Все, что вам нужно, это:

  1. создать несколько файлов для разных конфигураций
  2. назвать их по соглашению, например my.dev.settings, my.live.settings
  3. создать событие пост-сборки (см. ссылки)
  4. Enjoy =)

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

2
ответ дан 3 December 2019 в 11:20
поделиться

Одна мысль заключается в том, что переключение между серией статических значений звучит как довольно сложный способ решения проблем. Я бы посоветовал поискать шаблон Singleton. Этот шаблон дает вам один экземпляр класса, который используется всеми ссылками на класс, но при его первой загрузке вы можете выполнить обычные биты инициализации, чтобы проверить свою среду и установить соответствующие значения.

Точно так же, вместо того, чтобы использовать переключатели для работы с разными классами, разве вы не стали бы проектировать один интерфейс и каждый класс реализовывал этот интерфейс?

2
ответ дан 3 December 2019 в 11:20
поделиться

Проверка для определения среды, в которой вы работаете, сопряжена с небольшими накладными расходами. Если вы говорите о веб-среде, это может означать значительное снижение производительности. Я бы рекомендовал создать три отдельных файла конфигурации и настроить систему непрерывной интеграции и развертывания, которая обрабатывает присвоение имен и развертывание соответствующего файла настроек в зависимости от среды. В вашем случае у вас будет три файла: Production.config, Development.config и Test.config. Затем сервер интеграции создаст копию этого файла для web.config или app.config в зависимости от среды.

Что касается любого дополнительного обслуживания, связанного с поддержанием трех отдельных файлов при каждом изменении конфигурации, мы сохраняем файлы в автоматическом форматировании и используем что-то вроде WinMerge, чтобы легко видеть различия и поддерживать их надлежащую синхронизацию. Этот тип файлов обычно не требует большого количества изменений, а когда они и требуются, они обычно являются незначительными дополнениями.

1
ответ дан 3 December 2019 в 11:20
поделиться

В настоящее время я делаю нечто похожее на решение, упомянутое pdavis. Но для упрощения нескольких файлов конфигурации я использую шаблоны T4 для создания файлов конфигурации, специфичных для среды. Таким образом, существует один файл web.tt, который обрабатывает создание файла web.config по умолчанию. Каждая среда имеет свой собственный файл шаблона (qa.tt, production.tt и т. Д.), Который наследуется от web.tt и содержит любые переопределения для конкретной среды. Любые изменения в веб-конфигурации - новые параметры приложения, параметры конфигурации и т. Д. Автоматически распространяются на все файлы конфигурации для конкретного региона путем повторного создания шаблонов, и вам не нужно беспокоиться о синхронизации файлов с помощью инструмента сравнения.

1
ответ дан 3 December 2019 в 11:20
поделиться

Просто идея, но она может сработать ...

  • Вам понадобится N + 2 файла настроек (N разных сборок; 2 мастера) с , содержащими одинаковые ключи.

  • Очистите свойство "Пользовательский инструмент" для всех, кроме одного из мастеров (так только один мастер создает).

  • Измените сценарий предварительной сборки для каждого выпуска, чтобы скопировать соответствующее содержимое файла настроек в файл build-master.

  • Измените сценарий пост-сборки, чтобы скопировать содержимое вторичного главного файла обратно в исходный главный файл.

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

Я тоже никогда этого не делал; хотя бывают случаи, когда мне хотелось, чтобы в VS был более простой способ сделать что-то подобное.

0
ответ дан 3 December 2019 в 11:20
поделиться

Просто некоторая дополнительная информация о файлах конфигурации на основе среды .NET без конкретного использования указанной выше реализации:

В Enterprise Library есть эта функция, начиная с версии V3.0: Резюме

Visual Studio 2010 также будет иметь эту функцию. Это называется Config Transformation

0
ответ дан 3 December 2019 в 11:20
поделиться
Другие вопросы по тегам:

Похожие вопросы: