Лекция Конфигурирование Web приложений

Windows приложение Выполняемый файл, вместе с другими поддерживающими его файлами. Например, обычное Windows приложение состоит из –основного выполняемого файла (EXE); –поддерживающих компонент (обычно DLL библиотек); –других ресурсов, таких как баз данных и конфигурационных файлов. ASP.Net приложение использует другую модели приложения.

Создание и выполнение управляемых программ

Работа программ в MS DOS и OS Windows MS DOS Программа пользователя Программа пользователя 1 Программа пользователя 2 Программа пользователя 3 Программа пользователя 4 OS Windows Common Language Runtime Программа пользователя Программа использующая.NET технологию (управляемый код, managed code) Обычная программа, не использующая.NET технологию (не управляемый код, native code) процессы

Компилятор Управляемые модули *.dll или *.netmodule Редактор текста Исходный код *.cs, *.vb, … С помощью редактора текста программа записывается в файл и сохраняется на диске. Компилятор с любого языка преобразует исходный код в промежуточный код, и задает метаданные модуля с описаниями всех типов (классов) в модуле. Загрузчик (Loader) Загрузчик создает новый процесс, в который загружает среду выполнения RTE (Run Time Environment) Just In Time Compiler Оперативная память RTE вызывает JIT компилятор, который по мере использования классов сборки выполняет компиляцию на язык машинных инструкций. Вначале управление передается статической функции Main. Процессор выполняет операторы в соответствии с логикой программы. Если класс не на машинном языке, то формируется exception, которое вызывает JIT Процессор Последовательность создания и выполнения программы на платформе.Net Run Time Environment Exceptions RTE Программа Линкер сборок Assembly *.exe или *.dll Может использоваться AL.exe утилита для создания сборки (assembly). Для простых сборок компилятор автоматически создает сборку. Сборка не объединяет модули в единый модуль, а соединяет их логически.

