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

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

Все содержимое конфигурационного файла ASP.NET находится внутри корневого элемента configuration. Этот элемент содержит элемент system.web, который используется для параметров настройки ASP.NET. Внутри system.web находятся отдельные элементы для каждого аспекта конфигурации. Также имеется элемент appSettings, используемый для хранения специальных параметров, и элемент connectionStrings, применяемый для хранения строк подключения к базам данных, которые используете вы или на которые полагаются средства ASP.NET.

Ниже показано содержимое простейшего файла web.config, который получается при создании пустого веб-сайта ASP.NET в Visual Studio:

"?xml version="1.0"?

"configuration

system.web

compilation debug="true" targetFramework="4.0"/

/system.web

/configuration

Как и все XML-документы, содержимое файла web.config чувствительно к регистру символов. Каждый параметр использует стиль Camel и начинается с прописной буквы. Это означает, что записывать System.Web вместо system.web не допускается.

Раздел system.web играет центральную роль в конфигурации ASP.NET. Именно внутри него находятся все элементы, отвечающие за настройку функциональных средств ASP.NET. В большинстве приложений ASP.NET также используется раздел appSettings для хранения разнообразных конфигурационных деталей, касающихся самого приложения, и раздел connectionStrings для хранения строк подключения к базе данных. Кроме того, с помощью раздела system.webServer можно расширять конвейер ASP.NET дополнительными обработчиками и модулями HTTP. Нижепоказанбазовыйскелетфайла web.config:

configuration

appSettings /

connectionStrings /

system.web

!-- Разделы конфигурации ASP.NET --

/system.web

system.webServer/

/configuration

Конфигурационный файл для приложений ASP.NET 3.5 имеет более сложную структуру из-за способа, которым ASP.NET 3.5 была выпущена. По сути, ASP.NET 3.5 представляет собой комбинацию, которая состоит из базовой модели ASP.NET 2.0, со средой CLR 2.0, и набора расширений. Как результат, каждое приложение использует файл web.config для подключения новых средств. Однако в ASP.NET 4 такой подход не применяется, и приложения ASP.NET имеют более простое и понятное содержимое. Дополнительные параметры настройки были перемещены в файл machine.config и корневой файл web.config, где им самое место.

Наследование конфигурации

В ASP.NET используется многоуровневая система конфигурации, которая позволяет применять различные параметры к разным частям приложения. Данный прием требует создания внутри виртуального каталога дополнительных подкаталогов. Эти подкаталоги могут содержать собственные файлы web.config с дополнительными параметрами настройки. ASP.NET использует наследование конфигурации, благодаря которому каждый подкаталог автоматически получает параметры настройки родительского каталога.

Например, рассмотрим веб-запрос http://localhost/A/B/C/MyPage.aspx, где А представляет корневой каталог веб-приложения. Этот запрос подразумевает использование параметров на множестве уровней:

1. Сначала применяются используемые по умолчанию параметры из файла machine.config.

2. Далее применяются параметры из файла web.config, находящегося в корневом каталоге компьютера. Этот файл web.config хранится в том же каталоге Config, что и файл machine.config.

3. Если в корневом каталоге приложения А имеется файл web.config, тогда следующими применяются параметры, указанные в нем.

4. Если в подкаталоге В имеется файл web.config, тогда следующими применяются параметры, указанные в этом файле.

5. Если в подкаталоге С есть файл web.config, тогда напоследок применяются параметры из него.

этой последовательности, показанной на рисунке, важно обратить внимание, что подкаталогов может быть сколько угодно, но параметры, применяемые в шагах 1 и 2, имеют особое значение. Причина в том, что некоторые параметры (такие как учетная запись Windows, используемая для выполнения кода) могут применяться только на уровне machine.config, а некоторые (вроде типа аутентификации, используемого веб-приложением) - только на уровне корневого каталога приложения.

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

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

Если вы разрабатываете веб-проект (а не беспроектный веб-сайт), в состав этого проекта будут также включены файлы web.Debug.config иweb.Release.config. Эти файлы предназначены для переключения между параметрами, используемыми при тестировании веб-приложения, и параметрами, которые необходимы во время его развертывания в производственной среде. Однако они не дают никакого эффекта при запуске приложения в Visual Studio, поскольку в этом случае они полностью игнорируются.

Использование элементов location

