Эндрю Троелсен - ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

Элемент ‹customErrors› может использоваться для автоматического перенаправления всех ошибок в пользовательский набор файлов *.htm. Это может оказаться полезным тогда, когда вы хотите построить более понятную для пользователя страницу информирования об ошибках по сравнению с той, которая предлагается средой CLR по умолчанию. В общем виде элемент ‹customErrors› выглядит так.

‹customErrors defaultRedirect="url" mode="On|Off|RemoteOnly"›

‹error statusCode="код_состояния" redirect="url"/›

‹/customErrors›

Чтобы предъявить пример применения элемента ‹customErrors›, предположим, что Web-приложение ASP.NET имеет два файла *.htm. Первый файл (genericError.htm) функционирует, как страница перехвата ошибок. Эта страница может содержать логотип вашей компании, ссылку на адрес электронной почты администратора системы и, например, сообщение с извинениями за доставленные пользователю неудобства. Второй файл (Error404.htm) – это пользовательская страница ошибки, которая должна появляться только тогда, когда среда выполнения обнаруживает ошибку с номером 404 (грозная ошибка "необнаруженного ресурса"). Если вы хотите, чтобы все ошибки обрабатывались этими пользовательскими страницами, вы можете изменить файл Web.config так, как предлагается ниже.

‹?xml version="1.0"?›

‹configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"›

‹appSettings/›

‹connectionStrings /›

‹system.web›

‹compilation debug= "false" /›

‹authentication mode="Windows"/›

‹customErrors defaultRedirect="genericError.htm" mode="On"›

‹error statusCodes="404" redirect="Error404.htm"/›

‹/customErrors›

‹/system.web›

‹/configuration›

Обратите внимание на то, что корневой элемент ‹customErrors› используется для указания имени общей страницы для всех необработанных ошибок. Одним из атрибутов, которые могут присутствовать в открывающем дескрипторе, является атрибут mode. Значением, устанавливаемым для этого атрибута по умолчанию, является RemoteOnly, дающее указание среде выполнения не отображать пользовательские страницы ошибок, если HTTP-запрос поступает с той же машины, где находится Web-cервер (это очень удобно для разработчиков, которым требуется видеть все подробности). Если установить для атрибута mode значение "on", это позволит видеть пользовательские ошибки на всех машинах (включая машину разработки). Также заметьте, что элемент ‹customErrors› может поддерживать любое число вложенных элементов ‹error›, с помощью которых можно указать, какая страница должна иcпользоваться для ошибки с тем или иным кодом.

Чтобы проверить работу пользовательского перенаправления ошибок, создайте страницу *.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");

}

Наиболее мощным элементом файла 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.NET\Framework\‹версия›. На целевой машине вы должны выполнить файл InstallSqlState.sql, используя, например, SQL Server Query Analyzer (который входит в поставку Microsoft SQL Server).

После выполнения указанного SQL-сценария, вы обнаружите новую базу данных SQL Server (с именем ASPState), содержащую набор хранимых процедур, вызываемых средой выполнения ASP.NET, и множество таблиц, используемых для хранения сеансовых данных (кроме того, в базу данных tempdb будет добавлено множество таблиц для обмена данными). Вы должны понимать, что настройка Web-приложения на запоминание сеансовых данных рамках SQL Server является самым медленным из всех возможных вариантов. Преимущество этого варианта в том, что пользовательские данные при этом сохраняются наиболее надежно (даже при перезапуске Web-сервера).