Распространенные различия в конфигурации между средами разработки и производства (C#)

  • Статья

Скотт Митчелл

Загрузить PDF-файл

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

Введение

В последних двух руководствах описывается развертывание простого веб-приложения. В руководстве По развертыванию сайта с помощью FTP-клиента показано, как использовать автономный FTP-клиент для копирования необходимых файлов из среды разработки в рабочую среду. В предыдущем руководстве Развертывание сайта с помощью Visual Studio мы рассмотрели развертывание с помощью средства Копирования веб-сайта Visual Studio и параметра Опубликовать. В обоих руководствах каждый файл в рабочей среде был копией файла в среде разработки. Однако нередко файлы конфигурации в рабочей среде отличаются от файлов в среде разработки. Конфигурация веб-приложения хранится в Web.config файле и обычно содержит сведения о внешних ресурсах, таких как база данных, веб-серверы и серверы электронной почты. В ней также описывается поведение приложения в определенных ситуациях, например при возникновении необработанного исключения.

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

Типичные различия конфигурации между средами разработки и рабочей средой

Файл Web.config содержит различные сведения о конфигурации для ASP.NET приложения. Некоторые из этих сведений о конфигурации одинаковы независимо от среды. Например, параметры проверки подлинности и правила авторизации URL-адресов, которые изложены в Web.config элементах и <authorization> файла<authentication>, обычно одинаковы независимо от среды. Но другие сведения о конфигурации, такие как сведения о внешних ресурсах, обычно различаются в зависимости от среды.

Строки подключений к базе данных — это простой пример сведений о конфигурации, которые отличаются в зависимости от среды. Когда веб-приложение взаимодействует с сервером базы данных, оно должно сначала установить подключение, и это достигается с помощью строка подключения. Хотя можно жестко запрограммировать строка подключения базы данных непосредственно на веб-страницах или в коде, который подключается к базе данных, лучше разместить его Web.config<connectionStrings> элемент так, чтобы строка подключения сведения были в едином централизованном расположении. Часто во время разработки используется другая база данных, чем в рабочей среде; Следовательно, сведения о строка подключения должны быть уникальными для каждой среды.

Примечание

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

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

Параметры конфигурации, влияющие на производительность

При первом посещении страницы ASP.NET (или в первый раз после ее изменения) декларативная разметка должна быть преобразована в класс, и этот класс должен быть скомпилирован. Если веб-приложение использует автоматическую компиляцию, необходимо также скомпилировать класс кода программной части страницы. Вы можете настроить набор параметров компиляции Web.config с помощью элемента файла<compilation>.

Атрибут debug является одним из наиболее важных атрибутов в элементе <compilation> . debug Если атрибут имеет значение true, то скомпилированные сборки включают отладочные символы, необходимые при отладке приложения в Visual Studio. Но символы отладки увеличивают размер сборки и предъявляют дополнительные требования к памяти при выполнении кода. Кроме того, если для атрибута debug задано значение true, любое содержимое, возвращаемое методом WebResource.axd , не кэшируется. Это означает, что каждый раз, когда пользователь посещает страницу, ей потребуется повторно скачивать статическое содержимое, возвращаемое WebResource.axd.

Примечание

WebResource.axd — это встроенный обработчик HTTP, представленный в ASP.NET 2.0, который серверные элементы управления используют для извлечения внедренных ресурсов, таких как файлы скриптов, изображения, CSS-файлы и другое содержимое. Дополнительные сведения о том, как WebResource.axd работает и как его можно использовать для доступа к внедренным ресурсам из пользовательских серверных элементов управления, см. в разделе Доступ к внедренным ресурсам по URL-адресу с помощью WebResource.axd.

Атрибуту <compilation> элемента debug обычно присваивается значение true в среде разработки. Для отладки веб-приложения этому атрибуту необходимо присвоить значение true. Если вы попытаетесь выполнить отладку приложения ASP.NET из Visual Studio и debug для атрибута задано значение false, Visual Studio отобразит сообщение о том, что приложение не может быть отлажено до тех пор, пока для атрибута debug не будет задано значение true, и предложит внести это изменение.

В рабочей среде атрибут никогда неdebug должен иметь значение true из-за его влияния на производительность. Более подробное обсуждение этой темы см. в записи блога Скотта Гатри: Не запускать рабочие ASP.NET приложения с debug="true" включенным.

Пользовательские ошибки и трассировка

Когда в приложении ASP.NET возникает необработанное исключение, оно перенаправляемо в среду выполнения, после чего происходит одно из трех действий:

  • Отобразится общее сообщение об ошибке среды выполнения. Эта страница информирует пользователя о том, что произошла ошибка среды выполнения, но не предоставляет никаких сведений об этой ошибке.
  • Отобразится сообщение со сведениями об исключении, которое содержит сведения о только что созданном исключении.
  • Откроется пользовательская страница ошибок, которая представляет собой созданную вами ASP.NET страницу с любым сообщением.

То, что происходит перед необработанным исключением, зависит Web.config от раздела файла<customErrors>.

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

Примечание

Параметр раздела по умолчанию <customErrors> отображает сообщение со сведениями об исключении только при посещении страницы через localhost, в противном случае — универсальную страницу ошибки среды выполнения. Это не идеальный вариант, но необходимо знать, что поведение по умолчанию не раскрывает сведения об исключении для посетителей, не являющихся местными. В следующем руководстве <customErrors> этот раздел рассматривается более подробно и показано, как отображать пользовательскую страницу ошибок при возникновении ошибки в рабочей среде.

Еще одна ASP.NET функция, полезная во время разработки, — трассировка. Трассировка, если она включена Trace.axd, записывает сведения о каждом входящем запросе и предоставляет специальную веб-страницу для просмотра сведений о последних запросах. Вы можете включить и настроить трассировку с помощью <trace> элемента в Web.config.

Если вы включите трассировку, убедитесь, что она отключена в рабочей среде. Так как данные трассировки включают файлы cookie, данные сеанса и другие потенциально конфиденциальные сведения, важно отключить трассировку в рабочей среде. Хорошей новостью является то, что по умолчанию трассировка отключена Trace.axd , а файл доступен только через localhost. При изменении этих параметров по умолчанию в разработке убедитесь, что они отключены в рабочей среде.

Методы обслуживания отдельных сведений о конфигурации

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

Развертывание файла конфигурации рабочей среды вручную

Самый простой подход заключается в Web.config обслуживании двух версий файла: одна для среды разработки и одна для рабочей среды. Развертывание сайта в рабочей среде влечет за собой копирование всех файлов на рабочий сервер в среде разработкиWeb.config, за исключением файла. Вместо этого файл рабочей Web.config среды будет скопирован в рабочую среду.

Этот подход не очень сложный, но его легко реализовать, так как сведения о конфигурации меняются редко. Он лучше всего подходит для приложений с небольшой группой разработчиков, которые размещаются на одном веб-сервере и сведения о конфигурации которых редко изменяются. Это наиболее эффективно при развертывании файлов приложения вручную с помощью изолированного FTP-клиента. При использовании средства копирования веб-сайта или публикации Visual Studio необходимо сначала заменить файл, зависящий Web.config от развертывания, на файл, зависящий от рабочей среды, перед развертыванием, а затем переключить его обратно после завершения развертывания.

Изменение конфигурации во время сборки или развертывания

В ходе обсуждений до сих пор предполагается нерегламентированный процесс сборки и развертывания. Многие крупные программные проекты имеют более формализованные процессы, использующие средства с открытым кодом, собственные или сторонние инструменты. Для таких проектов, скорее всего, можно настроить процесс сборки или развертывания, чтобы соответствующим образом изменить сведения о конфигурации перед их отправкой в рабочую среду. При сборке веб-приложения с помощью MSBuild, NAnt или другого средства сборки, скорее всего, можно добавить шаг сборки, чтобы изменить Web.config файл, включив в него параметры, относящиеся к рабочей среде. Или рабочий процесс развертывания может программно подключиться к серверу управления версиями и получить соответствующий Web.config файл.

Фактический подход к получению соответствующих сведений о конфигурации в рабочей среде сильно зависит от инструментов и рабочего процесса. Таким образом, мы не будем углубляться в эту тему дальше. Если вы используете популярное средство сборки, например MSBuild или NAnt, вы можете найти статьи и руководства по развертыванию, относящиеся к этим средствам, с помощью поиска в Интернете.

Управление различиями конфигурации с помощью проекта веб-развертывания Add-In

В 2006 году корпорация Майкрософт выпустила проект веб-разработки Add-In для Visual Studio 2005. Add-In для Visual Studio 2008 был выпущен в 2008 году. Эта Add-In позволяет разработчикам ASP.NET создать отдельный проект веб-развертывания вместе с проектом веб-приложения, который при сборке явно компилирует веб-приложение и копирует файлы для развертывания в локальный выходной каталог. Проект веб-приложения использует MSBuild в фоновом режиме.

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

сведения о конфигурации, которые копируются в этот каталог следующими способами:

  • С помощью Web.config замены раздела файла, в котором необходимо указать раздел для замены и XML-файл, содержащий замещающий текст.
  • Путем предоставления пути к внешнему исходному файлу конфигурации. Если выбран этот параметр, проект веб-развертывания копирует определенный Web.config файл в выходной каталог (а не Web.config файл, используемый в среде разработки).
  • Путем добавления настраиваемых правил в файл MSBuild, используемый проектом веб-развертывания.

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

Дополнительные сведения об использовании проекта веб-развертывания проверка в этой статье о проектах веб-развертывания из апрельского выпуска журнала MSDN Magazine за апрель 2007 года или по ссылкам в разделе Дополнительные сведения в конце этого руководства.

Примечание

Проект веб-развертывания нельзя использовать вместе с Visual Web Developer, так как проект веб-развертывания реализован как Add-In Visual Studio, а выпуски Visual Studio Express (включая Visual Web Developer) не поддерживают надстройки.

Сводка

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

Счастливое программирование!

Дополнительные материалы

Дополнительные сведения по темам, рассматриваемым в этом руководстве, см. в следующих ресурсах:

НазадВперед