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

Question

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

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

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

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

Answer 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.

Answer 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

Answer 3

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

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

Существует также версия для VS2005, если вы не используете 2008.

Answer 4

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

<connectionStrings configSource="connectionStrings.config"/>

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

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

Answer 5

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

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

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

Answer 6

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

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

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

В данном случае это хорошо сработало, но, вероятно, не сработало бы везде.

Answer 7

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

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

Answer 8

Вы также можете сделать это после сборки. Установите новую конфигурацию «Развертывание» в дополнение к «Отладке и выпуску», а затем скопируйте на шаг после сборки правильный файл web.config.

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

Answer 9

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