ASP.NET MVC. Конфигурационный файл Web.config. Часть 1. Основные сведения
Web.config – это конфигурационный файл, в котором хранятся все настройки и отдельные параметры веб-приложения.
Расположение файла Web.config
Это не просто важный, это обязательный файл для работы любого приложения. Web.config представляет собой файл, содержащий разметку формата XML. Другими словами – это обычный XML-документ. Все настройки логически разделены на группы. Каждая группа отвечает за настройку какой-то части приложения, либо за настройку веб-сервера, который обслуживает наше приложение. Уже внутри групп расположены отдельные секции, представляющие ту или иную настройку.
Группы и секции в файле Web.config
- централизованное место для всех настроек в приложении
- приложение можно настроить максимально гибко и полно
- возможность описать собственные настройки, характерные для текущего проекта
- позволяет избежать проблемы жестко закодированных параметров в коде приложения
- при изменении настроек нет необходимости перекомпилировать код
- файл в формате стандарта XML
Чаще всего, при разработке типовых веб-приложений разработчики используют только один файл Web.config, расположенный на уровне текущего проекта. Однако этот файл является лишь частью целой иерархии конфигурационных файлов, которые использует в своей работе среда ASP.NET. Давайте посмотрим на всю цепочку файлов, составляющих эту иерархию:
Machine.config – самый первый и главный файл в иерархии. В нем определены основные настройки для среды ASP.NET, которые будут использоваться на данном физическом сервере.
Web.config – базовая версия этого файла. Здесь описаны значения по умолчанию для многих компонентов ASP.NET. Этот файл дополняет и расширяет файл machine.config, он располагается в той же директории.
ApplicationHost.config – в этом файле определены настройки а также значения по умолчанию для веб-сервера IIS (IIS Express), на котором будут работать все веб-приложения.
Web.config – версия файла для сайта IIS. В данном случае под сайтом понимается иерархия директорий, которая может включать в себя множество веб-приложений. Для всех приложений в конкретном сайте можно определить общие настройки через этот файл.
Web.config – версия файла для настройки конкретного веб-приложения. Именно этот файл чаще всего используется программистами в процессе работы.
Web.config – версия файла, расположенная в поддиректории текущего проекта. Здесь описаны настройки, актуальные для данной части веб-приложения. Например, файл web.config в папке Views определяет по умолчанию движок Razor для работы с представлениями.
Иерархия конфигурационных файлов .config
Стандартное расположение файлов Machine.config и Web.config:
C:\Windows\Microsoft.NET\Framework\
Стандартное расположение файла ApplicationHost.config:
C:\Users\
Таким образом, общая конфигурационная модель, которая используется для правильной работы не только нашего отдельного веб-приложения, но и всей платформы ASP.NET на сервере, а также самого сервера, состоит из нескольких дополняющих друг друга конфигурационных файлов. Группа этих файлов представляет собой некую иерархию, где на верхнем уровне определены базовые и самые основные настройки сервера и среды ASP.NET, а вниз по цепочке большинство (не все) этих настроек можно переопределить либо расширить для правильной работы отдельных веб-приложений.
Благодаря такой системе в файле Web.config уровня приложения записано лишь несколько десятков строк кода, подавляющее большинство настроек определено уровнями выше по иерархии.
В подавляющем большинстве случаев, при разработке типовых ASP.NET приложений, нет необходимости менять стандартные настройки config-файлов в иерархии вплоть до Web.config файла уровня приложения. Именно через этот файл происходит полная настройка приложения.
В момент запуска приложения все эти настройки соединяются воедино и кэшируются для большего быстродействия. Далее в процессе работы система отслеживает состояние файла Web.config на случай его изменения. Если изменения произошли, и конфигурационный файл был обновлен, тогда сервер дожидается корректной отработки действующих http-запросов, и веб-приложение перезагружается уже в новой конфигурации.
Ну и также замечу, что почти вся информация, которую мы сейчас узнали о конфигурационных файлах .config, актуальна и для других типов приложений, например, для приложений консольного типа. Только там конфигурационный файл для настройки приложения будет называться App.config. Поэтому если вы разрабатываете приложения другого типа, это информация вам также будет полезна.
Во второй части урока мы посмотрим, как работать с файлом Web.config, изменять настройки приложения, получать доступ к настройкам, чтобы использовать их где-то в коде приложения, а также научимся придумывать и добавлять свои собственные настройки.
Создание файла Web.config для приложения ASP.NET
В этой статье описывается создание файлаWeb.config , который используется для управления поведением отдельных ASP.NET приложений.
Исходная версия продукта: ASP.NET
Исходный номер базы знаний: 815179
Сводка
Microsoft платформа .NET Framework и, в частности, ASP.NET, использует файлы .config в формате XML для настройки приложений. Эта практика является отходом от обычных механизмов конфигурации реестра и метабазы. В настоящее время нет оснастки консоли управления (MMC) или другого средства администрирования, предоставляемого Корпорацией Майкрософт, которое можно использовать для создания и изменения .config файлов.
Иерархия файлов .config
Платформа .NET Framework использует .config файлы для определения параметров конфигурации. Файлы .config являются текстовыми XML-файлами. В одной системе может существовать несколько файлов .config.
Параметры конфигурации на уровне системы для платформа .NET Framework определяются в файлеMachine.config. Файл Machine.config находится в папке %SystemRoot%\Microsoft.NET\Framework\%VersionNumber%\CONFIG\ . Параметры по умолчанию, содержащиеся в файлеMachine.config , можно изменить, чтобы повлиять на поведение приложений Microsoft .NET во всей системе.
Вы можете изменить параметры конфигурации ASP.NET для одного приложения, создав файлWeb.config в корневой папке приложения. При этом параметры в файлеWeb.config переопределяют параметры в файлеMachine.config .
Создание файла Web.config
Файл Web.config можно создать с помощью текстового редактора, например Блокнота. Необходимо создать текстовый файл с именемWeb.config в корневом каталоге приложения ASP.NET. ФайлWeb.config должен быть хорошо сформированным XML-документом и иметь формат, аналогичный файлу %SystemRoot%\Microsoft.NET\Framework\%VersionNumber%\CONFIG\Machine.config .
Файл Web.config должен содержать только записи для элементов конфигурации, которые переопределяют параметры в файлеMachine.config . Как минимум, Web.config файл должен содержать элемент и элемент . Эти элементы будут содержать отдельные элементы конфигурации.
В следующем примере показан файл с минимальным Web.config .
В первой строке файла Web.config документ описывается в формате XML и указывается тип кодировки символов. Первая строка должна быть одинаковой для всех файлов .config.
Следующие строки помечают начало и конец элемента и
Ссылки
- Конфигурация ASP.NET
- Формат файлов конфигурации ASP.NET
- Изменение конфигурации приложения ASP.NET
Файл web.config
web.config — это файл, который считывается службами IIS и модулем ASP.NET Core для настройки приложения, размещенного в службах IIS.
Расположение файла web.config
Для корректной настройки модуля ASP.NET Core необходимо наличие файла web.config в корневой папке содержимого развертываемого приложения (как правило, это основной путь приложения). Это расположение соответствует физическому пути веб-сайта, указанному в службах IIS. Файл web.config требуется в корне приложения, чтобы включить публикацию нескольких приложений с помощью веб-развертывания.
По физическому пути приложения находятся файлы с конфиденциальной информацией, например, .runtimeconfig.json , .xml (комментарии к XML-документации) и .deps.json , где заполнитель представляет собой имя сборки. web.config Когда файл присутствует и сайт запускается обычно, службы IIS не обслуживает эти конфиденциальные файлы, если они запрашиваются. web.config Если файл отсутствует, неправильно назван или не удается настроить сайт для нормального запуска, службы IIS могут предоставлять конфиденциальные файлы общедоступным образом.
Файл web.config должен постоянно присутствовать в развертывании, а также иметь правильное имя и возможность настроить сайт для нормального запуска. Никогда не удаляйте файл web.config из развертывания в рабочей среде.
Если в проекте нет файла web.config , он создается с правильными processPath и arguments для настройки модуля ASP.NET Core и переносится в опубликованные выходные данные.
web.config Если файл присутствует в проекте, файл преобразуется правильно и arguments настраивается processPath ASP.NET основной модуль и перемещается в опубликованные выходные данные. Преобразование не изменяет параметры конфигурации служб IIS, включенные в файл.
Файл web.config может предоставить дополнительные параметры конфигурации IIS, которые управляют активными модулями IIS. Сведения о модулях IIS, которые могут обрабатывать запросы к приложениям ASP.NET Core, см. в статье Модули IIS.
Создание, преобразование и публикация web.config файла обрабатывается целевым объектом MSBuild ( _TransformWebConfig ) при публикации проекта. Этот целевой объект присутствует в целевых веб-пакетах SDK ( Microsoft.NET.Sdk.Web ). Пакет SDK задается в начале файла проекта:
Чтобы веб-пакет SDK не преобразовывал файл web.config , используйте свойство в файле проекта:
true
При отключении веб-пакета SDK от преобразования файла processPath необходимо arguments вручную задать разработчиком. Дополнительные сведения см. в разделе Модуль ASP.NET Core для IIS.
Настройка модуля ASP.NET Core с помощью web.config
Модуль ASP.NET Core настроен с aspNetCore разделом system.webServer узла в файле сайта web.config .
Следующий файл web.config публикуется для зависимого от платформы развертывания и настраивает модуль ASP.NET Core для обработки запросов к сайту.
Следующий файл web.config опубликован для автономного развертывания.
Когда приложение развернуто в службе приложений Azure, путь stdoutLogFile задан как \\?\%home%\LogFiles\stdout . Путь сохраняет журналы stdout в LogFiles папку, которая является автоматически созданным службой расположением.
Сведения о конфигурации дочерних приложений IIS см. в разделе Расширенные конфигурации.
Атрибуты элемента aspNetCore
Необязательный строковый атрибут.
Аргументы исполняемого файла, указанного в processPath .
Дополнительный логический атрибут.
Если значение равно true, страница 502.5 — ошибка процесса подавляется, и страница с кодом состояния 502, настроенная в web.config , имеет более высокий приоритет.
Дополнительный логический атрибут.
Если значение равно true, маркер безопасности отправляется дочернему процессу, прослушивающему порт %ASPNETCORE_PORT% , как заголовок MS-ASPNETCORE-WINAUTHTOKEN каждого запроса. Этот процесс вызывает CloseHandle по этому маркеру безопасности каждого запроса.
Необязательный строковый атрибут.
Указывает модель размещения — внутри процесса ( InProcess / inprocess ) или вне процесса ( OutOfProcess / outofprocess ).
Необязательный целочисленный атрибут.
Указывает количество экземпляров процесса, указанного в параметре processPath , который можно спрягать на каждое приложение.
†Для внутрипроцессного размещения установлено ограничение 1 .
Параметр processesPerApplication не рекомендуется. Этот атрибут будет удален в будущем выпуске.
Обязательный строковый атрибут.
Путь к исполняемому файлу, который запускает процесс прослушивания HTTP-запросов. Поддерживаются относительные пути. Если путь начинается с . , то начало пути считается относительно корневого каталога веб-сайта.
Необязательный целочисленный атрибут.
Указывает количество раз, когда указанный в processPath нем процесс может завершиться сбоем в минуту. Если этот предел превышен, модуль останавливает запуск процесса на оставшуюся часть минуты.
Не поддерживается для внутрипроцессного размещения.
Необязательный атрибут timespan.
Указывает продолжительность, на протяжении которой модуль ASP.NET Core ожидает ответа от процесса, прослушивающего порт %ASPNETCORE_PORT%.
В версиях модуля ASP.NET Core, поставляемых с выпуском ASP.NET Core 2.1 или новее, атрибут requestTimeout указывается в часах, минутах и секундах.
Не применяется к внутрипроцессному размещению. Для внутрипроцессного размещения модуль ожидает, пока приложение не обработает запрос.
Допустимые значения для сегментов минут и секунд в строках находятся в диапазоне 0–59. Использование значения 60 для минут и секунд приведет к ошибке 500 — Internal Server Error (внутренняя ошибка сервера).
Необязательный целочисленный атрибут.
Длительность в секундах, когда модуль ожидает правильного завершения работы исполняемого файла при обнаружении app_offline.htm файла.
Необязательный целочисленный атрибут.
Время в секундах, которое модуль ожидает, пока запустится процесс прослушивания порта исполняемого файла. Если этот предел превышен, модуль завершает процесс.
Внутрипроцессное размещение. Процесс не перезапускается и не использует параметр rapidFailsPerMinute .
Внепроцессное размещение. Модуль пытается перезапустить процесс, когда он получает новый запрос, и продолжает попытки перезапустить процесс при последующих входящих запросах, если только приложению не удастся запустится определенное количество раз ( rapidFailsPerMinute ) за последнюю минуту.
Значение 0 (ноль) не считается бесконечным временем ожидания.
Дополнительный логический атрибут.
Если значение true, а stderr для процесса, stdout указанного в processPath , перенаправляется в файл, указанный в stdoutLogFile .
Необязательный строковый атрибут.
Указывает относительный или абсолютный путь к файлу, для которого stdout и stderr из процесса, указанного в processPath журнале. Относительные пути задаются относительно корневого каталога веб-сайта. Любой путь, начинающийся с . , относится к корневому каталогу веб-сайта, а все остальные пути рассматриваются как абсолютные пути. Все папки, указанные в пути, создаются модулем при создании файла журнала. Использование разделителей подчеркивания, метки времени, идентификатора процесса и расширения файла ( .log ) добавляются в последний сегмент stdoutLogFile пути. Если в качестве значения задано значение .\logs\stdout , например, журнал stdout сохраняется как stdout_20180205194132_1934.log в папке logs с датой 5 февраля 2018 г. в 19:41:32 с идентификатором процесса 1934.
Настройка переменных среды
Переменные среды для процесса можно указать в атрибуте processPath . Укажите переменную среды с дочерним элементом элемента коллекции . Переменные среды, установленные в этом разделе, имеют приоритет над переменными системной среды.
В приведенном ниже примере устанавливаются две переменные среды в web.config . ASPNETCORE_ENVIRONMENT настраивает среду приложения для Development . Разработчик может временно задать это значение в файле web.config , чтобы принудительно загрузить страницу исключений для разработчиков при отладке исключения приложения. CONFIG_DIR — пример пользовательской переменной среды, где разработчик написал код, который считывает значение при запуске, чтобы сформировать путь для загрузки файла конфигурации приложения.
Вместо установки среды напрямую в web.config можно включить свойство в профиль публикации ( .pubxml ) или файл проекта. Этот подход задает среду при web.config публикации проекта:
Development
Установите только переменную среды ASPNETCORE_ENVIRONMENT для Development на серверах промежуточных процессов и тестирования, которые недоступны для ненадежных сетей, таких как Интернет.
Настройка служб IIS с помощью web.config
Конфигурация IIS зависит от раздела web.config сценариев IIS, которые работают для приложений ASP.NET Core с помощью модуля ASP.NET Core. Например, конфигурация IIS работает для динамического сжатия. Если службы IIS настроены на уровне сервера для использования динамического сжатия, элемент в файле приложения web.config может отключить его для приложения ASP.NET Core.
Дополнительные сведения см. в следующих разделах:
- Справочник по настройке для
- модуль ASP.NET Core (ANCM) для IIS
- Модули IIS с ASP.NET Core
Сведения о настройке переменных среды для отдельных приложений, выполняющихся в изолированных пулах приложений (такая возможность поддерживается в службах IIS, начиная с версии 10.0), см. в разделе Команда AppCmd.exe статьи Переменные среды в справочной документации по службам IIS.
Разделы конфигурации web.config
Разделы конфигурации приложений web.config ASP.NET 4.x не используются приложениями ASP.NET Core для настройки:
Для настройки приложений ASP.NET Core используются другие поставщики конфигураций. Дополнительные сведения см. в статье Конфигурация.
Преобразование web.config
Если вам нужно преобразовать web.config при публикации, см. статью Преобразование web.config. Возможно, вам потребуется выполнить преобразование web.config при публикации, чтобы задать переменные среды на основе конфигурации, профиля или среды.
Дополнительные ресурсы
- Службы IIS
- Модули IIS с ASP.NET Core
- Преобразование web.config
Совместная работа с нами на GitHub
Источник этого содержимого можно найти на GitHub, где также можно создавать и просматривать проблемы и запросы на вытягивание. Дополнительные сведения см. в нашем руководстве для участников.
Файл web.config
Каждое веб-приложение наследует параметры настройки из файла machine.config и корневого файла web.config. Кроме того, параметры могут применяться к отдельным веб-приложениям. Например, в веб-приложении может быть предусмотрен специфический метод аутентификации, тип отладки, язык по умолчанию или специальные страницы сообщений об ошибках. Чтобы сделать это, понадобится добавить в корневой виртуальный каталог своего веб-приложения файл web.config. Для конфигурирования отдельных подкаталогов в веб-приложении в них следует поместить дополнительные файлы web.config.
Важно понимать, что файл web.config в веб-приложении не может переопределять все параметры в файле machine.config. Некоторые параметры в этом файле, такие как параметры модели процессов, не могут изменяться для каждого приложения отдельно. Другие параметры, наоборот, являются специфичными для приложений. Это значит, что их можно устанавливать в файле web.config, который находится в корневом виртуальном каталоге веб-сайта, но нельзя в файлах web.config, расположенных в подкаталогах.
Все содержимое конфигурационного файла ASP.NET находится внутри корневого элемента . Этот элемент содержит элемент , который используется для параметров настройки ASP.NET. Внутри находятся отдельные элементы для каждого аспекта конфигурации. Также имеется элемент , используемый для хранения специальных параметров, и элемент , применяемый для хранения строк подключения к базам данных, которые используете вы или на которые полагаются средства ASP.NET.
Ниже показано содержимое простейшего файла web.config, который получается при создании пустого веб-сайта ASP.NET в Visual Studio:
Как и все XML-документы, содержимое файла web.config чувствительно к регистру символов. Каждый параметр использует стиль Camel и начинается с прописной буквы. Это означает, что записывать вместо не допускается.
Раздел играет центральную роль в конфигурации ASP.NET. Именно внутри него находятся все элементы, отвечающие за настройку функциональных средств ASP.NET. В большинстве приложений ASP.NET также используется раздел для хранения разнообразных конфигурационных деталей, касающихся самого приложения, и раздел для хранения строк подключения к базе данных. Кроме того, с помощью раздела можно расширять конвейер ASP.NET дополнительными обработчиками и модулями HTTP. Ниже показан базовый скелет файла web.config:
Конфигурационный файл для приложений 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, где А представляет корневой каталог веб-приложения. Этот запрос подразумевает использование параметров на множестве уровней:
- Сначала применяются используемые по умолчанию параметры из файла machine.config.
- Далее применяются параметры из файла web.config, находящегося в корневом каталоге компьютера. Этот файл web.config хранится в том же каталоге Config, что и файл machine.config.
- Если в корневом каталоге приложения А имеется файл web.config, тогда следующими применяются параметры, указанные в нем.
- Если в подкаталоге В имеется файл web.config, тогда следующими применяются параметры, указанные в этом файле.
- Если в подкаталоге С есть файл web.config, тогда напоследок применяются параметры из него.
этой последовательности, показанной на рисунке, важно обратить внимание, что подкаталогов может быть сколько угодно, но параметры, применяемые в шагах 1 и 2, имеют особое значение. Причина в том, что некоторые параметры (такие как учетная запись Windows, используемая для выполнения кода) могут применяться только на уровне machine.config, а некоторые (вроде типа аутентификации, используемого веб-приложением) — только на уровне корневого каталога приложения.
Благодаря этому, на уровне подкаталогов может быть указан лишь небольшой набор параметров, отличающихся от остальных параметров веб-приложения. Одной из причин использования в приложении множества подкаталогов является необходимость применять отличающиеся параметры безопасности. Файлы, нуждающиеся в защите, затем могут быть помещены в специальный каталог с файлом web.config, который определяет более строгие параметры безопасности, чем в корневом виртуальном каталоге.
Если возникает конфликт, параметры из файла web.config, находящегося во вложенном каталоге, всегда переопределяют те, что унаследованы от родителя. Однако существует одно исключение. Можно назначить специальные заблокированные разделы параметров, которые изменять нельзя. Этот прием более подробно описан в следующем разделе.
Если вы разрабатываете веб-проект (а не беспроектный веб-сайт), в состав этого проекта будут также включены файлы web.Debug.config и web.Release.config. Эти файлы предназначены для переключения между параметрами, используемыми при тестировании веб-приложения, и параметрами, которые необходимы во время его развертывания в производственной среде. Однако они не дают никакого эффекта при запуске приложения в Visual Studio, поскольку в этом случае они полностью игнорируются.
Использование элементов
Элемент является расширением, позволяющим определять несколько групп параметров настройки в одном конфигурационном файле. Чтобы определить подкаталог или файл, к которому будут применены параметры настройки, нужно использовать атрибут path в элементе . Например, в следующем файле web.config элемент применяется для создания двух групп параметров настройки — для текущего каталога и для подкаталога Secure:
Этот файл web.config, по сути, играет роль двух конфигурационных файлов. Он приводит к такому же результату, как если бы вы разделили параметры настройки на два отдельных файла web.config и поместили их в подкаталог Secure.
В одном конфигурационном файле может находиться сколько угодно различных элементов . Однако элемент часто не используется, поскольку гораздо проще управлять и обновлять параметры настройки конфигурации, когда они разделены на отдельные файлы. Тем не менее, существует один сценарий, в котором элемент обеспечивает функциональность, которую не удастся получить каким-либо другим способом. Это необходимо тогда, когда требуется заблокировать специфические параметры настройки таким образом, чтобы их нельзя было переопределить.
Чтобы получить представление о работе этой технологии, рассмотрим приведенный ниже пример. В нем определены две группы параметров настройки, для одной из которых атрибут allowOverride дескриптора устанавливается в false:
В этом случае переопределить какие-либо параметры настройки в разделе не получится. Если вы попытаетесь это сделать, ASP.NET сгенерирует необработанное исключение при запросе страницы в веб-приложении.
Атрибут allowOverride элемента предназначен в основном для компаний, занимающихся веб-хостингом, которым нужно защитить некоторые параметры настройки от изменения. В этом случае администратору придется модифицировать файл machine.config на веб-сервере и использовать элемент для блокировки различных разделов.
При блокировании параметров настройки в файле machine.config возможны два варианта: первый — заблокировать параметры сразу для всех приложений, опустив в дескрипторе атрибут path, а второй — заблокировать параметры только для конкретного приложения, указав в атрибуте path имя соответствующего веб-приложения.
Элемент
В элементе содержатся все конфигурационные параметры, касающиеся ASP.NET. Эти параметры отвечают за настройку различных аспектов веб-приложения и включают разные службы, такие как безопасность, управление состоянием и трассировка. Схема раздела является фиксированной, т.е. изменять структуру и добавлять собственные элементы нельзя. Однако можно включать сколько угодно конфигурационных разделов.
В таблице ниже перечислены основные дочерние элементы, которые могут присутствовать в , с описанием их назначения. Данный список является далеко не полным и предназначен для предоставления лишь общей картины о масштабах конфигурации ASP.NET:
Элемент | Описание |
---|---|
authentication | Этот элемент конфигурирует систему аутентификации — другими словами, он определяет, как будут проверяться идентификационные данные клиента, когда он запрашивает страницу |
authorization | Этот элемент управляет тем, каким клиентам должен предоставляться доступ к ресурсам, находящимся внутри веб-приложения или текущего каталога |
compilation | Этот элемент идентифицирует версию .NET, на которую ориентировано веб-приложение (посредством атрибута targetFramework) и указывает, должны ли генерироваться символы отладки в файлах .pdb (через атрибут debug), чтобы можно было отлаживать приложение с помощью инструмента, подобного Visual Studio. Этот элемент также может содержать элемент , в котором перечисляются дополнительные сборки, необходимые для веб-приложения. Эти сборки затем делаются доступными для кода (при условии, что их удается обнаружить в каталоге Bin или в GAC) |
customErrors | Этот элемент позволяет указывать специфичные URL-адреса, которые должны использоваться для переадресации в случае возникновения определенных (или стандартных) ошибок. Например, он может использоваться для перенаправления пользователя с неприглядной страницы ошибки 404 (page not found — страница не найдена) на более дружественную по отношению к пользователю страницу. Хотя этот параметр работает с встроенным тестовым веб-сервером Visual Studio, в IIS 7.x он заменен разделом |
membership | Этот элемент позволяет конфигурировать систему членства ASP.NET, которая управляет информацией пользовательских учетных записей и предоставляет высокоуровневый API-интерфейс для решения связанных с безопасностью задач, таких как вход пользователя в систему и переустановка пароля |
pages | Этот элемент позволяет определять параметры, которые должны использоваться для страниц по умолчанию (большинство из которых может быть переопределено с помощью директивы Page) |
profile | Этот элемент позволяет конфигурировать систему профилей ASP.NET, которая автоматически сохраняет и извлекает информацию по конкретному пользователю (обычно параметры профиля). Как правило, данные профилей сериализуются в базу данных |
roleManager | Этот элемент позволяет конфигурировать систему безопасности на основе ролей ASP.NET, которая предоставляет способ сохранения информации о ролях и высокоуровневый API-интерфейс для авторизации на основе ролей |
sessionState | Этот элемент конфигурирует различные опции, касающиеся обслуживания состояния сеанса для приложения, такие как, должно ли оно вообще поддерживаться, и если да, то где (в SQL, отдельная служба Windows и т.д.) |
trace | Этот элемент конфигурирует трассировку, т.е. средство ASP.NET, которое позволяет отображать диагностическую информацию на странице (или собирать ее для отдельного просмотра) |
Архитектура конфигурационного файла является стандартом .NET, и приложения другого типа (например, приложения для Windows) тоже могут использовать конфигурационные файлы. По этой причине корневой элемент не предназначен для параметров настройки веб-приложения. Вместо этого параметры настройки веб-приложения содержатся внутри выделенного раздела .
Раздел
В этом разделе содержатся параметры, которые оказывают влияние на веб-сервер. Элемент внутри этого раздела используется для регистрации специальных обработчиков HTTP, а раздел — для регистрации модулей HTTP.
Раздел
Специальные параметры настройки в файле web.config добавляются в элемент . Все добавляемые специальные параметры записываются в виде простых строковых переменных.
Необходимость использовать в файле web.config специальные параметры может возникать по нескольким причинам. Чаще всего это требуется, когда нужно записать жестко закодированную, но изменяемую информацию для подключения к внешним источникам, например, строки запросов к базе данных, пути к файлам и URL-адреса веб-служб. Конфигурационный файл web.config может изменяться в любое время, что позволяет обновлять конфигурацию приложения по мере изменения характеристик его физического размещения, не компилируя его при этом заново.
Специальные параметры вводятся с использованием элемента , который идентифицирует уникальное имя переменной (ключ) и ее содержимое (значение). Ниже приведен пример добавления двух новых специальных параметров настройки:
После добавления такой информации .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)
Ниже показана тестовая веб-страница в действии:
В данном случае при попытке извлечь несуществующее значение никакой ошибки не возникает. Если есть подозрение, что это может стать источником проблем, тогда перед извлечением значения позаботьтесь о проверке на предмет наличия нулевой ссылки.
Значения, содержащиеся в элементе конфигурационного файла, доступны любому классу в приложении, а также любому компоненту, который в нем используется, будь то класс веб-формы, класс бизнес-логики, класс доступа к данным или что-нибудь еще. Во всех этих случаях класс ConfigurationSettings используется абсолютно одинаково.
Раздел
Этот раздел позволяет определять строки соединения с базой данных, которые будут использоваться где-нибудь в приложении. Поскольку строки соединения точно будут использоваться многократно для поддержки пула соединений и, скорее всего, понадобится возможность модифицировать их без повторной компиляции веб-приложения, вполне логично поместить их в файл web.config.
Строк соединения можно добавлять столько, сколько необходимо. Для каждой из них должно быть указано имя поставщика ADO.NET. Ниже показан пример определения единственной строки соединения:
Для извлечения строк соединения в коде служит статическое свойство WebConfigurationManager.ConnectionStrings.
Коллекция ConnectionStrings включает в себя строки соединения, которые были определены как непосредственно в файле web.config, так и в конфигурационных файлах более высокого уровня (а именно — в корневом файле web.config и файле machine.config). Это означает, что вы автоматически получаете строку соединения по имени LocalSqlServer, которая указывает на локальный экземпляр SQL Server Express (который представляет собой сокращенную версию SQL Server и включен в состав Visual Studio).