2010-02-11 4 views
11

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

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; 

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

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

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

+0

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

ответ

2

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

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

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

+0

Действительно ли это единственный способ? Я полагаю, что если он одобрен Скоттом Х. Это похоже на действительно грязный хак. Вы могли бы подумать, что вы можете указать, какие файлы .settings или .config использовать для каждой конфигурации сборки. – Carl

+0

Я просто возвращался к своим ранее задаваемым вопросам и заметил, что я никогда не отмечал это так, как ответил, так что вы идете. Еще раз спасибо. – Carl

+0

Другая возможность - использовать инструмент преобразования XML, такой как [SlowCheetah] (https://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5) –

0

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

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

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

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

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

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

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

2

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

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

0

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

Библиотеки Enterprise имеет эту функцию, поскольку V3.0: Summary

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

1

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

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

1

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

Смежные вопросы