Предыдущий ролик Следующий ролик  

Видео урок: Using Web.config transformations

Основы ASP.NET MVC 5

В этом видео я покажу вам, как автоматизировать изменения элементов файла Web.config во время построения решения, которое в дальнейшем будет развернуто. Выполняя преобразования файла Web.config, мы получаем полезный инструмент для управления отдельными наборами настроек, ориентированных на определенные среды разработки и публикации, а также на множество других сред, которые тоже стоит учитывать. Кое-что из того, что я собираюсь вам показать, контролировалось скрытно во время развертывания на Azure или AppHarbor. Например, замена строки подключения в файле Web.config на строку подключения к рабочей базе данных.

При создании пакета Web Deploy, т.е. zip-файла, который можно установить с помощью инструмента командной строки MS Deploy на локальный или удаленный сервер с запущенной службой IIS, этим тоже управляем не мы. Но независимо от того, развертываем мы на IIS или на облако, или просто публикуем в файловую систему (а этот процесс мы рассмотрим чуть позже), у нас есть возможность настроить такое автоматическое изменение файла Web.config самостоятельно, потому что нам может понадобиться изменить не только строку подключения. Если мы раскроем раздел Web.config в Обозревателе решений, то увидим там 2 файла: Web.Debug.config и Web.Release.config.

В этих файлах описываются изменения, которые необходимо вносить в базовый файл Web.config во время построения решения в режиме отладки и в режиме публикации соответственно. Во время публикации проекта мы всегда можем выбрать режим конфигурации, а при развертывании на AppHarbor наши проекты всегда строятся в режиме публикации. Но в случае локального запуска приложения мы можем переключаться между этими конфигурациями с помощью вот этого выпадающего списка, расположенного ниже главного меню. А выбрав пункт "Диспетчер конфигураций" (Configuration Manager), можно даже создать новый режим, воспользовавшись пунктом "Создать" данного выпадающего списка.

Допустим, мне нужна третья среда под названием "Test". Я могу добавить ее вот здесь. После создания новой среды я могу добавить еще одно преобразование конфигурации, нажав правой кнопкой мыши на файле Web.config и выбрав пункт "Добавить преобразование конфигурации" (Add Config Transform). Но что именно находится внутри этих файлов? Если сначала рассмотреть файл Web.Debug.config, то можно увидеть, что в нем есть кое-какая информация, но большая часть ее закомментирована. И хотя считается хорошим тоном для внесения ясности определять здесь настройки режима отладки, я заметил, что большинство разработчиков, применяющих преобразования, задают эти настройки в базовом файле Web.config, а настройки публикации - в файле Web.Release.config.

Поэтому давайте рассмотрим именно этот файл. Он очень похож на файл конфигурации для режима отладки за исключением того, что в нем есть один элемент, который не закомментирован. Структура этого файла отражает структуру главного конфигурационного файла, но в элементе configuration нужно определить только то подмножество элементов, которые мы собираемся добавить, удалить или отредактировать. Раскомментируем этот элемент connectionString, аналогичный соответствующему элементу нашего базового файла Web.config, за исключением того, что в нем отсутствует атрибут providerName и присутствуют два дополнительных атрибута, которых не было в базовом конфигурационном файле.

Значение атрибута Locator говорит о том, что он некоторым образом влияет на элемент connectionString, атрибут name которого совпадает с названием данной строки подключения, а именно "MyDB". Значение атрибута Transform говорит о том, каким именно будет это воздействие, т.е. преобразование атрибутов, определенных в этом элементе, к которым в данном случае относится только элемент connectionString. Конечно, в нашем файле Web.config нет строки подключения с именем "MyDB", но если мы изменим значение этого атрибута на DefaultConnection, то сможем осуществить замену нашей строки подключения без помощи мастера публикации или развертывания.

Внутри секции system.web есть элемент compilation, обладающий только атрибутом Transform, который имеет значение "RemoveAttributes". Это означает, что мы собираемся удалить атрибут debug из элемента compilation, но при этом не затронуть остальные атрибуты. Если нужно удалить несколько атрибутов, то можно воспользоваться списком, элементы которого разделены запятой. Атрибут Locator нам не нужен, потому что у нас имеется всего один элемент compilation. Аналогично базовому файлу Web.config ниже имеется всего один элемент customErrors.

Здесь уже значение атрибута Transform указывает на то, что мы хотим заменить соответствующий элемент главного конфигурационного файла вот на этот элемент. Опять же, это возможно, потому что для локальных пользователей нам нужна подробная информация об ошибке, а для удаленных - информация о встроенных ошибках. И независимо от того, какие атрибуты я задам в базовом файле Web.config, этот код гарантирует, что при публикации в режиме Release этот атрибут всегда будет иметь значение "RemoteOnly".

Нужно только убедиться, что мы работаем в режиме Release. Итак, через некоторое время можно уже приступить к тестированию. Атрибуты Locator и Transform могут иметь куда более сложные значения. Например, значение Match может сопровождаться выражениями xpass и условиями, а атрибут Transform может вставлять элементы перед или после других элементов. Давайте добавим еще один элемент с помощью Insert. Делать это будем в элементе appSettings. Этот элемент является дочерним элементом configuration.

Добавим ключ для SMTP-сервера, который будет иметь значение "smtp.mvcatm.com". Итак, в файле Web.config этот элемент не определен. Давайте представим, что при запуске в режиме Debug мой код никогда никому не будет отправлять электронные письма. Поэтому я могу просто сказать, что Transform равен Insert. И в результате он будет добавлен в конфигурацию публикации. Если сохранить изменения и нажать правой кнопкой мыши на файле Web.Release.config, то можно выполнить предварительное преобразование и посмотреть, какое именно влияние окажет это преобразование.

Во время публикации выберем вариант "Custom" (Пользовательский), а затем назовем профиль "File System" (Файловая система), поскольку я собираюсь создать скомпилированную версию этого приложения на рабочем столе в папке под названием "Release". Выберем вариант "File System". Проверьте, выбрана ли конфигурация Release, а затем нажмите кнопку "Опубликовать" (Publish). Если затем открыть этот файл, то можно увидеть новую строку подключения, настройки почтового сервера, отсутствие атрибутов в элементе compilation и замененный элемент customErrors.

Таким образом, несмотря на то что внедрение и замена строки подключения с помощью мастеров публикации и сервисов развертывания довольно полезны, теперь мы видим, как можно управлять этим самостоятельно с помощью преобразований файла Web.config, что позволит управлять настройками в рамках различных сред. Просмотреть все изменения, которые мы внесли в проект в рамках этой главы, можно в файлах упражнений, размещенных в папке Chapter 8 -> Final.