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

Обратите внимание на то, что корневой элемент ‹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");

}

Сохранение данных состояния с помощью ‹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-группе), вы имеете возможность изменить это значение.