Разработка .Net: Переключение Между Средами Dev И Prod. Первая Часть

Проект загружается на рабочий сервер, компилируется в конфигурации Release. И каждый проект рано или поздно разрастается настолько, что в нем появляется некий «отладочный» или «релизный» код — то есть код, который должен работать только в одной из конфигураций.

И если бы дело ограничивалось только кодом, то директива условной компиляции #if решила бы все проблемы.

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

В самом начале, когда такие проблемы только начинают проявляться, и еще не являются сильной головной болью, обычно используется банальное комментирование строк с ненужным в конкретный момент кодом/разметкой/настройками.

Но это Road To Hell в чистом виде.

Но я хотел бы рассказать вам о Stairway To Heaven.



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

И вдруг я обнаружил, что все мои искусственные костыли совершенно избыточны — проблему можно решить стандартными средствами и без ущерба для читаемости кода.

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

Мы поговорим о разработке приложений ASP.NET MVC — области, в которой я в основном работаю.

Однако все написанное будет применимо к любой разработке .

Трансформация появилась вместе с Visual Studio 2010 и сразу решила огромное количество проблем, связанных с разными настройками сред DEV и PROD. При этом правила, по которым осуществляется трансформация, чрезвычайно просты и гибки.

Возможно, вы заметили, что начиная с VS 2010 файл web.config внезапно стал появляться в дереве проекта в виде контейнера, внутри которого теперь есть два новых файла: web.release.config и web.debug.config. Это файлы, в которых настраивается трансформация основного файла web.config. Вы можете вообще не использовать эти два файла и работать с основным web.config как с единственным, и это не вызовет никаких проблем.

Но лучше будет постичь этот Дзен, чтобы впоследствии практиковать его всегда и с умом.

Изучая, как работает трансформация, самое главное — четко понимать две основные вещи при ее настройке: 1. Трансформация работает только при публикации проекта 2. Файлы web.debug.config и web.release.config. не заменять исходный web.config и изменить (преобразовать) его Казалось бы, первый пункт накладывает серьезные ограничения на использование трансформации в развитии.

И действительно, что хорошего может быть, когда ты разрабатываешь проект, например, под IIS Express, то есть без публикаций? Но на самом деле это не проблема, но этого момента я коснусь позже.

Что касается второго пункта, то это частая ошибка тех, кто впервые столкнулся с трансформацией, в том числе и я: сначала я решил, что при публикации файл web.config заменяется соответствующим файлом Release/Debug. Конечно, первая же публикация заставила меня внимательно прочитать инструкцию, ведь это работает совсем не так.

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

Не будем далеко ходить и рассмотрим стандартный пример.

Автоматически созданный файл web.release.config по умолчанию уже содержит одну стандартную директиву для преобразования.

В приведенном выше примере используется только Transform — его значение говорит нам, что нам нужно удалить атрибут debug в элементе компиляции исходного файла web.config (вместе с его значением, конечно).

Для справки: атрибут debug элемента Configuration/system.web/compilation отвечает за компиляцию страниц Asp.net. В файле web.config по умолчанию значение этого атрибута обычно равно true, что означает, что страницы asp.net будут скомпилированы с добавлением отладочной информации.

В конфигурации Release (то есть в конфигурации, в которой проект обычно компилируется для загрузки в PROD) этого не требуется и именно для этого в файл трансформации web.release.config вставляется команда по умолчанию удалить этот атрибут. Обо всем этом я упомяну подробнее, но позже.

Вернемся к нашему примеру.

При публикации проекта в конфигурации Release атрибут debug в элементе Configuration/system.web/compilation будет удален из окончательного файла web.config, независимо от того, какое у него было значение и был ли он там вообще.

Обратите внимание, что в примере отсутствует атрибут Locator, поскольку преобразование явно установлено для определенного элемента в файле конфигурации.

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

Вот еще один пример:

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform "> <appSettings> <add key="Setting1" value="SettingValue" xdt:Locator="Condition(@key='key1') " xdt:Transform="Replace"/ > </appSettings> </configuration>

В этом примере в исходном файле web.config будет искаться настройка с ключом key1 (это указывается через XPath в Локаторе), и если таковая будет найдена, то она будет полностью заменена.

(значение атрибута Заменить Transform) на настройку из файла с преобразованием.

Значение Condition атрибута Locator содержит выражение XPath, которое применяется к элементу в файле конфигурации, в котором оно определено, а сам элемент автоматически становится текущим выражением XPath. Помимо Condition в атрибуте Locator можно указать значение XPath — оно отличается только тем, что выражение XPath будет рассматриваться в глобальном контексте.

Другой пример:

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform "> <system.web> <customErrors mode="On" xdt:Transform="Insert "> <error statusCode="404" redirect="/Error404" /> <error statusCode="500" redirect="/Error500" /> </customErrors> </system.web> </configuration>

В этом примере мы добавляем в финальный web.config целый раздел настроек customErrors (кстати, очень полезный и часто используемый раздел для настройки поведения веб-приложения в случае ошибки).

Обратите внимание: используя значение Insert атрибута Transform, мы предполагаем отсутствие этого раздела в исходном файле web.config. Если он есть, то нам следует использовать «Заменить» вместо «Вставить».

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

элементов) и изменять значения любых атрибутов для любых элементов.

Это позволяет нам избавиться от постоянного комментирования настроек в файле web.config или регулярной замены его на «тестовый»/«боевой» при отладке.

Полный список значений атрибутов трансформации с примерами использования можно найти в MSDN .

Если говорить о реальном использовании трансформаций в моих проектах, то из всех настроек в файле web.config чаще всего затрагиваются следующие: 1. Строки подключения или, другими словами, все настройки подключения к базе данных.

Это касается и самой строки подключения и настроек всех ORM-фреймворков.

2. Настройки в разделе Настройки приложения.

Все настройки переводятся из режима разработки/отладки в режим боевого применения.

3. Настройки обработки ошибок веб-приложения – раздел / / в примере выше.

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

Конечно, для боевого применения это неприемлемо.

4. Настройки трассировки/журнала/отладки.

Помимо упомянутого выше параметра /> , все настройки, связанные с отладкой и трассировкой, удаляются из web.config (или оставляются, но отключаются).

И настройки журнала переводятся из параноидального режима в рабочий.

5. Настройки профиля кэширования веб-страницы.

Кэширование HTTP-страниц совершенно не требуется при отладке, поэтому профили кэширования в web.debug.config просто отключаются с помощью атрибута Enabled="false".

(Надеюсь, вы используете профили кэширования в атрибуте OutputCache?) Конечно, это не полный список – все зависит от конкретного проекта.

Но именно на эти настройки трансформации влияют почти во всех случаях.

Что касается разработки с использованием IIS Express, где не происходит публикация, то, как я уже сказал, для использования преобразований это не проблема.

Я довольно часто разрабатываю веб-приложения с помощью IIS Express (то есть без публикации на реальный веб-сервер), и делаю это довольно просто: исходный файл web.config содержит все необходимые настройки в версии DEV, а указываются только преобразования.

в веб-файле .

release.config. То есть исходный файл web.config по сути действует как файл web.debug.config. Итак, Visual Studio дает нам возможность гибко управлять работой приложения в средах DEV и PROD, не внося код, верстку или настройки различными костылями или заглушками.

Если вы до сих пор не владеете этой техникой, то этот пробел необходимо срочно закрыть.

В следующих статьях речь пойдет о минификации, бандлах, скриптах, DEBUG и о том, как его правильно использовать.