Подтвердить что ты не робот

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

.NET позволяет использовать файлы .settings для управления настройками приложения. Я хотел бы хранить настройки Production, 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 и давать им те же свойства, но тогда мне понадобилось бы множество операторов switch для определения того, какой класс использовать, потому что они не происходят из общего класса.

4b9b3361

Ответ 1

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

  • создать несколько файлов для разных конфигураций
  • назовите их по соглашению, например. my.dev.settings, my.live.settings
  • создать событие post build (см. ссылки)
  • enjoy =)

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

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

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

Ответ 6

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

У Enterprise Library есть эта функция с V3.0: Резюме

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