Использование другого Web.config в среде разработки и производства

Мне нужно использовать другую строку подключения к базе данных и адрес SMTP-сервера в моем приложении ASP.NET, в зависимости от того, что она запущена в среде разработки или производства.

Приложение считывает настройки из файла Web.config через свойство WebConfigurationManager.AppSettings.

Я использую команду Build/Publish для развертывания приложения на производственный сервер через FTP и затем вручную заменяю удаленный Web.config на правильный.

Возможно ли как-то упростить процесс развертывания? Спасибо!

Ответ 1

В Visual Studio 2010 и выше у вас теперь есть возможность применить преобразование к вашему web.config в зависимости от конфигурации сборки.

При создании файла web.config вы можете развернуть файл в проводнике решений, и вы увидите два файла:

Web.Debug.Config
Web.Release.Config

Они содержат код преобразования, который можно использовать для

Изменение строки подключения
Удаление трассировки и настроек отладки
Зарегистрировать страницы ошибок

Для получения дополнительной информации см. Синтаксис преобразования Web.config для развертывания проекта веб-приложений в MSDN.

Также возможно, хотя и официально не поддерживается, применить такой же вид преобразования к файлу app.config не веб-приложения. Смотрите блог Phil Bolduc о том, как изменить файл проекта, чтобы добавить новую задачу в msbuild.

Это длительный запрос на Visual Studio Uservoice.

Расширение для Visual Studio 2010 и выше " SlowCheetah " доступно для создания преобразования для любого файла конфигурации. Начиная с Visual Studio 2017.3, SlowCheetah интегрирован в среду IDE, а база кода управляется Microsoft. Эта новая версия также поддерживает преобразование JSON.

Ответ 2

Тег <appSettings> в web.config поддерживает атрибут файла, который будет загружать внешнюю конфигурацию с собственным набором ключей/значений. Они будут отменять любые настройки, которые у вас есть в вашем web.config или добавить к ним.

Мы воспользуемся этим, изменив наш web.config во время установки с атрибутом файла, который соответствует среде, на которой устанавливается сайт. Мы делаем это с помощью нашего установщика.

например,

<appSettings file=".\EnvironmentSpecificConfigurations\dev.config">

<appSettings file=".\EnvironmentSpecificConfigurations\qa.config">

<appSettings file=".\EnvironmentSpecificConfigurations\production.config">

Примечание:

Изменения в .config, указанные атрибутом, не будут инициировать перезапуск рабочего процесса asp.net.

Ответ 3

Вы заглянули в проекты веб-развертывания?

http://www.microsoft.com/downloads/details.aspx?FamilyId=0AA30AE8-C73B-4BDD-BB1B-FE697256C459&displaylang=en

Существует версия для VS2005, если вы не в 2008 году.

Ответ 4

Я тоже хотел бы знать. Это помогает изолировать проблему для меня.

<connectionStrings configSource="connectionStrings.config"/>

Затем я сохраняю connectionStrings.config, а также "{host} connectionStrings.config". Это по-прежнему проблема, но если вы делаете это для разделов, которые отличаются в двух средах, вы можете развернуть и обновить один и тот же файл web.config.

(И я не использую VS, btw.)

Ответ 5

Я использую NAnt Build Script для развертывания в разных средах. Я могу изменить мои файлы конфигурации через XPath в зависимости от того, где они будут развернуты, а затем автоматически помещает их в эту среду, используя Beyond Compare.

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

Вот статья, которую я нашел на ней.

Ответ 6

В одном проекте, где у нас было 4 среды (разработка, тестирование, постановка и производство), мы разработали систему, в которой приложение выбрало соответствующую конфигурацию на основе имени машины, в которой она была развернута.

Это сработало для нас, потому что:

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

Это хорошо сработало для нас в этом случае, но, вероятно, не получилось бы повсеместно.

Ответ 7

Редактор конфигурации Enterprise Library может помочь вам в этом. Он позволяет создавать базовый файл конфигурации, а затем дельта для каждой среды. Затем вы можете объединить базовую конфигурацию и дельта, чтобы создать специфический для среды web.config. Взгляните на информацию здесь, в которой вы можете пройти через нее лучше, чем я могу.

Ответ 8

Вы также можете сделать это шаг после сборки. Настройте новую конфигурацию, которая является "Deploy" в дополнение к Debug и Release, а затем скопируйте шаг после сборки поверх правильного web.config.

Мы используем автоматические сборки для всех наших проектов, а вместе с ними build script обновляет файл web.config, указывая на правильное местоположение. Но это не поможет вам, если вы делаете все от VS.

Ответ 9

Это одно из огромных преимуществ использования machine.config. На моей последней работе у нас были среды разработки, тестирования и производства. Мы могли бы использовать machine.config для таких вещей, как строки подключения (к соответствующей машине dev/test/prod SQL).

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