Храните то, что, по вашему мнению, может измениться между средами, в конфигурационных файлах.
Visual Studio может сделать тяжелую работу здесь, если хотите; Вы можете создать настройки и указать значения по умолчанию на вкладке «Настройки» свойств проекта Visual Studio.
Это создаст файл конфигурации для вас и предоставит строго типизированный доступ через Properties.Settings.Default .
Что касается обработки нескольких сред в вашей сборке, я видел, что некоторые люди рекомендуют поддерживать несколько копий файлов конфигурации - например, по одной для каждой среды - а другие рекомендуют использовать nant для изменения файлов конфигурации на этапе сборки или развертывания. , Вы можете использовать свойство, переданное nant в командной строке (например), чтобы выбрать среду, которую вы создаете (или развертываете, в зависимости от того, как вы это делаете).
Я не рекомендую ни один из этих подходов, потому что:
- Они оба требуют изменений в вашей сборке для поддержки новых сред.
- Если вы измените параметр в развернутой среде и забудете обновить сборку, то при следующем развертывании это изменение будет сброшено (что несколько нарушит настройку конфигурации).
- Если кто-то создает новую среду (скажем, он хочет исследовать проблемы, возникающие, например, при обновлении до новой версии SQL Server) и не хочет создавать все новые файлы конфигурации в системе сборки, он может решить просто использовать настройки существующей среды. Допустим, они выбирают развертывание с использованием текущих настроек и забывают что-то изменить потом. Теперь ваша новая «тестовая» среда может указывать на живой набор.
Я создаю копию каждого файла конфигурации (например, с именем web.config.example) и закомментирую параметры в них (если они не имеют значимых значений по умолчанию). Я проверяю их и получаю развернутые вместо реального web.config (то есть web.config НЕ развертывается автоматически. Web.config.example развертывается как web.config.example.
Администратор новой среды должен будет скопировать и переименовать файл в web.config и указать значимые значения). Я также помещаю все вызовы в настройки позади своего собственного класса-оболочки - если отсутствует обязательный параметр, я выкидываю исключение.
Сборка и мои среды больше не зависят друг от друга - одну сборку можно развернуть в любой среде.
Если параметр отсутствует (новое окружение или новый параметр в существующем окружении), вы получите хорошее четкое исключение, чтобы сообщить администратору, что делать.
Существующие настройки не изменяются после обновления, так как были обновлены только файлы .example. Это задача администратора - сравнить текущие настройки с последним примером и при необходимости изменить.
Чтобы настроить развертывание, вы можете поместить все параметры среды (пути установки и т. Д.) В свойства nant и переместить их в отдельный файл (например, settings.build), а затем использовать задачу включения nant, чтобы включить этот файл в файл. верх файла развертывания (например, deploy.build). Затем вы можете развернуть новую версию deploy.build, не перезаписывая изменения конфигурации, как они есть в settings.build. Если новое свойство вводится в deploy.build, nant завершится неудачно с хорошим сообщением о том, что вы не установили это свойство.