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

• Название: ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание
• Автор: Эндрю Троелсен
• Издательство: Издательский дом "Вильямс"
• Жанр: Программирование
• Год: 2007
• ISBN: ISBN 5-8459-1124-9

В этой книге содержится описание базовых принципов функционирования платформы .NET, системы типов .NET и различных инструментальных средств разработки, используемых при создании приложений .NET. Представлены базовые возможности языка программирования C# 2005, включая новые синтаксические конструкции, появившиеся с выходом .NET 2.0, а также синтаксис и семантика языка CIL. В книге рассматривается формат сборок .NET, библиотеки базовых классов .NET. файловый ввод-вывод, возможности удаленного доступа, конструкция приложений Windows Forms, доступ к базам данных с помощью ADO.NET, создание Web-приложений ASP.NET и Web-служб XML. Книга содержит множество примеров программного кода, призванного помочь читателю в освоении предлагаемого материала. Программный код примеров можно загрузить с Web-сайта издательства.

---

При добавлении файла Web.config к файлам узла с помощью выбора WebSite→Add New Item из меню создаваемая по умолчанию структура выглядит примерно так, как показано ниже (чтобы не загромождать структуру, комментарии здесь были исключены).

‹?xml version="1.0"?›

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

  ‹appSettings/›

  ‹connectionStrings/›

  ‹system.web›

   ‹compilation debug="false"/›

   ‹authentication mode="Windows"/›

  ‹/system.web›

‹/configuration›

Подобно любому файлу *.config, в файле Web.config определяется корневой элемент ‹configuration›. В его контекст вкладывается элемент ‹system.web›, который может содержать множество дочерних элементов, с помощью которых осуществляется управление поведением Web-приложения в среде выполнения. В ASP.NET файл Web.config можно модифицировать с помощью любого текстового редактора. Некоторые элементы, которым позволено присутствовать в файле Web.config, описаны в табл. 24.4.

Замечание. Чтобы выяснить подробности формата файла Web.config, выполните поиск разделов документации .NET Framework 2.0 SDK, соответствующих ключу поиска "ASP.NET Settings Schema".

Таблица 24.4. Подборка элементов файла

Элемент Описание ‹appSettings› Используется для создания пользовательских пар имен и значений, которые можно программно считывать в память для использования на страницах в дальнейшем ‹authentication› Связанный с безопасностью элемент, используемый для определения режима аутентификации данного Web-приложения ‹authorization› Еще один связанный с безопасностью элемент, используемый для определения прав пользователей при доступе к ресурсам сервера ‹compilation› Используется для разрешения (или запрета) отладки и определения языка .NET, используемого данным Web-приложением по умолчанию, а также (необязательно) для определения множества внешних компоновочных блоков .NET ссылки на которые должны использоваться автоматически <connectionStrings> Используется для хранения строк внешних соединений данного Web-узла ‹customErrors› Используется для инструкций среде выполнения по поводу того, как сообщать об ошибках, происходящих в процессе работы Web-приложения ‹globalization› Используется для настройки параметров глобализации данного Web-приложения ‹sessionState› Используется для контроля того, как и где среда выполнения .NET должна хранить данные состояния сеанса <trace> Используется для разрешения (или отключения) трассировки данного Web-приложения

Файл Web.config может содержать дополнительные элементы, размещенные как до, так и после элементов, представленных в табл. 24.4. Большинство этих эле-ментов связано с безопасностью, а остальные оказываются полезными только для построении достаточно сложных сценариев ASP.NET, предполагающих, например, создание пользовательских HTTP-заголовков или пользовательских HTTP-модулей (эти вопросы здесь обсуждать не планируется). Если вам нужен полный комплект элементов, допустимых для использования в файле Web.config, поищите по ключу "ASP.NET Settings Schema" в системе оперативной справки.

Разрешение трассировки с помощью ‹trace›

Первым элементом файла Web.config, который мы собираемся здесь рассмотреть, будет элемент ‹trace›. Этот XML-дескриптор может иметь любое число атрибутов, задающих особенности его поведения, как показано в следующем примере.

‹trace

 enabled="true|false"

 localOnly= "true|false"

 pageOutput="true|false"

 requestLimit="integer"

 traceMode="SortByTima|SortByCategory"/›

Описания этих атрибутов предлагаются в табл. 24.5.

Таблица 24.5. Атрибуты элемента ‹trace›

Атрибут Описание enabled Индикатор разрешения трассировки для приложения в целом (значением по умолчанию является false – ложь). Как было показано в предыдущей главе, можно разрешить трассировку селективно для данного файла *.aspx, используя директиву @Page localOnly Индикатор отображения информации трассировки только на Web-сервере, но не в системах удаленных клиентов (значением по умолчанию является true – истина) pageOutput Указывает вид представления результатов трассировки requestLimit Указывает число запросов трассировки, сохраняемых на сервере. Значением по умолчанию является 10. Если достигается предел, трассировка автоматически отключается traceMode Указывает соответствие порядка отображения информации трассировки порядку ее обработки. Значением по умолчанию является SortByTime (сортировка по времени), но можно также указать сортировку по категории

Вспомните из предыдущей главы, что с помощью директивы ‹%@Page%› можно разрешить трассировку отдельных страниц. Но если вы хотите разрешить трассировку для всех страниц Web-приложения, измените ‹trace› в файле Web.config, как показано ниже.

‹trace enabled="true" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" /›

Настройка вывода сообщений об ошибках с помощью ‹customErrors›

Элемент ‹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 так, как предлагается ниже.