ASP.Net приложение На наиболее базовом уровне ASP.Net приложение является комбинацией файлов, страниц, обработчиков событий, модулей и выполняемого кода, который может быть вызван из виртуальной папки (virtual directory) (и ее подпапок) на web- сервере. В отличие от Windows приложений, конечный пользователь никогда не запускает на выполнение ASP.Net приложение напрямую. Вместо этого пользователь запускает браузер (например, такой как IE) и задаст конкретный URL адрес (например, Браузер отправит в сеть интернет HTTP запрос таким адресом и сеть Интернет переправит этот запрос web серверу с заданным адресом (

Web приложение Набор страниц, которые работают совместно. –Global.asax – обработчики событий –Web.Config – файл конфигурации приложения Поддерживаемая функциональность –Сохранение состояния между вызовами страниц –Средства навигации между страницами –Регистрация пользователей и их прав –Хранение данных каждого конкретного пользователя (персонализация) между сеансами –Единый дизайн (оформление) страниц

Выполнение ASP.Net приложения IIS web сервер не имеет понятие об отдельных web приложениях, он просто передает все запросы к ASP.Net приложениям в рабочий процесс ASP.Net (worker process) в котором выполняется среда CLR (специальная версия webhost). Разные web приложения выполняются в одном рабочем процессе ASP.Net но в разных различных доменам приложений (application domains). Web страницы, которые располагаются в одной и той же виртуальной папке (или в одной из ее подпапок) выполняются в одном и том же домене приложений. Web страницы из других виртуальных папках выполняются в других доменах приложений. В отдельном домене приложения выполняется одно web-приложение, которое расположено в отдельной виртуальной папке IIS web-сервера. Все домены приложений хорошо изолированы друг от друга. Замечание: Виртуальные папки это просто папки файловой системы, к которым есть доступ посредством web сервера.

Домен приложения Домен приложения это возможность выполнять в одном процессе несколько управляемых приложений. При этом Common Language Runtime (CLR) гарантирует, что приложения не будут влиять (или видеть в памяти данные) друг на друга. –Все web страницы одного web приложения совместно используют одни и те же ресурсы, размещенные о оперативной памяти; –Все web страницы одного web приложения совместно используют одни и те же установки (параметры) конфигурации. Однако можно настраивать некоторые конфигурационные параметры в отдельных подпапках (вложенных папках) одной и той же виртуальной папки. Например, можно задать только один способ аутентификации для web приложения, независимо от того, сколько подпапок в нем содержится. Но можно задать различные правила авторизации для каждой папки, чтобы более детально указать, кому разрешен доступ к различным группам страниц. –Все web приложения генерируют глобальные события приложения на различных этапах выполнения (когда домен приложения в первый раз создается, когда уничтожается и удаляется из памяти, и т.п.). Можно задать обработчики событий, которые реагируют на глобальные события приложения, задавая код в файле global.asax, который содержится виртуальной папке приложения.

Виртуальные папки Виртуальная папка являются основным способом выделения ASP.Net приложения. Можно создать правильное ASP.Net приложение, содержащее только 1 web страницу (.aspx файл). Однако, ASP.Net приложения могут включать следующие компоненты: –Web страницы (.aspx файлы): это основные элементы ASP.Net приложения. –Web сервисы (.asmx файлы): они позволяют совместно использовать полезные функции (методы) с приложениями, которые расположены на разных компьютерах и на других платформах. –Code-behind файлы: В зависимости от того, какая модель кода используется, можно размещать программный код в отдельных.cs файлах. –Конфигурационные файлы (web-config) - это файл содержащий множество параметров (установок) уровня приложения, которые конфигурируют все, начиная от безопасности, и заканчивая отладкой и управлением состоянием. –Файл global.asax - этот файл содержащий обработчики событий, которые обрабатывают глобальные события приложения. –Множество любых других ресурсов, которые используются приложением: изображения, XML файлы, данные и т.п. Другие компоненты: это откомпилированные сборки (assemblies). Которые содержат отдельные компоненты, которые разработаны программистом или приобретенные, поддерживающие полезную функциональность. Компоненты позволяют разделить бизнес логику и логику доступ к данным и создавать пользовательские ЭУ.

Жизненный цикл приложений ASP.Net использует метод ленивой инициализации (lazy initialization) для создания доменов приложений. Это означает, что домен приложения для web приложения создается после того, как поступит первый запрос к странице, которая содержится в виртуальной папке. Домен приложения может закончить работу по разным причинам, включая ситуацию, когда останавливается работа самого Internet сервера. Но более вероятно, что приложения будет стартовать заново в новом домене приложений в ответ на возникновение ошибки выполнения или изменения конфигурации. Например, в зависимости от установок в файле machine.config, который содержит установки для всего компьютера (на уровне компьютера), ASP.Net приложение может периодически перезапускаться, если будет достигаться некоторое пороговое значение. Такая модель создана для того, чтобы сохранить правильное состояние приложения и обнаружить характеристики, которые могут указывать на возникновение проблем или понижение производительности (такие как длинные очереди отложенных запросов, использование большого объема памяти и т.п.). В зависимости от установок в файле machine.config, домены приложений могут перезапускаться, на основе времени выполнения домена приложений, количества запросов поставленных в очередь, или количества используемой памяти.

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

Структура папок Web приложения Каждое web приложение имеет хорошо спланированную структуру папок. ASP.Net определяет несколько папок со специальным назначением.

Зарезервированные папки проекта Bin – все предкомпилированные (заранее компилированные) сборки.dll, необходимые для работы приложения. В простом проекте их может не быть. App_Data – источники данных, используемых в проекте. Доступны только из этого проекта. App_Code – исходные коды классов приложения (.cs ). При первом обращении к ним они динамически компилируются в сборку.dll, которая кэшируется в папке Windows\...\Temporary ASP.NET Files. Кэшированная сборка используется проектом, пока не изменятся какие-либо его коды. App_GlobalResources – глобальные ресурсы.resx всего приложения для многоязычной поддержки браузеров (язык браузера передаётся в заголовке HTTP-запроса). App_LocalResources – локальные ресурсы.resx для отдельных страниц приложения. App_Thems – темы приложения - файлы.css, рисунки… Каждая тема в своей папке. App_WebReferences – файлы.wsdl используемые для Web-сервисов.

Структура папок web-приложения (Application Directory) ПапкаОписание Bin Эта папка содержит все заранее откомпилированные сборки (обычно DLL), которые будет использовать ASP.Net. Эти сборки могут включать откомпилированные классы web- страниц. App_Code Эта папка содержит файлы с исходным кодом, которые динамически компилируются для использования в приложении. Эти папки с кодом обычно совместно используют компоненты, такие как компоненты поддержки журнала или библиотеку доступа к данным. Откомпилированный код никогда не появляется в Bin папке, так как ASP.Net помещает его во временные папки, которые используются для динамической компиляции. App_GlobalResources В этой папке хранятся глобальные ресурсы, которые доступны во всех страницах web-приложения. App_LocalResources Эта папки используется с той же целью, что и папка App_GlobalResources, но эти ресурсы доступны только для указанной в них странице.

Структура папок web-приложения (продол.) ПапкаОписание App_WebReference В этой папке хранятся ссылки на web-сервисы, которые использует web-страница. В ней размещаются WSDL файлы и документы поиска сервисов. App_Data Эта папка предназначена для хранения данных, включая базы данных SQL Server 2005 Express и XML файлы. Суда можно помещать и любые свои файлы с данными. App_Browser В этой папке хранится информация с описаниями браузеров в виде XML файлов. Такие XML файлы содержат описания возможностей браузеров клиентов для выполнения различных действий по рендерингу. Хотя ASP.Net делает это глобально (на весь компьютер), папка App_Browser позволяет настраивать такое поведение для различных web-приложений. App_Themes В этой папке хранятся темы (theme), используемые web- приложением.

События приложения (Application Events) Можно обрабатывать два типа событий в global.asax файле: –События, которые возникают для каждого запроса. К ним относятся события связанные с запросом (request-related) и события связанные с ответом (response-related). –События, которые возникают только при определенных условиях.

IIS связывает обрабатывающих модулей с расширением.aspx Указывается, что модуль aspnet_isapi.dll должен обрабатывать запросы к файлам с расширением aspx. Данный модуль передает данные о запрашиваемом файле в другой модуль - aspnet_wp.exe.

Обработка запросов в IIS 5.0 aspnet_wp.exe

Обработка запросов в IIS 6.0

Что такое ASP.Net? В самом общем виде, ASP.Net является системой обработки запросов (request processing engine). Она получает приходящий запрос и передает его по внутреннему процессу обработки (internal pipeline) до конечной точки, где разработчик может подключить к процессу требуемый код.Эта система обработки полность отделяет HTTP runtime от Web Server. Фактически данная HTTP runtime является компонентом, который разработчик может помещать в свои собственные приложения вне IIS.Например, так делает Visual Studio. HTTP runtime отвечает за маршрутизацию запросов через этот процесс обработки (pipeline), сложный, хотя и очень изящный механизм. Несколько взаимосвязанных объектов, расширенных с помощью создания производных классов или с помощью интерфейсов, доступны для настройки на решение конкретной задачи. Это придает данной среде хорошую адаптируемость. ISAPI это Win32 API. Система обработки ASP.Net взаимодействет с IIS посредством ISAPI расширения. Данное расширение содержит.Net через ASP.Net runtime. Система обработки (engine) ASP.Net была написана полность на управляемом коде и вся расширяющая функциональность предоставляется посредством "расширений на управляемом коде" (managed code extensions)

Поток обработки запроса в web-сервере IIS и затем в рабочем цикле ASP.NET (runtime) (упрощенный).

События, составляющие процесс обработки запроса

Модули и Обработчики (Modules,Handlers) Классы HTTPApplication и HTTPContext являются просто контейнерами для приходящих сообщений. Они создают рабочий процесс (pipeline) формируя цепочку событий, которые начинаются в определенном порядке и они содержат данные, связанные с запросом, для того, чтобы предоставить другим экземплярам легкий доступ к информации, имеющей отношение к данному процессу. Однако реальная работа выполняется в других обрабатывающих элементах, в частности в модулях и обработчиках. Модули разрабатываются на базе класса HTTPModule, а обработчики на базе класса HTTPHandler. Оба эти класса являются абстрактными и требуют конкретную реализацию. Кроме того, оба этих класса очень хорошо настраиваются (configurable) и действуют в виде последовательности экземпляров. Это означает, что разработчик можетприкрепить столько модулей и обработчиков, сколько требуется и запрос будет проходить через все эти экземпляры. Разные задачи могут решаться в модулях и обработчиках, однако они имеют разное назначение. Модули предназначены для управления задачами на более низком уровне, они более базовые по сравнению с обработчиками. Модули можно понимать, как подходящее место для подготовки данных, которые будут обрабатываться обработчиками, или для изменения данных после того, как выполнение обработчиаов завершается. Ревностные поклонники web-сервера IIS могут рассматривать модули, как аналоги ISAPI фильтров. Однако ледует отметить, что разрабатывать ASP.Net модули с помощью.Net намного легче, чем фильтры для IIS. Обычный порядок выполнения модулей и обработчиков следующий: 1.Использование модуля для предварительной обработки (pre-process) запроса. 2.Использование обработчика для обработки запроса. 3.Использование модуля для завершающей обработки (post-process) запроса. ASP.Net содержит несколько уже созданных обработчиков (handlers), таких, как базовые обработчики web-страниц *.aspx или web-сервисов *.ascx. Имеются также несколько стандартных модулей, которые выполняют такие задачи, как аутентификация или кеширование. ASP.Net дает возможность достаточно просто разработать свои собственные модули и разработчики.

Жизненный цикл ASP.Net web-приложения Жизненный цикл ASP.Net web-приложения можно разделить на три части: –Жизненный цикл приложения –Жизненный цикл web-страницы –Жизненный цикл элемента управления

События жизненного цикла web- приложения

Начало обработки запроса После получения первого запроса к любому ресурсу в приложении, создается экземпляр класса ApplicationManager. Его основной целью является создание домена приложения (AppDomain), в котором будет обрабатываться запрос. В этом домене создается экземпляр HostingEnvironment, который предоставляет доступ к такой информации о данном приложении, как имя папки, в которой хранятся файлы приложения. В течении первого запроса выполняется компиляция исходного кода всех web- страниц приложения в одну сборку. После этого создаются и инициализируются объекты классов HttpContext, HttpRequest и HttpResponse. Эти объекты существуют в течении всего времени обработки запроса и предоставляют разработчику полный доступ ко всем связанным с ними данным. Объект класса HttpContext содержит объекты, которые являются специфичными для текущего запроса к приложению, таким, как объекты HttpRequest и HttpResponse. Объект HttpRequest содержит информацию о текущем запросе, такую, как куки (cookies) и информация о браузере. Объект HttpResponse содержит формируемый ответ, который предназначен для отправки клиенту. Этот ответ содержит всю информацию,формируемую ЭУ (rendered output) и данные заголовка (header data), такие, как куки. Статический метод HttpContext.Current предоставляет постоянный доступ текущему контексту. Для более простого доступа, класс Page имеет такие свойства, как Request и Response, которые возвращают экземплярытех же объектов HttpRequest и HttpResponse.

После инициализации всех нужных объектов, приложение начинает работать. Для этого создается экземпляр класса HttpApplication. Если приложение имеет файл global.asax, тогда ASP.Net создает на его основе экземпляр класса производного от HttpApplication. Этот объект используется для представления данного приложения. Таким образом разработчик может создать обработчики событий, связанных с приложением, global.asax. Данный объект создается при первом вызове приложения. При обработке последующих вызовов этот объект снова используется. Объект класса HttpApplication выполняет несколько действий в ходе обработки запроса. Каждый шаг процесса обработки инициирует специфическое событие, которое позволяет разработчику написать обработчик (специальный код), который будет выполняться при возникновении данного события.

Основные шаги жизненного цикла страницы Начало работы (Start) –задаются свойства Request, Response, IsPostBack. Инициализацию (Page Initialization) –становятся доступными экземпляры ЭУ и у каждого ЭУ задается свойство UniqueID. Загрузка (Load) –если текущий запрос является повторным (postback), то свойства ЭУ загружаются информацией полученной из vie state и control state. –восстановление и поддержка состояния (view state). При начальном запросе свойствам ЭУ задаются значения по умолчанию. Проверка (Validation) –у всех ЭУ вызываются методы Validate(). Задается свойство IsValid для всех валидаторов ЭУ, а также устанавливается свойство IsValid для всей страницы. Обработка событий повторного запроса (Postback event handling) –если запрос повторный, то вызываются требуемые события, например, такое как событие click для button. Рендеринг (формирование ответа, Rendering) –Формируется view state для страницы и всех ЭУ. Рендеринг это процесс, в ходе которого создается HTML, который делает страницу видимой в браузере. Каждый ЭУ отвечает за свой рендеринг. Вызывается метод Render() для каждого ЭУ, которому передается TextWriter, который передает OutputStream свойству Response данной страницы. Выгрузка (Unload) –После того, как страница полностью сформирует ответ (выполнит рендеринг) и он отправлен клиенту, она может быть удалена. В ходе выполнения всех шагов инициируются соответствующие события, для которых разработчик может написать обработчики.

Обработка событий приложения

Основные события web-приложения возникающие при обработке каждого запроса 1.Application_BeginRequest(): в начале каждого запроса 2.Application_AuthenticateRequest(): перед выполнением аутентификации. Удобно для выполнения аутентификации. 3.Application_AuthorizeRequest(): После аутентификации пользователя наступает время для определения прав пользователей (users permissions). Можно использовать данный метод для задания специальных привилегий. 4.Application_ResolveRequestCache(): этот метод обычно используется совместно с выходным кэшем. Используя выходной кэш, можно многократно использовать сформированный HTML web формы, без выполнения кода. Однако этот обработчик события будет выполняться. 5.В этом месте вызываются запрос передается подходящему обработчику событий. Например, при запросе web-form, это место, когда страница компилируется (если необходимо) и создается ее экземпляр. 6.Application_AcquireRequestState(): Этот метод вызывается как раз перед специфическая для сеанса информация ищется для клиента и используется для заполнения Session коллекции. 7.Application_PreRequestHandlerExecute(): Этот метод вызывается перед тем, как подходящий HTTP handler выполняет запрос. 8.В этом месте подходящий HTTP handler выполняет запрос. Например, если это запрос к web форме, то выполняется код обработки событий данной страницы, и формируется HTML ответ. 9.Application_PostRequestHandlerExecute(): этот метод вызывается сразу после обработки запроса. 10.Application_ReleaseRequestState(): этот метод вызывается, когда специфическая для сеанса (session) информации из коллекции Session сериализована, так что она доступна для следующего запроса. 11.Application_UpdateRequestCache(): Этот метод вызывается как раз перед тем, как информация добавляется в выходной кэш (output cache). Например, если включено output caching для данной страницы, то в данном месте ASP.NET будет вставлять сформированный HTML страницы в кэш. 12. Application_EndRequest(): Этот метод вызывается в конце обработки запроса, как раз перед освобождением объектов. Это удобное место для освобождения всех занятых ресурсов.

События возникающие в специальных случаях Application_Start(): этот метод вызывается, когда приложение стартует первый раз и создается домен приложения. Это удобное место для инициализации переменных приложения. Например, в этом месте можно загрузить и кэшировать данные, которые не будут изменяться в ходе работы приложения, такие как дерево навигации, статические каталоги продукции и т.п. Session_Start(): Этот метод вызывается каждый раз при создании сеанса работы пользователя. В нем часто выполняется инициализация специфических для пользователя данных. Application_Error(): Этот метод вызывается когда в приложении генерируется не обработанное исключение. Session_End(): Этот метод возникает, когда заканчивается сеанс работы пользователя. Это возникает, когда код явно задаст это или когда интервал времени между вызовами превысит заданный предел (обычно 20 мин.). В этом методе обычно выполняется освобождение занятых ресурсов. Однако этот метод вызывается, если только используется in-process способ хранения состояния сеанса (InProc mode, а не StateServer или SQLServer). Application_End(): Этот метод вызывается перед самым завершением работы приложения. Окончание работы приложения возникает в связи с тем, что запускается заново IIS или в связи с тем, что приложение переходит к новому домену приложения в ответ на обновление фалов или в связи с установками повторного использования процесса.

Файл global.asax Файл global.asax дает возможность записывать обработчики событий, которые обрабатывают глобальные события. Пользователи никогда не запрашивают этот файл напрямую. Вместо этого, этот файл выполняется автоматически в ответ на некоторые событии приложения. Файл global.asax предоставляет сервис сходный с тем, который предоставляет файл global.asa в обычных ASP приложениях. Вы записываете код в файл global.asax также как и в web-формы. Отличием является то, что global.asax не содержит HTML или ASP.Net тэгов. Вместо этого он содержит методы со специальными именами. Файл global.asax является не обязательным, но web-приложение может содержать не более чем один global.asax файл. Для добавления файла можно использовать команду Website Add New Item (or Project Add New.

Пул объектов Application Все глобальные события обрабатываются объектами класса Application (производный от класса HttpApplication) Для обработки глобальных событий ASP.Net создает пул объектов Application в домене приложения, когда приложение впервые загружается, и использует их для обслуживания каждого запроса. Этот пул имеет разный размер, в зависимости от системы и количества доступных потоков (thread), но обычно он включает от 1 до 100 экземпляров. Каждый запрос получает эксклюзивный доступ к одному их этих объектов приложений, а когда запрос заканчивается, то объект повторно используется с другим запросом.

Пример обработчика событий global.asax Например, приведенный ниже файл будет реагировать событие HttpApplication.EndRequest, которое произойдет перед тем, как страница будет отправлена пользователю: protected void Application_OnEndRequest() { Response.Write(" This page was served at " + DateTime.Now.ToString()); }

События связанные с работой приложения Application_Start – возникает, когда приложение начинает работать. Хорошее место для задания начальных значений в словаре Application. Application_End - возникает, когда приложение завершает работу. Используется для освобождения занятых ресурсов и выполнения записи в журнал. Application_Error - возникает, когда возникает не обработанная ошибка. Используется для записи в журнал информации об ошибке.

Пример обработчиков событий void Application_Start(object sender, EventArgs e) { // Код выполняемый при запуске приложения Application["UsersOnline"] = 0; } void Session_Start(object sender, EventArgs e) { // Код выполняемый в начале сессии Application.Lock(); Application["UsersOnline"] = (int)Application["UsersOnline"] + 1; Application.UnLock(); } void Session_End(object sender, EventArgs e) { // Код выполняемый при завершении сессии // Замечание: Событие Session_End возникает, только, когда режим // sessionstate установлен на InProc в файле Web.config. Если режим // установлен на StateServer или SQLServer, то событие не возникает Application.Lock(); Application["UsersOnline"] = (int)Application["UsersOnline"] - 1; Application.UnLock(); }

Хотя это не показано в файле global.asax, каждый файл global.asax определяет методы для класса приложений Application. Класс приложений является производным от класса HTTPApplication и в результате ваш код имеет доступ ко всем его public и protected членам. В этом примере используется объект Response, который предоставляется с помощью встроенного свойства класса HTTPApplication, также как и встроенное свойство класса Page. В приведенном примере обработчик события Application_OnEndRequest() записывает нижнюю строку страницы. Так как он реагирует на каждое событие HttpApplication.EndRequest, то данный метод будет вызываться при каждом запросе страницы, после того, как будет закончено выполнение всего кода по обработке страницы.

Настройка ASP.Net приложений Вся информация, требуемая для конфигурирования базовых параметров (установок) ASP.Net приложения, а также специфических параметров вашего приложения, хранится в этом конфигурационных файлах. Конфигурационные файлы содержат XML документы. Достоинства XML конфигурационных файлов: –Никогда не блокируются, могут быть изменены в любое время; –Легко доступны и повторно используемы; –Их легко редактировать и понимать. Состав конфигурационных файлов В папке c:\Windows\Microsoft.NET\Framework\v \Config –мachin.config (, ) –web.config В виртуальных папках –web.config

Файлы настройки web приложения machine.config web.config

Файл machine.config Находится в папке c:\Windows\Microsoft.NET\Framework\v \Config Раздел - позволяет задать, как рабочий процесс ASP.Net использует многократно домен приложений и учетную запись Windows, которая определяет его привилегии. (в IIS 6 и 7 не используется). Раздел позволяет задать специфический для сервера ключ, для кодирования данных и создания цифровых подписей. В этом случае для каждого приложения создается и сохраняется специфические ключи. Если не требуется создавать разные ключи, то можно использовать один ключ для всех приложений: Или задать значения ключей самому:

Файл web.config Наследует значения из файла machin.config и файла web.config записанного в корневой виртуальной папке приложения.

Наследование конфигураций

Конфигурация Концепции и архитектура –Файл Web.Config –Иерархическая архитектура конфигурации Влияет на текущую директорию и все поддиректории Root Dir Sub Dir1 Sub Dir2 Web.Config

Наследование значений конфигурационных файлов Например, рассмотрим web-запрос к странице где A это корневая папка web приложения. В этом случае множество уровней установок будет использовано: 1.Вначале применяются установки из файла machine.config. 2.Следующими считываются установки из web.config корневой папки компьютера. Корневой web.config файл расположен в той же Config папке, что и файл machine.config. 3.Если есть web.config файл в корневой папке приложения, то установки из него применяются следующими. 4.Если есть файл web.config в поддиректории B, то они применяются следующими. 5.Если есть файл web.config в поддиректории С, то они последними.

В разделе содержатся все специфические для ASP.Net конфигурационные установки, такие как: –безопасность (authentication, authorization) –Управление состоянием (sessionState) –Трассировка (trace, customErrors) Структура данного раздела фиксирована, нельзя добавлять свои собственные элементы.

Задаются строки соединения с БД ...

В этот раздел можно добавлять свои элементы. ...

Класс WebConfigurationManager Чтение строк соединения WebConfigurationManager.ConnectionStrings[«имя соединения»]; Чтение параметров программы WebConfigurationManager.AppSettings[«имя параметра»]; Пример: using System.Configuration; … protected void Page_Load(object sender, EventArgs e) { lblSiteName.Text = ConfigurationManager.AppSettings["websiteName"]; lblWelcome.Text = ConfigurationManager.AppSettings["welcomeMessage"]; }

Чтение connections strings foreach (ConnectionStringSettings connection in WebConfigurationManager.ConnectionStrings) { Response.Write("Name: " + connection.Name + " "); Response.Write("Connection String: " + connection.ConnectionString + " "); }

// Get the configuration for the current web application. Configuration config = WebConfigurationManager.OpenWebConfiguration("/"); // Search for the element inside // the element. AuthenticationSection authSection =

web.config … …

Пример файла конфигурации web.config

Website Administration Tool (WAT) Website ASP.NET Configuration Project ASP.NET Configuration

Запуск администрирования веб- узлом