Приложения XML были интегрированы в .NET настолько, что XML больше не является модным словом. Microsoft, как вы, наверное, знаете, взяла XML в ядро своей платформы .NET. XML не только является общепринятым форматом для обмена данными, он также используется для хранения настроек конфигурации.
Параметры конфигурации для любого из ваших веб-приложений ASP.NET можно сохранить в виде простого текстового файла. Представленный в легко понятном формате XML, этот файл, называемый Web.config, может содержать данные всего приложения, такие как строки подключения к базе данных, пользовательские сообщения об ошибках и параметры культуры.
Поскольку Web.config является файлом XML, он может состоять из любых допустимых тегов XML, но корневым элементом всегда должен быть <configuration> . Внутри этого тега вы можете включать различные другие теги для описания ваших настроек. Поскольку файл Web.config входит в стандартную комплектацию, когда вы начинаете создавать новое веб-приложение, давайте рассмотрим XML-файл по умолчанию, созданный Visual Studio .NET:
<?xml version="1.0" encoding="utf-8" ?> <configuration> <system.web> <compilation defaultLanguage="c#" debug="true" /> <customErrors mode="RemoteOnly" /> <authentication mode="Windows" /> <authorization> <allow users="*" /> </authorization> <trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" /> <sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" /> <globalization requestEncoding="utf-8" responseEncoding="utf-8" /> </system.web> </configuration>
Опытные программисты ASP.NET заметят, что я пропустил теги комментариев, которые автоматически генерируются вместе с файлом. Я сделал это, чтобы обеспечить четкое представление о XML, который используется здесь. Кроме того, я подробно остановлюсь на каждом теге конфигурации позже в этой статье, и это обсуждение сделает теги комментариев довольно устаревшими.
Если вы посмотрите на пример XML, то заметите, что у <configuration> есть только один дочерний тег, который мы называем группой разделов, — <system.web> . Группа разделов обычно содержит разделы настроек, такие как: compilation , customErrors , authentication , authorization и т. Д. Это работает довольно просто: вы просто включаете свои настройки в соответствующие разделы настроек. Например, если вы хотите использовать другой режим аутентификации для своего веб-приложения, вы измените этот параметр в разделе аутентификации.
Помимо стандартных настроек system.web вы можете определить собственные настройки приложения, например строку подключения к базе данных, используя <appSettings> . Следовательно, ваш самый общий набросок Web.config будет:
<configuration> <system.web> <! - sections--> </system.web> <appSettings> <! - sections --> </appSettings > </configuration>
Давайте обсудим детали обеих групп разделов.
Группа system.web
В эту группу разделов вы, как правило, включаете параметры конфигурации, которые в эпоху до .NET вы устанавливали где-то в консоли администрирования IIS. В библиотеке MSDN от Microsoft вы можете найти обзор всех тегов, которые понимает группа разделов system.web , но, в зависимости от сложности вашего сайта, вы никогда не сможете использовать даже половину этих параметров.
Давайте рассмотрим наиболее ценные настройки, которые вы можете сделать в группе разделов system.web, в алфавитном порядке.
<authentication>
Раздел аутентификации контролирует тип аутентификации, используемый в вашем веб-приложении, который содержится в режиме атрибута. Вы введете значение «Нет», если кто-то может получить доступ к вашему приложению. Если требуется аутентификация, вы будете использовать «Windows», «Forms» или «Passport» для определения типа аутентификации. Например:
<authentication mode="Windows" />
<authorization>Чтобы разрешить или запретить доступ к вашему веб-приложению определенным пользователям или ролям, используйте дочерние теги
<allow>или<deny>.
<authorization> <allow roles="Administrators,Users" /> <deny users="*" /> </authorization>
Важно понимать, что модуль авторизации ASP.NET просматривает разделы, применяя первое правило, соответствующее текущему пользователю. В этом примере пользователям, имеющим роль Администраторы или Пользователи, будет разрешен доступ, в то время как всем остальным (обозначенным подстановочным знаком *) будет встречено второе правило, и впоследствии ему будет отказано в доступе.
<compilation>Здесь вы можете настроить параметры компилятора для ASP.NET. Здесь вы можете использовать множество атрибутов, из которых наиболее распространенными являются
debugиdefaultLanguage. Установите для debug значение true, только если вы хотите, чтобы браузер отображал информацию об отладке. Поскольку включение этой опции снижает производительность, вы обычно хотите установить для нее значение «false».defaultLanguageсообщает ASP.NET, какой языковой компилятор использовать, поскольку вы можете использовать, например, Visual Basic .NET или C #. По умолчанию имеет значениеvb.
<customErrors>Чтобы предоставить вашим конечным пользователям настраиваемые, удобные для пользователя сообщения об ошибках, вы можете установить для атрибута mode этого раздела значение
On. Если вы установите для него значениеRemoteOnly, пользовательские ошибки будут отображаться только для удаленных клиентов, в то время как локальные пользователи хоста будут видеть уродливые, но полезные ошибки ASP.NET - очевидно, это полезно при отладке. Если для атрибута mode установлено значениеOffто ошибки ASP.NET будут отображаться всем пользователям.Если вы укажете относительный (например, /error404.html) или абсолютный адрес (http://yourdomain.com/error404.html) в
defaultRedirect, приложение будет автоматически перенаправлено на этот адрес в случае ошибки. Обратите внимание, что относительный адрес относится к местоположению файла Web.config, а не к странице, на которой происходит ошибка. Кроме того, вы можете использовать теги<error>для предоставленияstatusCodeи атрибутаredirect:
<customErrors mode="RemoteOnly" defaultRedirect="/error.html"> <error statusCode="403" redirect="/accessdenied.html" /> <error statusCode="404" redirect="/pagenotfound.html" /> </customErrors>
<globalization>Раздел глобализации полезен, когда вы хотите изменить кодировку или культуру вашего приложения. Глобализация - настолько обширная тема, что этому вопросу может быть посвящена целая статья. Короче говоря, этот раздел позволяет вам определить, какой набор символов сервер должен использовать для отправки данных клиенту (например, UTF-8, который используется по умолчанию), и какие настройки сервер должен использовать для интерпретации и отображения специфичных для данной культуры строк, такие как числа и даты.
<globalization requestEncoding="utf-8" responseEncoding="utf-8" culture="nl-NL" />
Кодирование осуществляется через атрибуты requestEncoding и responseEncoding . Значения должны быть одинаковыми во всех средах с одним сервером. В этом примере культура приложения установлена на голландский. Если вы не предоставите культуру, приложение будет использовать региональные настройки сервера.
<httpRuntime>
Вы можете использовать раздел httpRuntime для настройки ряда общих параметров времени выполнения, два из которых особенно удобны.
<httpRuntime appRequestQueueLimit="100" executionTimeout="600" />
Первый атрибут определяет количество запросов, которые сервер может поставить в очередь в памяти во время интенсивного трафика. В этом примере, если уже есть 100 запросов, ожидающих обработки, следующий запрос приведет к ошибке 503 («Сервер слишком занят»).
Атрибут executeTimeout указывает количество секунд, в течение которых ASP.NET может обработать запрос до истечения времени ожидания.
<sessionState>
В этом разделе файла Web.config мы сообщаем ASP.NET, где хранить состояние сеанса. По умолчанию используется сам процесс:
<sessionState mode="InProc" />
Переменные сессии очень мощные, но у них есть несколько недостатков. Информация теряется при сбое процесса ASP.NET, а сеансы, как правило, бесполезны в случае веб-фермы (несколько веб-серверов). В этом случае общий сервер сеансов может решить ваши проблемы. Расширение этой темы выходит за рамки этой статьи, но стоит упомянуть. Дополнительную информацию о sessionState можно найти в онлайн-библиотеке MSDN.
<trace>
trace.axd трассировки вашего приложения находится в корневой папке приложения под именем trace.axd . Вы можете изменить отображение информации о трассировке в разделе трассировки.
Атрибуты, которые вы будете искать изначально, включены: localOnly и pageOutput .
<trace enabled="true" localOnly="true" pageOutput="false" />
Установите для localOnly значение false, чтобы получить доступ к журналу трассировки с любого клиента. Если вы установите значение pageOutput в «true», информация о трассировке будет добавляться внизу каждой веб-страницы.
Группа appSettings
Помимо параметров конфигурации веб-сайта, о которых я говорил в предыдущих параграфах, вы будете знать, что программисту часто нравится использовать пользовательские константы всего приложения для хранения информации на нескольких страницах. Наиболее привлекательным примером такой пользовательской константы является строка подключения к базе данных, но вы, вероятно, можете думать о десятках других из вашего собственного опыта.
Общим знаменателем этих констант является то, что вы хотите программно извлекать их значения из вашего кода. Файл Web.config предоставляет возможность сделать это, но в качестве меры безопасности эти константы должны быть включены в группу <appSettings> . Как и <system.web> , <appSettings> является прямым дочерним тегом <appSettings> конфигурации Web.config.
Типичная группа пользовательских разделов будет выглядеть примерно так:
<appSettings> <add key="sqlConn" value="Server=myPc;Database=Northwind" /> <add key="smtpServer" value="smtp.mydomain.com" /> </appSettings>
Пример показывает, что ключи и значения могут быть включены в пользовательские настройки приложения с помощью <add> . Способ доступа к такому значению на любой из ваших веб-страниц показан ниже:
ConfigurationSettings.AppSettings("sqlConn")
Да, это так просто! Обратите внимание, что значением этих настроек всегда является строковый формат.
Несколько других вопросов
Я не буду вдаваться в них здесь, но файл Web.config может содержать несколько других групп разделов, кроме вышеупомянутых system.web и appSettings , таких как группа configSettings .
- Веб-приложение может содержать более одного файла Web.config. Параметры в файле применяются к каталогу, в котором он находится, и ко всем дочерним каталогам. Файлы Web.config в дочерних каталогах имеют приоритет над параметрами, указанными в родительских каталогах.
- Файлы Web.config защищены IIS, поэтому клиенты не могут получить к ним доступ. Если вы попытаетесь получить существующий файл http://mydomain.com/Web.config, вы увидите сообщение об ошибке «Отказано в доступе».
- IIS отслеживает изменения в файлах Web.config и кэширует их содержимое в целях повышения производительности. Нет необходимости перезапускать веб-сервер после изменения файла Web.config.
Заключительные замечания
В этой статье я коснулся возможностей, которые файл Web.config предлагает программисту ASP.NET. Вы можете использовать легкодоступный XML-файл для определения настроек приложения, не беспокоясь об использовании консоли управления IIS. С помощью файла Web.config ASP.NET позволяет добавлять, изменять и удалять основные параметры конфигурации, такие как аутентификация и авторизация, отображение пользовательских ошибок и прямое отслеживание.
Более того, файл Web.config предлагает вам пространство для определения любого пользовательского ключа, который вам требуется, например, строк подключения к базе данных. Впоследствии мы увидели, что с помощью всего одной строки кода вы можете получать необходимую информацию со всех страниц вашего приложения.