Обновление ASP.NET 1.1 до IIS 7.0 в Windows Vista и Windows Server 2008
от команды IIS
Введение
Для разработчиков приложений ASP.NET, которые переходят на операционную систему Windows Vista™ или более поздней версии, IIS 7.0 и более поздних версий представляют собой значительный прогресс по сравнению с более ранними версиями IIS. Режим интеграции IIS обеспечивает повышенную безопасность и новые возможности приложений, а также другие улучшения.
Большинство разработчиков, которые переходят на Windows Vista, переходят с операционной системы Microsoft Windows® XP на Windows Vista и обновляют свои ASP.NET приложения в процессе. Или они устанавливают в Windows Vista ASP.NET приложения, разработанные в других операционных системах Windows.
В этом документе подробно описаны важные действия по настройке после установки и обновления, которые необходимо выполнить, чтобы приложения работали в новой операционной системе. В ней описываются изменения между классическим режимом и режимом интеграции IIS, влияющие на ASP.NET приложения, а также способы обхода этих известных проблем.
Одним из значительных улучшений в IIS 7.0 и более поздних версий является встроенная функция конвейера, которая позволяет веб-приложениям использовать один конвейер обработки запросов из управляемых или неуправляемых приложений кода. Кроме того, новая модель конвейера сокращает избыточное поведение, которое является результатом двух отдельных реализаций одной функции.
Например, в предыдущих выпусках IIS и ASP.NET реализовали отдельные конвейеры запросов, которые не совместно используют доступ к событиям и модулям обработчика. Проверка подлинности выполнялась независимо в каждом конвейере. В новой модели проверку подлинности можно выполнить один раз для IIS и ASP.NET.
К другим преимуществам этой интеграции относятся:
- ASP.NET службы, такие как проверка подлинности на основе форм и роли, работающие с типами контента IIS, например статические и классические страницы ASP.
- Функциональные возможности IIS, расширяющиеся с помощью управляемого кода и ASP.NET модулей конвейера, а не только с расширениями ISAPI или CGI.
- Упрощение устранения неполадок в результате интеграции трассировки событий и ведения журнала ошибок.
- Совместное использование конфигурации приложения между ASP.NET и IIS.
В этой статье рассматриваются проблемы совместимости для приложений ASP.NET, которые переносятся с более ранних версий IIS на IIS 7.0 и более поздних версий, и особое внимание уделяется различиям, связанным с переходом из классического режима на использование интегрированного конвейера в режиме интеграции.
Полный обзор функций и преимуществ интеграции ASP.NET и IIS см. в статье ASP.NET Интеграция с IIS 7.0 и более поздних версий.
Обновление с более ранних версий IIS до Windows Vista
На следующей диаграмме показана доступность СЛУЖБ IIS 7.0 в доступных версиях Windows Vista:
| Версия Windows Vista | Доступность IIS 7.0 |
|---|---|
| Домашняя базовая | Нет |
| Домашняя расширенная | Да |
| бизнеса | Да |
| Ultimate | Да |
Сценарии обновления ASP.NET в Windows Vista
В следующей таблице представлен краткий обзор поддерживаемых путей обновления для ASP.NET в более ранних версиях операционных систем Windows для ASP.NET в Windows Vista. Дополнительные сведения об ограничениях и ограничениях обновления см. в следующих разделах.
В таблице также показано, что обновления с версий ОС сервера до версий клиентских ОС недоступны. Вместо этого необходимо выполнить чистую установку Vista на компьютере с установленной серверной ОС.
| Операционная система | Версия IIS | Версия платформы .NET Framework | Рекомендации при обновлении до Windows Vista и IIS 7.0 |
|---|---|---|---|
| Windows 2000 Server | IIS 5.0 | 1.0, 1.1, 2.0 | Обновление до Windows Vista недоступно. |
| Windows 2000 Professional | IIS 5.0 | 1.0, 1.1, 2.0 | Требуется чистая установка ОС. |
| Windows Server 2003 | IIS 6,0 | 1.0, 1.1, 2.0 | Обновление до Windows Vista недоступно. |
| Windows XP Домашняя | Н/Д | 1.0, 1.1, 2.0 | Windows XP Home не включает IIS. Пользователи могут решить установить службы IIS 7.0 или более поздней версии в Windows Vista. |
| Windows XP Professional | IIS 5,1 | 1,0 | Платформа .NET Framework 1.0 не поддерживается в Windows Vista. ASP.NET 1.0 приложения должны быть обновлены как минимум до ASP.NET 1.1 (рекомендуется ASP.NET 2.0). |
| 1,1 | После обновления требуется настройка вручную (см. далее в этой статье). | ||
| 2,0 | ASP.NET необходимо выбрать в параметрах настройки IIS после обновления, чтобы ASP.NET 2.0 можно было настроить в режиме интеграции. | ||
| Windows XP Tablet PC | IIS 5,1 | 1,0 | Платформа .NET Framework 1.0 не поддерживается в Windows Vista. ASP.NET 1.0 приложения должны быть обновлены как минимум до ASP.NET 1.1 (рекомендуется ASP.NET 2.0). |
| 1,1 | После обновления требуется настройка вручную (см. далее в этой статье). | ||
| 2,0 | ASP.NET необходимо выбрать в параметрах настройки IIS после обновления, чтобы ASP.NET 2.0 можно было настроить в режиме интеграции. | ||
| Windows XP Professional x64 | IIS 5,1 | 1.1, 2.0 | Требуется чистая установка ОС. |
Конфигурация приложения после установки
Сразу после установки или обновления до Windows Vista пользователи должны выполнить дополнительные действия по настройке, чтобы обеспечить работу приложений. Конфигурация после установки зависит от версии ASP.NET, используемой каждым приложением.
Настройка приложений ASP.NET 1.1
Перед установкой платформа .NET Framework 1.1 (которая необходима при использовании приложений ASP.NET версии 1.1) пользователи должны выполнить следующие два действия, чтобы включить ASP.NET приложения:
Процедура
Каждый пул приложений IIS, в котором выполняется приложение ASP.NET, должен быть явно настроен с использованием версии платформа .NET Framework, которая соответствует версии ASP.NET, используемой для приложения. Для каждого пула приложений можно запускать только одну версию ASP.NET, поэтому для каждой версии ASP.NET необходимо использовать отдельные пулы приложений.
В консоли диспетчера IIS откройте пулы приложений, щелкните пул приложений правой кнопкой мыши и выберите Основные параметры. В диалоговом окне Изменение пула приложений, показанном на рис. 1, выберите версию платформа .NET Framework, соответствующую приложениям, настроенным в пуле приложений, и нажмите кнопку ОК.
Рис. 1. Изменение параметров пула приложений
Использование ASP.NET 1.1 в классическом режиме
ASP.NET 1.1 использует расширение IIS ISAPI при работе в классическом режиме, который является параметром по умолчанию для ASP.NET после установки или обновления (обратите внимание, что ASP.NET 2.0 также может работать в режиме интеграции в Windows Vista, который не требует расширения ISAPI).
Необходимо явно разрешить версию ASP.NET, используемую приложениями, с помощью конфигурации ограничений ISAPI и CGI в консоли управления IIS. Откройте диспетчер IIS и выберите ISAPI и ограничения CGI. На странице Ограничения ISAPI и CGI выберите в столбце Ограничения каждую версию ASP.NET, для которых задано значение Не разрешено, и щелкните ссылку Разрешено в правой части страницы, чтобы изменить параметр на Разрешено.
На рисунке 2 показан пример страницы ограничений ISAPI и CGI с выбранной версией сборки Aspnet_isapi.dll, используемой для ASP.NET 1.1. На рисунке параметр для этого расширения ISAPI должен быть изменен с Не разрешено на Разрешено.
Рис. 2. Список ограничений ISAPI и CGI
Настройка приложений ASP.NET 2.0
Платформа .NET Framework 2.0 устанавливается во время установки Windows Vista, поэтому ASP.NET 2.0 уже присутствует на сервере после установки. Однако для завершения настройки ASP.NET в Vista для приложений ASP.NET 2.0 пользователи должны выполнить следующие два действия:
Шаг 1
В диспетчере пакетов Windows Vista (панель управления\Программы и компоненты\Включить или выключить компоненты Windows) выберите ASP.NET, как показано на рисунке 3, и нажмите кнопку ОК.
Примечание
Если ASP.NET уже установлена на компьютере перед этим шагом, выбор ASP.NET таким образом гарантирует выполнение дополнительных действий по настройке.
Рис. 3. Установка Windows Vista — компоненты Windows
Шаг 2
Каждый пул приложений IIS, в котором выполняется ASP.NET приложение, должен быть явно настроен с использованием версии платформа .NET Framework, которая соответствует версии ASP.NET, используемой для приложения. Для каждого пула приложений можно запустить только одну версию ASP.NET, поэтому для каждой версии ASP.NET необходимо использовать отдельные пулы приложений.
В диспетчере IIS откройте пулы приложений, щелкните правой кнопкой мыши пул приложений и выберите Основные параметры. В диалоговом окне Изменение пула приложений, показанном на рис. 4, выберите версию платформа .NET Framework, соответствующую приложениям, настроенным в пуле приложений, и нажмите кнопку ОК.
Рис. 4. Пул приложений & режиме интеграции
Параметры пула приложений
При обновлении ASP.NET приложений в более ранних версиях операционных систем Windows до Windows Vista приложения настраиваются в пулах приложений на основе параметров изоляции приложений IIS следующим образом:
| Конфигурация изоляции IIS перед обновлением | Пулы приложений IIS | Удостоверение пула приложений IIS |
|---|---|---|
| Низкий | AppPool Low | NT AUTHORITY\NETWORK SERVICE |
| Средний | AppPool Medium | <имя IWAM_машина> |
| Высокий | Приложения настраиваются в пуле приложений с соответствующим именем приложения. | <имя IWAM_машина> |
ASP.NET версии 1.0 не поддерживается в Windows Vista
Платформа .NET Framework 1.0 не поддерживается в Windows Vista, поэтому ASP.NET приложений версии 1.0 необходимо обновить по крайней мере до ASP.NET 1.1. Мы настоятельно рекомендуем обновить приложения ASP.NET 1.0 до ASP.NET 2.0, чтобы воспользоваться преимуществами более высокой производительности и поддержки, которые доступны в более поздних версиях ASP.NET.
Обработчики HTTP
При обновлении до IIS 7.0 и более поздних версий в Windows Vista обновляются только предварительные обработчики HTTP, настроенные на глобальном уровне. Обработчики, настроенные на уровне сайта, не обновляются.
Параллельная поддержка
Приложения, разработанные в разных версиях ASP.NET (например, 1.1 и 2.0), можно запускать параллельно в IIS. Необходимо настроить приложения в пуле приложений IIS. Этот пул должен быть настроен для версии ASP.NET, для которой было разработано приложение. Для каждого пула приложений можно настроить только одну версию ASP.NET.
Для платформа .NET Framework 1.1 требуется конфигурация WoW 64 в 64-разрядной версии Windows Vista
ASP.NET настроен неправильно, если платформа .NET Framework 1.1 установлен в 64-разрядных версиях Windows Vista. После установки платформа .NET Framework 1.1 в 64-разрядных версиях Windows Vista необходимо вручную настроить приложения для запуска с помощью WOW 64 на глобальном уровне с помощью средства администрирования IIS.
Настройка режима конвейера, используемого приложением
Службы IIS настроены для использования нового интегрированного режима для новых приложений. Это поведение по умолчанию. Режим конвейера настраивается с помощью параметров пула приложений. Измените эти параметры, используя один из следующих способов:
- Средство администрирования IIS
- Программа командной строки APPCMD.EXE
- Изменение файла конфигурации приложения с помощью текстового редактора
При обновлении существующего компьютера до IIS 7.0 или более поздней версии приложения по умолчанию настроены для работы в классическом режиме. Классический режим обеспечивает совместимость приложений, имеющих определенные зависимости от реализации конвейера HTTP в более ранних версиях IIS.
Однако если вы импортируете существующее приложение на компьютер под управлением IIS 7.0 и более поздних версий и копируете веб-сайт, используемый режим конвейера определяется параметрами пула приложений, в котором настроено выполнение приложения.
Например, если вы копируете приложение на компьютер и настраиваете его для запуска в пуле приложений по умолчанию, оно запускается с использованием параметров этого пула приложений, которые по умолчанию настроены в режиме интеграции. Чтобы изменить режим конвейера для приложения, измените параметры пула приложений по умолчанию или создайте новый пул приложений с нужными параметрами.
Дополнительные сведения о настройке существующего приложения для использования интегрированного режима см. в статье ASP.NET интеграции со службами IIS 7.0 и более поздних версий в разделе "Миграция приложений ASP.NET в интегрированный режим IIS 7.0 и более поздних версий". Здесь приведены инструкции по изменению параметров конфигурации приложения.
Совместимость
ASP.NET модули конвейера, разработанные для более ранних версий IIS и настроенные для использования интегрированного режима со службами IIS 7.0 и более поздних версий, могут столкнуться с различиями в поведении или другими проблемами совместимости. Такие проблемы вызваны различиями в архитектуре конвейера в более ранних версиях IIS, модульной структурой IIS 7.0 и более поздних версий, а также интегрированным конвейером HTTP.
В остальных разделах этой статьи описываются потенциальные проблемы совместимости, с которыми могут столкнуться приложения, и приводятся предлагаемые обходные пути. Если предлагаемое решение нецелесообразно реализовать, настройте приложение для запуска в классическом режиме, чтобы избежать проблем с совместимостью.
Известные различия между интегрированным и классическим режимами
Ниже приведен список известных проблем между этими двумя режимами. Внимательно прочитайте этот список.
В режиме интеграции Application_OnError не вызывается для исключений, возникающих в HttpApplication::Init.
В режиме интеграции исключения, возникающие во время инициализации приложения или модуля, не могут быть перехвачены с помощью события Application.Error.
Кроме того, приложения, использующие Server.ClearError для восстановления после ошибок, не могут устранить ошибки во время инициализации приложения. Это необходимо, чтобы приложение не игнорировало ошибку во время инициализации. Приложения, которые регистрируют сведения об ошибках для каждого исключения, не смогут регистрировать ошибки, возникающие во время инициализации приложения, хотя эти ошибки сообщаются с помощью веб-событий и HTTP-ответов.
Если приложению требуется реализация такой обработки исключений во время инициализации, оно должно выполняться в классическом режиме, а не в режиме интеграции.
Server.ClearError в EndRequest не очищает сообщение об исключении в интегрированном режиме
В интегрированном режиме вызов Server.ClearError в EndRequest не очищает ответ об исключении, если исключение произошло ранее при обработке запроса. Приложения, очищающие сообщение об исключении в EndRequest, не могут удалить выходные данные исключения из ответа.
Если приложению требуется реализация такой обработки исключений во время EndRequest, оно должно выполняться в классическом режиме, а не в режиме интеграции.
Приложения в интегрированном режиме могут записывать данные в ответ в EndRequest после форматирования исключения и записи в ответ.
В режиме интеграции можно выполнить запись в и отобразить дополнительный ответ, записанный после возникновения исключения.
Это не происходит в классическом режиме. Если во время запроса возникает ошибка и приложение записывает в ответ в EndRequest после возникновения исключения, отображаются сведения об ответе, записанные в EndRequest. Это влияет только на запросы, которые включают необработанных исключений.
Чтобы избежать записи в ответ после исключения, приложение должно проверка HttpContext.Error или HttpResponse.StatusCode перед записью в ответ.
В интегрированном режиме ASP.NET больше не подавляет тип контента, если ответ пуст.
В режиме интеграции обработчики ASP.NET создают заголовки типа контента при явном указании модулем, даже если ответ пуст. Некоторые приложения создают тип контента для пустых ответов. При необходимости измените приложения, чтобы явно удалить заголовок Типа контента, установив для него значение NULL.
Разные удостоверения Windows в проверке подлинности с помощью Форм
Если приложение использует проверку подлинности с помощью форм и разрешен анонимный доступ, удостоверение встроенного режима отличается от удостоверения классического режима следующими способами:
- Заполнено значение ServerVariables["LOGON_USER"].
- Request.LogognUserIdentity использует учетные данные учетной записи [NT AUTHORITY\NETWORK SERVICE] вместо учетной записи [NT AUTHORITY\INTERNET USER].
Такое поведение происходит из-за того, что проверка подлинности выполняется на одном этапе в режиме интеграции. И наоборот, в классическом режиме проверка подлинности выполняется сначала в службах IIS с анонимным доступом, а затем с ASP.NET с помощью проверки подлинности с помощью форм. Таким образом, результатом проверки подлинности всегда является один пользователь — пользователь проверки подлинности на основе форм. AUTH_USER/LOGON_USER возвращает этого же пользователя, так как учетные данные пользователя проверки подлинности на основе форм синхронизируются между СЛУЖБАми IIS и ASP.NET.
Побочным эффектом является то, что LOGON_USER, HttpRequest.LogonUserIdentity и олицетворение больше не могут получить доступ к учетным данным анонимного пользователя, которые IIS прошли проверку подлинности в классическом режиме.
Событие Authentication_OnAuthenticate по умолчанию не вызывается в интегрированном режиме
В режиме интеграции событие DefaultAuthenticationModule.Authenticate больше не вызывается. В классическом режиме это событие возникает, если проверка подлинности не выполнялась. В режиме интеграции приложение, которое устанавливает режим проверки подлинности =Нет и подписывается на событие DefaultAuthentication.Authentication, получит исключение, указывающее, что эта функция не поддерживается в режиме интеграции. Схемы проверки подлинности, основанные на этом шаблоне, не будут работать.
Чтобы обойти это изменение, приложения в интегрированном режиме могут подписаться на AuthenticateRequest.
В режиме интеграции Request.RawUrl содержит новую строку запроса после вызова RewritePath.
В режиме интеграции после вызова RewritePath по URL-адресу с новой строкой запроса свойство Request.RawUrl содержит новую строку запроса. В классическом режиме он содержит старую строку запроса.
Чтобы обойти это изменение, перезапишите приложение, чтобы оно не зависело от старого поведения.
Проверка подлинности с сетевыми учетными данными Passport не поддерживается в Windows Vista
Функции учетных данных Passport Network удалены из Windows Vista и операционной системы Microsoft Windows Server® 2008, поэтому приложения для проверки подлинности учетных данных Passport Network не работают по умолчанию в ISAPI или интегрированном режиме.
Модуль PassportAuthentication не является частью интегрированного конвейера
В режиме интеграции модуль проверки подлинности ASP.NET Passport удаляется из конвейера по умолчанию. Если он используется приложением, его можно добавить обратно в конвейер. Как упоминалось выше, базовые функции учетных данных Passport Network удалены из Windows Vista и Microsoft Windows Server 2008, поэтому приложения проверки подлинности учетных данных Passport Network не работают по умолчанию в ISAPI или интегрированном режиме.
Большие допустимые билеты проверки подлинности форм (длина <= 4096 байт), присутствующих в строке запроса, отклоняются службами IIS 7.0 и более поздних версий.
IIS отклоняет запросы с большими запросами ASP.NET без файлов cookie, например запросы, используемые в проверке подлинности на основе форм, состоянии сеанса и анонимном идентификаторе, общая сумма которых превышает 4096 байт. По соображениям безопасности это предотвращает переполнение буфера эксплойтами, которые используют большие строки запроса. Приложения, в которых хранятся пользовательские данные или используют очень большие имена пользователей в запросах проверки подлинности с помощью форм, могут видеть, что запросы отклоняются из-за слишком большого размера строк запроса.
Чтобы изменить это поведение, настройте максимальный размер строки запроса в разделе конфигурации фильтрации запросов IIS.
В режиме интеграции время ожидания ASP.NET запроса применяется несколько раз во время запроса, что позволяет выполнять запрос дольше.
В режиме интеграции время ожидания выполнения управляемого запроса сбрасывается для каждого нового перехода в конвейере. Это означает, что запрос может использовать до (время ожидания *(# уведомлений модуля)), если любой отдельный тайм-аут не превышает максимальное время, заданное для времени ожидания.
Медленные запросы могут быть не прерваны или занять значительно больше времени перед прерыванием, в зависимости от количества ASP.NET модулей и того, насколько хорошо эти модули объединяются вместе. Избегайте такого поведения, уменьшая время ожидания.
Параметры трассировки не передаются на целевую страницу Server.Transfer
Встроенный режим не поддерживает передачу параметров трассировки в целевой объект операции Server.Transfer.
Метод Httpcontext.Current.Response.Write() не может работать в Application_Onstart()
В режиме интеграции приложение не может вызвать Http.Current.Response.Write() в методе Application_Onstart().
HttpRequest.LogonUserIdentity создает исключение при обращении к postAuthenticateRequest
В режиме интеграции свойство HttpRequest.LogonUserIdentity создает исключение при обращении к нему до PostAuthenticateRequest. Если модуль обращается к этому свойству до PostAuthenticateRequest, создается исключение.
Чтобы избежать такого поведения: не обращаться к этому свойству в приложении; или получите к нему доступ после завершения PostAuthenticateRequest.
В режиме интеграции при отключении анонимной проверки подлинности модули ASP.NET получат первый запрос к СЛУЖБАм IIS 7.0 и более поздних версий без проверки подлинности.
В режиме интеграции при использовании схемы проверки подлинности IIS, отличной от анонимной проверки подлинности, первый запрос от клиента, не содержащий необходимые учетные данные, отображается ASP.NET модулям на этапах BeginRequest и AuthenticateRequest.
Для сравнения, в классическом режиме приложение ASP.NET не увидит такого запроса, так как IIS отклоняет его с помощью запроса 401, прежде чем ASP.NET сможет обработать его.
Это означает, что ASP.NET модулям будет отображаться дополнительный запрос на этапах BeginRequest и AuthenticateRequest. Запрос отображается в веб-событиях и во всех пользовательских журналах, выполненных в BeginRequest или EndRequest.
ASP.NET не может олицетворить удостоверение клиента до postAuthenticateRequest
В режиме интеграции ASP.NET не олицетворяет клиента до postAuthenticateEvent, если олицетворение клиента включено для приложения с помощью Web.config приложения или в Machine.config.
Кроме того, если олицетворение клиента включено, модули, работающие в событиях BeginRequest и AuthenticateRequest, выполняются с удостоверением процесса, а не с удостоверением пользователя, прошедшего проверку подлинности. Это не должно быть проблемой, так как модули редко обращаются к ресурсам в этих событиях, так как пользователь, прошедший проверку подлинности, еще не установлен.
Однако в этом случае удостоверение процесса используется для доступа к ресурсам.
Из-за возможного повышения прав пользователя, которое может вызвать это изменение, СЛУЖБЫ IIS создает исключение при включении олицетворения клиента. Это означает, что приложение должно быть перемещено в классический режим или эта ошибка должна быть отключена, если можно подтвердить доступ к ресурсам в событиях BeginRequest или AuthenticateRequest.
Заголовок Content-Type не создается, если для кодировки и типа контента задана пустая строка
HTTP.sys больше не создает заголовок Content-Type, если для него явно задано значение String.Empty. Это изменение может повлиять на приложения, клиенты которых используют пустой заголовок Content-Type.
В режиме интеграции синхронные и асинхронные события вызываются для каждого модуля перед выполнением следующего модуля.
В режиме интеграции синхронные и асинхронные события будут вызываться для каждого модуля, прежде чем сервер перейдет к следующему модулю.
Это отличается от классического режима, в котором сначала выполняются все асинхронные уведомления модуля, а затем все синхронные уведомления. Это не должно влиять на приложения, если нет зависимости от упорядочения (см. раздел "Порядок модулей отменен для PreSendRequestHeaders и PreSendRequestContent при использовании режима интеграции" в другом месте этого документа).
Заголовки ответов удаляются в интегрированном режиме после вызова ClearHeader в пользовательском модуле IHttpModule.
В режиме интеграции вызов ClearHeaders не создает заголовки по умолчанию автоматически. Приложения, вызывающие ClearHeaders, возвращают заголовки в состояние по умолчанию для aspx-страницы, а не очищают все заголовки ответов.
Совместное использование проверки подлинности Windows и Forms в режиме интеграции не поддерживается
В режиме интеграции параметр Impersonate=true и использование проверки подлинности с помощью форм не поддерживается и вызывает ошибку или неправильное поведение.
В режиме интеграции IIS 7.0 и более поздних версий всегда отклоняет новые строки в заголовках ответов (даже если ASP.NET enableHeaderChecking имеет значение false).
В режиме интеграции при попытке задать заголовок ответа значение , содержащее \r или \n, возникает исключение. В классическом режиме это значение кодируется по умолчанию и передается, если кодировка заголовков отключена. По соображениям безопасности приложения не должны пытаться записывать незакодированные новые строки в значениях заголовков.
События PreSendRequestHeaders и PreSendRequestContent будут создаваться вместе для каждого модуля.
В режиме интеграции модули, которые подписываются на события PreSendRequestHeaders и PreSendRequestContent, вместе уведомляются о событиях PreSendRequestHeaders и PreSendRequestContent.
Например, приложение может прервать работу, если модуль A имеет зависимость от модуля B, выполняющегося сначала в PreSendRequestHeaders, перед запуском модуля A для PreSendRequestContent, например, если модуль B изменяет некоторое состояние запроса и модуль A полагается на него.
Порядок модулей отменяется для PreSendRequestHeaders и PreSendRequestContent при использовании режима интеграции.
В режиме интеграции модули, которые подписываются на PreSendRequestHeaders и PreSendRequestContent, будут получать уведомления в обратном порядке о своем появлении в разделе. Это изменение влияет на приложения с несколькими модулями, настроенными для выполнения в любом из этих событий, если они имеют зависимость от упорядочения событий.
Чтобы обойти такие проблемы, измените порядок модулей в разделе или запустите приложение в классическом режиме.
В режиме интеграции параметры потоков и очередей в игнорируются.
В режиме интеграции ASP.NET, а не IIS, обрабатывает запросы в потоках и не использует семантику потоков или очередей, используемую в классическом режиме. Из-за этой разницы пропускная способность или стрессовое поведение приложений в режиме интеграции может отличаться от поведения при работе в классическом режиме.
Если при использовании режима интеграции возникает ошибка файла конфигурации, службы IIS, а не ASP.NET, создает сообщение об ошибке.
Для приложений, работающих в режиме интеграции, службы IIS теперь считывают файлы конфигурации приложения. Таким образом, если в файле Web.config обнаружен неправильный ФОРМАТ XML или в файле есть ошибки конфигурации, службы IIS всегда создает сообщение об ошибке, а не ASP.NET.
Так как IIS и ASP.NET записывать ошибки в разных форматах, формат сообщения об ошибке зависит от того, работает ли приложение в режиме интеграции или в классическом режиме. Ниже приведен пример ошибки одного типа файла конфигурации, создаваемой службами IIS: внутренняя ошибка конфигурации сервера: файл конфигурации не имеет правильного формата XML
В режиме интеграции приложения ASP.NET должны подписываться на события конвейера во время вызова init модуля.
ASP.NET приложения, использующие конвейер HTTP ASP.NET, могут подписываться на события приложения за пределами конвейера. Однако ASP.NET приложения, использующие конвейер режима интеграции IIS, теперь должны всегда подписываться на события во время метода Init() модуля. В следующем примере показано, как реализована подписка на события в init:
Public void Init(httpApplication context)
{
Context.AuthenticateRequest += new EventHandler(this.AuthenticateUser);
}
Дополнительные сведения о создании модулей IIS см. в статье Разработка модуля с помощью .NET.
Дополнительные ресурсы
Дополнительные сведения об обновлении до IIS 7.0 и более поздних версий в Windows Vista см. в статье Совместимость приложений IIS 7.0 в Windows Vista, Требования к совместимости и компонентам для Windows Vista.