Элемент location является расширением, позволяющим определять несколько групп параметров настройки в одном конфигурационном файле. Чтобы определить подкаталог или файл, к которому будут применены параметры настройки, нужно использовать атрибут path в элементе location. Например, в следующем файле web.config элемент location применяется для создания двух групп параметров настройки - для текущего каталога и для подкаталога Secure:

configuration

system.web

!-- Параметры конфигурации --

/system.web

location path="/Secure"

system.web

!-- Параметры конфигурации для подкаталога Secure --

/system.web

/location

/configuration

Этот файл web.config, по сути, играет роль двух конфигурационных файлов. Он приводит к такому же результату, как если бы вы разделили параметры настройки на два отдельных файла web.config и поместили их в подкаталог Secure.

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

Чтобы получить представление о работе этой технологии, рассмотрим приведенный ниже пример. В нем определены две группы параметров настройки, для одной из которых атрибут allowOverride дескриптора location устанавливается в false:

configuration

system.web

!-- Параметры незащищенной конфигурации --

/system.web

location allowOverride="false"

system.web

!-- Параметры заблокированной конфигурации --

/system.web

/location

/configuration

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

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

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

Элемент system.web

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

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

Архитектура конфигурационного файла является стандартом .NET, и приложения другого типа (например, приложения для Windows) тоже могут использовать конфигурационные файлы. По этой причине корневой элемент configuration не предназначен для параметров настройки веб-приложения. Вместо этого параметры настройки веб-приложения содержатся внутри выделенного раздела system.web.

Раздел system.webserver

В этом разделе содержатся параметры, которые оказывают влияние на веб-сервер. Элемент chandlers внутри этого раздела используется для регистрации специальных обработчиков HTTP, а раздел modules - для регистрации модулей HTTP.

Раздел appSettings

Специальные параметры настройки в файле web.config добавляются в элемент appSettings. Все добавляемые специальные параметры записываются в виде простых строковых переменных.

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

Специальные параметры вводятся с использованием элемента add, который идентифицирует уникальное имя переменной (ключ) и ее содержимое (значение). Ниже приведен пример добавления двух новых специальных параметров настройки:

configuration

appSettings

add key="websiteName" value="My New WebSite"/

add key ="welcomeMessage" value="Рад видеть вас на моем новом сайте!"/

/appSettings

/configuration

После добавления такой информации .NET позволяет чрезвычайно легко извлекать ее в коде веб-страниц. Все, что понадобится - это просто использовать класс WebConfigurationSettings, который находится в пространстве имен System.Web.Configuration. Этот класс предоставляет статическое свойство AppSettings, в котором содержится динамически генерируемая коллекция всех доступных в текущем каталоге параметров приложения.

Например, если класс страницы ASP.NET, ссылающийся на коллекцию AppSettings, находится в http://localhost/MyApp/MyDirectory/MySubdirectory, то в коллекции AppSettings, вероятно, будут содержаться параметры настройки из трех разных файлов web.config. Коллекция AppSettings делает такую иерархию параметров бесшовной для страницы, которая ее использует.

Для использования класса WebConfigurationSettings сначала необходимо импортировать пространство имен System.Web.Configuration, чтобы иметь возможность ссылаться на этот класс, не указывая его длинное полностью уточненное имя:

using System.Web.Configuration;

Далее останется просто извлечь требуемое значение по имени:

protected void Page_Load(object sender, EventArgs e)

{

this.Header.Title = WebConfigurationManager.AppSettings["websiteName"];

txtHeader.Text = Header.Title;

txt1.Text = WebConfigurationManager.AppSettings["welcomeMessage"];

}

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

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

Раздел connectionStrings

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

Строк соединения можно добавлять столько, сколько необходимо. Для каждой из них должно быть указано имя поставщика ADO.NET. Ниже показан пример определения единственной строки соединения:

connectionStrings

add name="NorthwindConnection"

connectionString="Data Source=MICROSOF-1EA29ESQLEXPRESS; AttachDbFilename=C:Northwind.mdf; Integrated Security=True"/

/connectionStrings

Дляизвлечениястроксоединениявкодеслужитстатическоесвойство WebConfigurationManager.ConnectionStrings.

Коллекция ConnectionStrings включает в себя строки соединения, которые были определены как непосредственно в файле web.config, так и в конфигурационных файлах более высокого уровня (а именно - в корневом файле web.config и файле machine.config). Это означает, что вы автоматически получаете строку соединения по имени LocalSqlServer, которая указывает на локальный экземпляр SQL Server Express (который представляет собой сокращенную версию SQL Server и включен в состав Visual Studio).