Файл web.config

ASP.NET --- Основы ASP.NET --- Файл web.config

Каждое веб-приложение наследует параметры настройки из файла 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>

В этом разделе содержатся параметры, которые оказывают влияние на веб-сервер. Элемент <handlers> внутри этого раздела используется для регистрации специальных обработчиков 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-1EA29E\SQLEXPRESS; 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).