Как настроить web config

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

Для работы с конфигурационным файлом Web.config мы будем использовать следующие его члены:

AppSettings – это свойство возвращает стандартную NameValueCollection коллекцию, которая представляет собой набор простых настроек приложения. Обращаясь по ключу или по индексу, можно получить значение определенного элемента в секции appSettings в файле Web.config.

ConnectionStrings – это свойство возвращает коллекцию объектов класса ConnectionStringSettings. Данный класс описывает конкретную строку подключения к внешнему источнику данных, например, к базе данных.

GetWebApplicationSection(section) – этот метод возвращает объект, с помощью которого можно получить информацию об определенной секции в конфигурационном файле, и уже как-то работать с ее конкретными атрибутами.

Теперь давайте попробуем внести изменения в файл Web.config. Предположим, что нам нужно добавить свои собственные настройки в приложение. Мы уже знаем, что жестко закодировать новые настройки, например, через константы – это не самая лучшая идея. Поэтому добавим их в конфигурационный файл Web.config.

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

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

Теперь посредством класса WebConfigurationManager мы можем обратиться к секции appSettings и прочитать новые настройки:

Таким образом, секция appSettings в файле Web.config – это идеальное место для объявления простых настроек в нашем приложении, которые можно описать правилом «ключ\значение».

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

Давайте попробуем создать более сложную структуру, подобную группе system.web. То есть мы объявим новую группу, в которую будут вложены отдельные элементы с нужными атрибутами:

Работа с конфигурацией такого типа немного сложнее. Прежде чем мы сможем использовать ее в работе, нам придется написать обслуживающий код. Нам понадобится создать классы-обработчики, описывающие эту конфигурацию программно, а также зарегистрировать ее в файле Web.config.

То есть, мы наследуемся от класса ConfigurationSection, а внутри нашего класса ассоциируем свойства с соответствующими атрибутами в секции.

Далее нам нужно подобным образом описать объявленную нами группу userCustomSettings, в которую вложен элемент defaultValues. Опять создаем класс обработчик, в этот раз для группы:

После этого нужно зарегистрировать объявленную группу и секцию в файле Web.config в разделе configSections:

Теперь все подготовительные действия закончены, и мы можем прочитать нашу конфигурацию:

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

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

Теперь, если мы удалим из конфигурации атрибут timeZoneShift, то будет использовано его значение по умолчанию — 5. В то же время, если мы удалим атрибут city (который теперь стал обязательным), то увидим ошибку конфигурации, и наше приложение не сможет стартануть.

То есть через параметры мы можем добиться того, что перед стартом приложения конфигурация должна быть корректно настроена. Иногда это может быть очень важно. Гораздо безопаснее будет просто не дать приложению запуститься, чем потом в процессе работы ломать голову и искать какую-нибудь логическую ошибку из-за отсутствующего значения города.

Также помимо этих параметров мы можем применить дополнительные валидационные атрибуты к нашим свойствам, описывающим секцию в конфиге. Ниже представлен список всех доступных атрибутов:

CallbackValidator — используется, чтобы реализовать пользовательскую валидацию (см.ниже).

StringValidator — используется, чтобы реализовать простую валидацию над строковыми значениями. Например, ограничить длину строки.

IntegerValidator — используется, чтобы реализовать валидацию над значениями типа int. Например, ограничить число некоторым диапазоном.

LongValidator — используется для валидации значений типа long.

TimeSpanValidator — используется для валидации TimeSpan значений. Например, также можно ограничить диапазон значений.

RegexStringValidator — можно использовать для проверки, подходит ли строка под регулярное выражение или нет.

Одним из наиболее интересных атрибутов является атрибут CallbackValidator. Он позволяет нам произвести проверку значения по нашим собственным условиям. Мы объявляем метод, в котором будет проводиться проверка, передаем название этого метода в валидатор, и в момент загрузки конфигурации приложения этот метод будет вызван для проверки значения в конфигурации.

Давайте напишем метод, в котором сделаем проверку, что если в представленном email нет слова admin, то тогда выбрасывать исключение, что представленный емаил нам не подходит:

Обратите внимание на важный момент. Особенность работы валидационных атрибутов такова, что валидаторы вызываются дважды за проверку. Первый раз в валидатор передается значение по умолчанию для данного типа (пустая строка для типа string, 0 для типа int и т.д.). Далее происходит второй вызов валидатора, и уже передается значение из файла Web.config. Именно поэтому мы сперва делаем проверку на пустую строку в конструкции if. Если не обработать двойной вызов валидатора должным образом, то наша проверка будет завершаться неудачно.

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

Для того, чтобы работать со строками подключения, указанными в конфигурации, мы обращаемся к классу WebConfigurationManager, к свойству ConnectionStrings. Это свойство возвращает объект класса ConnectionStringSettingsCollection, который содержит коллекцию всех объявленных строк подключения:

Как видно, работать со строками подключения очень просто и удобно. Для этого в классе WebConfigurationManager определено специальное свойство.

Нам осталось рассмотреть вопрос переопределения конфигурации для какой-то части приложения. Это можно сделать двумя способами:

• через элемент location в файле Web.config
• через вложенный файл Web.config

Элемент location позволяет нам определить отдельные секции в конфигурационном файле, которые будут задействованы при обращении по определенному URL. Например, добавим особые правила для действия Index в контроллере Home:

Теперь при обращении по этому URL объявленная нами конфигурация будет переопределена новыми значениями. Обратите внимание, что другие элементы секции appSettings были унаследованы от родительской конфигурации в файле Web.config.

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

Также мы можем создать дополнительный файл Web.config в поддиректории нашего приложения. Например, создадим конфигурационный файл в папке Views/Home:

Для того, чтобы применить новые настройки из вложенного файла Web.config, нам следует прочитать эту конфигурацию через WebConfigurationManager:

Также хочу заметить, что мы можем не только получать информацию о текущих настройках приложения, но и изменять настройки приложения в runtime. Например:

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

Источник

Файл web.config

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

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

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