Чтобы проверить работу пользовательского перенаправления ошибок, создайте страницу *.aspx с двумя элементами управления Button и обработайте их события Click так, как предлагается ниже.
private void btnGeneralError_Click(object sender, EventArgs e) {
// Это генерирует ошибку общего вида.
throw new Exception("Ошибка общего вида…");
}
private void btn404Error_Click(object sender, EventArgs e) {
// Это генерирует ошибку 404 (при отсутствии файла MyPage.aspx).
Response.Redirect("MyPage.aspx");
}
Сохранение данных состояния с помощью ‹sessionState›
Наиболее мощным элементом файла Web.config является ‹sessionState›. По умолчанию ASP.NET запоминает данные сеансового состояния с помощью *.dll в рамках рабочего процесса ASP.NET (aspnet_wp.exe). Подобно любому файлу *.dll. положительным моментом его использования является то, что доступ к информации оказывается настолько быстрым, насколько это возможно. Однако недостатком оказывается то, что в случае аварийного завершения работы этого домена приложения (по любой причине) будут потеряны все данные пользователя. К тому же, когда вы храните данные в *.dll внутри процесса, вы не можете взаимодействовать с сетевой Web-группой. По умолчанию элемент ‹sessionState› файла Web.config выглядит примерно так.
‹sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" /›
Принятый по умолчанию режим хранения оказывается вполне подходящим только в том случае, когда ваше приложение обслуживается в рамках одного Web-сервера. Но в ASP.NET вы можете дать указание среде выполнения обслуживать *.dll сеансового состояния в суррогатном процессе, называемом сервером сеансового состояния ASP.NET (aspnet_state.exe). Тем самым вы можете вывести *.dll из aspnet_wp.exe в отдельный *.exe. Первым шагом при этом должен быть запуск службы aspnet_state.exe Windows. С этой целью введите в командной строке
net start aspnet_state
Запустить aspnet_state.exe можно и по-другому, с помощью оснастки Службы, доступной из папки Администрирование панели управления Windows (рис. 24.10).
Рис. 24.10. Оснастка Services Windows
Преимуществом этого подхода является то, что с помощью окна свойств вы можете настроить aspnet_state.exe на автоматический старт при загрузке машины. В любом случае, запустив сервер состояния сеанса, измените элемент ‹sessionState› в файле Web.config так, как показано ниже.
‹sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20"/›
Здесь атрибут mode устанавливается равным StateServer. Это именно то, что требуется. Теперь CLR обслуживает данные сеанса в рамках aspnet_state.exe. В этом случае, если домен приложения, содержащий само Web-приложение, завершится аварийно, сеансовые данные сохранятся. Также заметьте, что элемент ‹sessionState› может содержать атрибут stateConnectionString. Принятое по умолчанию значение (127.0.0.1) для адреса TCP/IP указывает на локальную машину. Если вместо этого вы хотите, чтобы среда выполнения .NET использовала сервис aspnet_state.exe на другой машине в сети (снова подумайте о Web-группе), вы имеете возможность изменить это значение.
Наконец, если требуется наивысшая степень изолированности и устойчивости дли Web-приложения, вы можете "заставить" среду выполнения сохранять все данные состояния сеанса в Microsoft SQL Server. Соответствующая модификация файла Web.config снова очень проста.
‹sessionState mode="SQLServer" stateConnectionString="tcpip=l27.0.0.1:42424" sqlConnectionString="data sourse=127.0.0.1;Trusted_Connection=yes'' cookieless="false" timeout="20" /›
Однако перед тем как вы попытаетесь выполнять соответствующее Web-приложение, вы должны обеспечить правильную настройку целевой машины (указанной атрибутом sqlConnectionString). При установке .NET Framework 2.0 SDK (или Visual Studio 2005) создаются два файла, InstallSqlState.sql и UninstallSqlScate.sql, которые по умолчанию помещаются в папку ‹%windir%›Microsoft.NETFramework‹версия›. На целевой машине вы должны выполнить файл InstallSqlState.sql, используя, например, SQL Server Query Analyzer (который входит в поставку Microsoft SQL Server).
После выполнения указанного SQL-сценария, вы обнаружите новую базу данных SQL Server (с именем ASPState), содержащую набор хранимых процедур, вызываемых средой выполнения ASP.NET, и множество таблиц, используемых для хранения сеансовых данных (кроме того, в базу данных tempdb будет добавлено множество таблиц для обмена данными). Вы должны понимать, что настройка Web-приложения на запоминание сеансовых данных рамках SQL Server является самым медленным из всех возможных вариантов. Преимущество этого варианта в том, что пользовательские данные при этом сохраняются наиболее надежно (даже при перезапуске Web-сервера).
Замечание. Если для хранения сеансовых данных используется сервер состояния сеанса ASP.NET или SQL Server, то любой пользовательский тип, размещаемый в объекте HttpSessionState, должен быть обозначен атрибутом [Serializable].
Утилита администрирования узла ASP.NET 2.0
В завершение этого раздела главы следует упомянуть тот факт, что ASP.NET 2.0 теперь предлагает Web-утилиту конфигурации для управления множеством установок в файле Web.config узла. Чтобы активизировать эту утилиту (рис. 24.11), выберите Web Site→ASP.NET Configuration из меню Visual Studio 2005.
Рис. 24.11. Утилита администрирования узла ASP.NET 2.0
В большинстве своем функциональные возможности этого инструмента связаны с безопасностью вашего узла (режим аутентификации, пользовательские роли, поставщики безопасности и т.д.). Однако, кроме того, этот инструмент позволяет устанавливать параметры приложения, детали отладки и страницы обработки ошибок.
Наследование конфигурации
Последним из рассматриваемых в этой главе вопросов будет наследование конфигурации. Из предыдущей главы вы узнали, что Web-приложение можно определить, как множество файлов, содержащихся в корневом каталоге и любом числе необязательных подкаталогов. Все приложения примеров этой и предыдущей глав находились в одном корневом каталоге, управляемом IIS (с необязательным каталогом Bin). Однако полномасштабные Web-приложения обычно определяют в корневом каталоге множества подкаталогов, каждый из которых содержит некоторое подмножество связанных между собой файлов. Подобно обычному приложению дал настольной системы, это делается для удобства разработчиков, поскольку иерархическая структура может сделать большое множество файлов более понятным.
Если у вас есть Web-приложение ASP.NET, содержащее необязательные подкаталога в корневом каталоге, вы с удивлением обнаружите, что каждый такой подкаталог может иметь собственный файл Web.config. Это дает возможность каждому подкаталогу переопределить установки родительского каталога. Если подкаталог не имеет своего пользовательского файла Web.config, каталог наследует установки следующего файла Web.config, размещенного выше по структуре каталога. Такой подход как это ни странно звучит, позволяет перенести определенные принципы ООП на структуру каталогов. Соответствующая концепция иллюстрируется схемой, представленной на рис. 24.12.
Рис. 24.12. Наследование конфигурации
Конечно, хотя ASP.NET позволяет определить множество файлов Web.config для одного Web-приложения, это делать совсем не обязательно. В большинстве случаев Web-приложению для нормального функционирования будет вполне достаточно одного файла Web.config, размещенного в корневом виртуальном каталоге IIS.
Замечание. Вспомните из плавы 11, что файл machine.config определяет различные установки на уровне машины, многие из которых связаны с ASP.NET. Этот файл является наивысшим в иерархии наследования конфигурации.
На этом наш обзор ASP.NET завершается. Как уже подчеркивалось в главе 23, полное и исчерпывающее рассмотрение ASP.NET 2.0 требует отдельной и довольно объемной книги. Но я надеюсь, что теперь вы чувствуете себя достаточно уверенно в рамках соответствующей программной модели.
Замечание. Если вам требуется более глубоко изучить ASP.NET 2.0, обратитесь к книге Мэтью Мак-Дональда и Марио Шпушта, Microsoft ASP.NET 2.0 с примерами на C# 2005 для профессионалов (ИД "Вильямс", 2006 г.).
В завершение нашего путешествия в последней главе будет рассмотрена тема создания Web-сервисов XML в .NET 2.0.
В этой главе вы имели возможность расширить свои знания в области ASP.NET, рассмотрев возможности использования типа HttpApplication. Вы могли убедиться в том, что этот тип предлагает целый ряд обработчиков событий уровня приложения и сеанса.
Значительная часть этой главы была посвящена рассмотрению различных подходов к управлению данными состояния. Напомним, что данные состояния представлений используются для автоматического обновления значений HTML-элементов при вторичных обращениях к Web-странице. Затем были выяснены различия между данными уровня приложения и сеанса, рассмотрены возможности управления данными cookie и изучен кэш приложения ASP.NET. Наконец, был рассмотрен набор элементов, которые могут присутствовать в файле Web.config.
