Любое веб-приложение в ASP.NET автоматически наследует базовые параметры из системного файла machine.config и корневого web.config. Однако разработчик не ограничен лишь общими настройками - он может гибко адаптировать поведение приложения под конкретные задачи. Например, вы можете задать особый тип аутентификации, включить режим отладки или настроить пользовательские страницы ошибок для отдельных разделов сайта. Для этого достаточно разместить дополнительный файл web.config в корне виртуального каталога вашего приложения. А чтобы настроить отдельные подкаталоги с уникальными параметрами, просто добавьте свои файлы конфигурации прямо в них.
Важно помнить о границах власти: web.config приложения не может переопределять абсолютно все настройки из machine.config. Некоторые критически важные параметры, такие как модель процессов, остаются неизменными для каждого приложения индивидуально. С другой стороны, существуют конфигурации, специфичные именно для веб-приложений - их можно задавать только в корне сайта, но не в подкаталогах.
Вся «магия» настройки ASP.NET происходит внутри корневого элемента configuration. В его сердце бьется элемент system.web, отвечающий за основные параметры фреймворка. Здесь же вы встретите appSettings - удобное место для хранения собственных ключей и значений, а также connectionStrings, где лежат строки подключения к базам данных, на которые опирается ваше приложение.
Посмотрим, как выглядит минимальный web.config, который Visual Studio создает для пустого сайта ASP.NET:
"?xml version="1.0"?
"configuration
system.web
compilation debug="true" targetFramework="4.0"/
/system.web
/configuration
Помните: как и в любом XML-документе, здесь критически важен регистр букв. Имена элементов пишутся в стиле CamelCase (начало с заглавной буквы). Если вы ошибетесь и напишете System.Web вместо system.web - система просто не поймет вас.
Раздел system.web является центральным узлом конфигурации ASP.NET. Именно здесь собраны все инструменты для настройки функциональности фреймворка. В большинстве проектов также активно используются appSettings для хранения служебной информации и connectionStrings для базы данных. Кроме того, через раздел system.webServer можно расширять конвейер запросов дополнительными обработчиками и модулями HTTP. Вот базовый каркас файла web.config:
configuration
appSettings /
connectionStrings /
system.web
!-- Разделы конфигурации ASP.NET --
/system.web
system.webServer/
/configuration
Структура конфигурации для ASP.NET 3.5 была несколько сложнее из-за особенностей релиза этой версии (комбинация модели 2.0 и набора расширений). Но в ASP.NET 4 ситуация упростилась: многие параметры переехали в machine.config и корневой web.config, сделав жизнь разработчика более предсказуемой.
Наследование конфигурации
ASP.NET использует элегантную многоуровневую систему конфигурации. Это позволяет применять разные правила к разным частям вашего приложения, создавая вложенные подкаталоги с собственными файлами web.config. Благодаря механизму наследования каждый такой подкаталог автоматически «унаследует» настройки родительского уровня, если не переопределит их явно.
Представьте запрос http://localhost/A/B/C/MyPage.aspx, где А - это корень приложения. Здесь вступают в силу правила нескольких уровней:
1. Сначала действуют глобальные параметры по умолчанию из machine.config.
2. Затем применяются настройки из корневого web.config сервера (того, что лежит рядом с machine.config в каталоге Config).
3. Если в корне приложения А есть свой web.config - его параметры имеют приоритет.
4. Далее идут настройки из подкаталога В (если там тоже лежит web.config).
5. И наконец, применяются параметры из самого глубокого вложенного каталога С.
Обратите внимание на эту цепочку: подкаталогов может быть сколько угодно, но шаги 1 и 2 фундаментальны. Некоторые параметры (например, учетная запись для выполнения кода) можно задать только в machine.config, а другие (типы аутентификации) - строго в корне приложения.
В подкаталогах вы можете менять лишь ограниченный набор настроек. Часто это делают ради безопасности: файлы, требующие защиты, помещают в отдельный каталог с web.config, который задает более строгие правила доступа, чем корневой.
При конфликте правил всегда побеждает тот файл web.config, что находится глубже (вложеннее). Но есть нюанс: можно заблокировать определенные параметры от переопределения. Об этом мы поговорим позже.
Если вы работаете с полноценным веб-проектом (а не просто сайтом), в нем будут лежать файлы web.Debug.config иweb.Release.config. Они помогают легко переключаться между настройками для отладки и продакшена. Но имейте в виду: при запуске приложения прямо из Visual Studio эти трансформации игнорируются.
Использование элементов location
Элемент location - это мощный инструмент, позволяющий определять группы настроек для разных путей прямо в одном файле. Атрибут path указывает, на какой каталог или файл действуют эти правила. Например, вы можете настроить отдельный блок параметров для подкаталога Secure:
configuration
system.web
!-- Параметры конфигурации --
/system.web
location path="/Secure"
system.web
!-- Параметры конфигурации для подкаталога Secure --
/system.web
/location
/configuration
По сути, такой файл заменяет два отдельных web.config - один для корня и один для Secure. Хотя обычно проще держать настройки в разных файлах ради удобства управления, location незаменим в одном случае - когда нужно заблокировать параметры от изменений.
Посмотрите на пример ниже: здесь задана группа параметров с атрибутом allowOverride, установленным в false:
configuration
system.web
!-- Параметры незащищенной конфигурации --
/system.web
location allowOverride="false"
system.web
!-- Параметры заблокированной конфигурации --
/system.web
/location
/configuration
В этом случае попытка переопределить эти настройки в нижележащих каталогах приведет к необработанному исключению ASP.NET. Это «жесткая» блокировка.
Атрибут allowOverride чаще всего используют хостеры, чтобы запретить клиентам менять критически важные настройки сервера. Администратору достаточно отредактировать machine.config и заблокировать нужные секции через location.
Заблокировать параметры можно для всех приложений (не указывая path) или только для конкретного сайта (указав его имя в path).
Внутри system.web собраны все ключевые настройки ASP.NET. Они управляют безопасностью, сессиями, трассировкой и многим другим. Структура этого раздела фиксирована - вы не можете добавить свои «костыльные» элементы, но внутри можно размещать множество стандартных секций.
Ниже представлен перечень основных дочерних элементов system.web с кратким описанием их роли:
Некоторые базовые разделы конфигурации system.Web |
| | |
| | Настройка механизма аутентификации - способа проверки identity пользователя при обращении к странице. |
| | Управление доступом: определяет, кто и к каким ресурсам приложения имеет право обращаться. |
| | Определяет целевую версию .NET (targetFramework), режим отладки (debug) и список дополнительных сборок (assemblies), доступных для приложения. |
| | Позволяет заменять стандартные страницы ошибок (например, 404) на дружелюбные для пользователя. В IIS 7.x эту функцию часто берет на себя раздел httpErrors. |
| | Конфигурация системы членства ASP.NET, которая управляет учетными записями пользователей и предоставляет API для входа/выхода. |
| | Задаёт параметры по умолчанию для веб-страниц, которые можно переопределить в каждой отдельной странице. |
| | Настройка системы профилей, автоматически сохраняющей персональные данные пользователей (часто в базе данных). |
| | Активация и настройка системы ролей ASP.NET для управления доступом на основе групп. |
| | Определяет, где и как хранятся данные сессии (в памяти, SQL Server или через отдельную службу). |
| | Включение и настройка трассировки для сбора диагностической информации. |
Помните, что архитектура конфигурационных файлов универсальна для всего .NET. Поэтому корневой элемент configuration не является «веб-специфичным» - все настройки именно веб-приложений живут внутри system.web.
Этот раздел влияет на поведение самого веб-сервера. Здесь через chandlers регистрируют HTTP-обработчики, а через modules - HTTP-модули.
Для хранения произвольных ключей-значений используется элемент appSettings. Это «карманный» раздел для любых строковых параметров.
Зачем он нужен? Чаще всего - чтобы вынести из кода жестко закодированные данные, которые могут меняться: пути к файлам, URL веб-сервисов или параметры подключения. Так как web.config можно редактировать без пересборки проекта, это очень удобно.
Параметры добавляются через элемент add, где вы указываете ключ (key) и значение (value). Пример:
configuration
appSettings
add key="websiteName" value="My New WebSite"/
add key ="welcomeMessage" value="Рад видеть вас на моем новом сайте!"/
/appSettings
/configuration
Получить эти значения в коде проще простого. Достаточно обратиться к статическому свойству AppSettings класса WebConfigurationManager (из пространства имен System.Web.Configuration). Это динамическая коллекция, которая объединяет настройки из всех уровней иерархии.
Например, если ваша страница находится в deep-каталоге, она автоматически увидит параметры из корня сайта. Для работы достаточно импортировать пространство имен:
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"];
}
Если ключа нет, метод вернет null. Поэтому перед использованием значения лучше всегда делать проверку на пустую ссылку.
Доступ к appSettings открыт для любого класса в вашем приложении - будь то UI-слой, бизнес-логика или работа с данными.
Здесь хранятся строки подключения к базам данных. Поскольку они используются часто и могут меняться (например, при миграции на новый сервер), логично держать их в конфигурации.
Можно добавить сколько угодно строк подключения. Для каждой необходимо указать имя и саму строку connection string. Пример:
connectionStrings
add name="NorthwindConnection"
connectionString="Data Source=MICROSOF-1EA29ESQLEXPRESS; AttachDbFilename=C:Northwind.mdf; Integrated Security=True"/
/connectionStrings
Для доступа к ним в коде используется коллекция WebConfigurationManager.ConnectionStrings.
Эта коллекция объединяет строки подключения из текущего web.config и всех родительских уровней. Благодаря этому автоматически доступен ключ LocalSqlServer, который указывает на локальный экземпляр SQL Server Express, поставляемый с Visual Studio.