Общие различия конфигурации между разработкой и продакшеном (C#)

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

Скачать в формате PDF

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

Введение

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

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

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

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

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

Замечание

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

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

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

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

Атрибут отладки является одним из наиболее важных атрибутов элемента <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 или параметра публикации сначала замените файл, используемый для развертывания, на файл, предназначенный для рабочего окружения, а затем замените их обратно после завершения развертывания.

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

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

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

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

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

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

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

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

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

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

Замечание

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

Сводка

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

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

Дальнейшее чтение

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

НазадДалее

  • Last updated on