интеграция ASP.NET с IIS 7

Майк Володарский

Введение

С момента выпуска ASP.NET была платформой для разработки веб-приложений на платформе Windows или IIS. ASP.NET 2.0 заняла новый уровень разработки веб-приложений, что позволяет разработчикам создавать более мощные приложения быстрее, чем когда-либо раньше.

IIS 7 и более поздние версии продвигают ASP.NET, интегрируя модель расширяемости среды выполнения ASP.NET с основным сервером. Это позволяет разработчикам полностью расширить сервер IIS с широкими возможностями ASP.NET 2.0 и .NET Framework, а не использовать менее способные API IIS C++. Существующие приложения ASP.NET также сразу же получают более тесную интеграцию с помощью существующих функций ASP.NET, таких как проверка подлинности, роли и кэширование выходных данных для всего содержимого.

Хотя IIS по умолчанию предлагает улучшенную интеграцию с ASP.NET, у пользователей есть выбор: IIS поддерживает как новые, так и старые режимы интеграции ASP.NET, которые можно использовать параллельно на одном сервере.

В этой статье рассматриваются улучшения, представленные режимом интеграции ASP.NET, архитектурой двух режимов, а также описывается, как выбрать и настроить режимы интеграции для ASP.NET приложений.

усовершенствования ASP.NET в IIS 7 и более поздних версиях

Улучшенная интеграция ASP.NET в IIS улучшает существующие приложения, а также позволяет новым приложениям воспользоваться преимуществами функций ASP.NET следующими способами:

• ASP.NET службы можно использовать для всех типов контента. В прошлом ASP.NET функции, такие как проверка подлинности форм, роли, авторизация URL-адресов и кэширование выходных данных, доступны только для ASP.NET типов контента, таких как страницы ASPX. Статические файлы, страницы ASP и другие типы контента не могут воспользоваться этими службами.

В СЛУЖБАх IIS все службы ASP.NET предоставляются одинаково для всего содержимого. Например, вы можете защитить все веб-содержимое, включая изображения и страницы ASP, с помощью существующего решения управления доступом ASP.NET 2.0, созданного на основе проверки подлинности ASP.NET Forms, элементов управления членством и именами входа.

• Полностью расширяйте службы IIS с помощью ASP.NET. Предыдущие версии IIS часто требуют расширяемости сервера с помощью собственного фильтра ISAPI или режима расширяемости расширений из-за ограничений среды выполнения ASP.NET.

IIS позволяет ASP.NET модулям подключаться непосредственно к конвейеру сервера с той же точностью среды выполнения, что и модули, разработанные с помощью собственного API сервера (C++). модули ASP.NET могут выполняться во всех этапах выполнения конвейера обработки запросов и выполняться в любом порядке относительно собственных модулей. API ASP.NET также расширяется, чтобы обеспечить более контроль над обработкой запросов, чем было возможно ранее.

• Единая среда выполнения сервера. Более жесткая ASP.NET интеграция также объединяет многие функции между IIS и ASP.NET.

IIS предоставляет унифицированную конфигурацию для модулей и обработчиков служб IIS и ASP.NET. Многие другие функции, включая пользовательские ошибки и трассировку, были унифицированы, чтобы обеспечить более эффективное управление и согласованное проектирование приложений.

Архитектура интеграции ASP.NET

В IIS 6.0 и предыдущих выпусках ASP.NET реализован в виде расширения ISAPI IIS.

В этих более ранних версиях IIS обрабатывал запрос к типу контента ASP.NET, а затем перенаправлял этот запрос в ASP.NET ISAPI DLL, в которой размещался конвейер запросов ASP.NET и фреймворк страницы. Запросы на non-ASP.NET содержимое, например страницы ASP или статические файлы, обрабатывались службами IIS или другими расширениями ISAPI и не были видимы для ASP.NET.

Основным ограничением этой модели было то, что службы, предоставляемые модулями ASP.NET и пользовательскими ASP.NET кодом приложения, недоступны для non-ASP.NET запросов. Кроме того, модули ASP.NET не смогли повлиять на некоторые части обработки запросов IIS, которые произошли до и после пути выполнения ASP.NET.

Рис. 1. Конвейеры IIS 6.0 и ASP.NET

В IIS конвейер обработки запросов ASP.NET фактически перекрывает конвейер IIS, предоставляя оболочку вместо интеграции.

Службы IIS обрабатывают запросы, поступающие для любого типа контента, с собственными модулями IIS и модулями ASP.NET, предоставляющими обработку запросов на всех этапах. Это позволяет службам, предоставляемым модулями ASP.NET, таким как проверка подлинности форм или кэш выходных данных, использоваться для запросов на страницы ASP, страницы PHP, статические файлы и т. д.

Возможность подключаться непосредственно к конвейеру сервера позволяет модулям ASP.NET заменить, выполняться до или после любых функций IIS. Это позволяет, например, использовать пользователю модуль базовой проверки подлинности ASP.NET, разработанный для работы с службой Membership и пользовательской базой данных SQL Server, для замены встроенной функции базовой проверки подлинности IIS, которая работает только с учетными записями Windows.

Кроме того, развернутые ASP.NET API используют прямую интеграцию для включения дополнительных задач обработки запросов. Например, модули ASP.NET могут изменять заголовки запросов перед обработкой запроса другими компонентами, вставляя заголовок Accept-Language перед выполнением приложений ASP, что заставляет локализованное содержимое отправляться клиенту на основе предпочтений пользователя.

Рис. 2. Режим интеграции IIS 7 и выше

Из-за интеграции среды выполнения IIS и ASP.NET могут использовать ту же конфигурацию, чтобы включить и упорядочить серверные модули, а также настроить сопоставления обработчиков. Другие унифицированные функции включают трассировку, пользовательские ошибки и кэширование выходных данных.

Совместимость

В частности, архитектура поддерживает архитектуру среды выполнения ASP.NET и API, что позволяет существующим ASP.NET приложениям и службам работать при установке. При нескольких изменениях существующие ASP.NET приложения и службы могут воспользоваться новыми возможностями ASP.NET.

Аналогичным образом разработчики могут продолжать писать новые приложения для знакомых ASP.NET API, а также использовать преимущества интеграции среды выполнения.

Службы IIS по-прежнему предоставляют классический режим ASP.NET для приложений ASP.NET, имеющих определенные требования к совместимости, которые не соответствуют интегрированному режиму. Администраторы могут выбрать нужный режим интеграции для пула приложений, что позволяет приложениям использовать новые и классические режимы ASP.NET для параллельной работы на одном сервере.

Перенос приложений ASP.NET в режим интеграции IIS 7 и более поздних версий

На IIS ASP.NET настроено для работы в новом интегрированном режиме по умолчанию. Это позволяет приложению воспользоваться усовершенствованиями встроенного режима с минимальными изменениями.

Из-за объединения конфигурации некоторым приложениям может потребоваться миграция для правильной работы в интегрированном режиме. По умолчанию сервер обеспечивает помощь в миграции. Он обнаруживает приложения, требующие миграции, и возвращает сообщение об ошибке, запрашивающее перенос приложения.

Следующая конфигурация приводит к ошибке миграции:

1. Файл Web.config приложения определяет <конфигурацию httpModules> .
   Приложение загружает новые модули ASP.NET или удаляет существующие.
   В интегрированном режиме модули ASP.NET указываются с собственными модулями в разделе конфигурации унифицированного <system.webServer>/<modules> .
   Модули ASP.NET, указанные в разделе конфигурации system.web</>httpModules<, должны быть перемещены в >новый раздел конфигурации, чтобы ввести в силу новый раздел конфигурации. Впоследствии новые модули ASP.NET должны быть добавлены непосредственно в единый <modules> раздел.
2. Файл Web.config приложения определяет <httpHandlers> конфигурацию.
   Приложение использует сопоставления пользовательских обработчиков для нескольких типов содержимого.
   В интегрированном режиме сопоставления обработчиков ASP.NET должны быть указаны в унифицированном разделе конфигурации <system.webServer>/<handlers>, чтобы вступить в силу. Впоследствии новые сопоставления обработчиков ASP.NET должны быть добавлены непосредственно в единый <handlers> раздел.
   Этот раздел заменяет конфигурацию ASP.NET <httpHandlers> и конфигурацию карт сценариев IIS, оба из которых ранее должны быть настроены для настройки сопоставления обработчика ASP.NET.
3. Файл приложения Web.config определяет <имперсонификацию="true" /> конфигурация.
   Приложение олицетворяет учетные данные клиента, что чаще всего используется в приложениях интрасети. В интегрированном режиме олицетворение клиента недоступно на некоторых ранних этапах обработки запросов. В большинстве случаев это не проблема, и вы можете отключить ошибку миграции. В противном случае необходимо настроить это приложение для запуска с помощью классического режима ASP.NET.

При возникновении ошибки миграции обычно можно перенести конфигурацию приложения (рекомендуется в случаях 1 и 2 выше) или переместить приложение для использования классического режима ASP.NET (в случае 3).

Перенос конфигурации приложения

IIS переносит приложение с помощью инструмента командной строки AppCmd.exe для миграции. Сообщение об ошибке миграции содержит команду, выполняемую в окне командной строки, которую необходимо запустить с правами администратора, чтобы мгновенно перенести приложение в интегрированный режим.

Базовый формат команды миграции выглядит следующим образом:

%windir%\system32\inetsrv\APPCMD.EXE migrate config <Application Path>

Где <путь> приложения — это виртуальный путь приложения, содержащего имя сайта, например "Веб-сайт или приложение1 по умолчанию".

После завершения миграции приложение будет работать как в интегрированных, так и классических режимах без каких-либо проблем.

Переход к классическому режиму интеграции ASP.NET

Если вы хотите вернуться в классический режим ASP.NET, переместите приложение в пул приложений, настроенный для запуска в классическом режиме. Другие приложения продолжают работать в новом интегрированном режиме параллельно с приложением классического режима.

Дополнительные сведения о перемещении приложения в классический режим ASP.NET см. в разделе "Изменение режимов ASP.NET для приложения".

Отключение сообщения об ошибке миграции

Если вы вручную выполнили миграцию конфигурации или хотите остаться в интегрированном режиме без переноса конфигурации (не рекомендуется), можно отключить сообщение об ошибке миграции, добавив следующее в файл Web.config приложения:

<system.webServer> 
    <validation validateIntegratedModeConfiguration="false" />    
</system.webServer>

Если вы вручную отключите сообщение об ошибке миграции, необходимо убедиться, что приложение работает правильно в интегрированном режиме, так как сервер больше не будет предоставлять предупреждения о неподдерживаемой конфигурации.

Изменение режимов ASP.NET для приложения

Если приложение работает неправильно в режиме встроенной ASP.NET, его можно переместить в классический режим ASP.NET, переместив его в другой пул приложений. Каждый пул приложений настраивается отдельно для использования требуемого режима интеграции ASP.NET. Это позволяет запускать группы приложений, использующих разные режимы интеграции ASP.NET параллельно на одном сервере.

Чтобы изменить режим интеграции ASP.NET для приложения, выполните следующие действия.

1. Найдите или создайте пул приложений, настроенный для использования требуемого режима.
   По умолчанию все новые пулы приложений выполняются в интегрированном режиме.
   ASP.NET настройка предоставляет пул приложений с именем "Classic .NET AppPool", который выполняется в классическом режиме интеграции ASP.NET. Этот пул приложений можно использовать для приложений, которые не должны выполняться в интегрированном режиме.
   Кроме того, можно изменить режим ASP.NET существующего пула приложений с помощью средства администрирования IIS или средства командной строки AppCmd.exe или вручную изменить конфигурацию пула приложений.
2. Задайте для приложения использование этого пула приложений.
   Каждое приложение настроено для использования определенного пула приложений. По умолчанию все приложения используют пул приложений по умолчанию с именем DefaultAppPool, который выполняется в интегрированном режиме.
   Пул приложений можно изменить с помощью средства администрирования IIS или средства командной строки AppCmd.exe или вручную изменить конфигурацию приложения.

Выбор версии ASP.NET для приложения

Исторически служба IIS поддерживает несколько версий ASP.NET / CLR параллельно. Например, СЛУЖБЫ IIS позволяют тому же серверу запускать ASP.NET приложения с помощью .NET Framework версии 1.1 и версии 2.0. Эта поддержка была предоставлена путем назначения соответствующей версии ASPNET_isapi.dll для обработки запросов к ASP.NET содержимому с помощью конфигурации скриптов IIS.

Например, можно использовать следующую конфигурацию карты скриптов для поддержки параллельной поддержки:

1. приложение ASP.NET версии 1.1 в /app1:
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
2. ASP.NET приложение версии 2.0 в /app2:
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll

Когда приложение получает запрос *.aspx, IIS загружает указанный aspnet_isapi.dll, который загружает правильную версию среды CLR в рабочий процесс и обрабатывает запрос.

ASP.NET также предоставляет следующие способы настройки параллельных карт сценариев:

1. ASP.NET расширение MMC. При выборе используемой версии ASP.NET расширение автоматически настраивает карты скриптов для приложения, чтобы указать правильную версию aspnet_isapi.dll.
2. ASP.NET aspnet_regiis.exe. Используйте параметры -i и -r, чтобы установить карты скриптов, указывающие на соответствующую версию ASP.NET.

К сожалению, из-за ограничения возможности загрузки только одной версии CLR в один рабочий процесс необходимо убедиться, что два приложения, использующие разные версии ASP.NET, никогда не конфигурируются в одном пуле приложений. При совершении этой распространенной ошибки первый запрос загружает CLR соответствующего aspnet_isapi.dll, а последующие запросы на другую версию в том же пуле приложений завершаются с ошибкой.

IIS распознает, что пул приложений — это версия ASP.NET, которую вы выбрали для запуска приложения. Таким образом, версия среды CLR /ASP.NET, загруженная в пул приложений, явно настраивается в конфигурации пула приложений. По умолчанию IIS предварительно загружает среду CLR, указанную этим параметром при загрузке рабочего процесса (если версия не настроена на пустую).

Так как пулы приложений являются границей управления версиями .NET Framework, можно изменить версию приложения ASP.NET, выполнив следующие действия.

1. Переместите приложение в пул приложений, использующий нужную версию ASP.NET.
   По умолчанию приложения используют пул приложений по умолчанию с именем DefaultAppPool, который выполняет ASP.NET версии 2.1 в интегрированном режиме. Переместите приложение в классический режим .NET AppPool, чтобы запуститься в классическом режиме ASP.NET версии 2.1 или в другом пуле приложений.
2. Настройте пул приложений, в котором выполняется приложение, для использования требуемой ASP.NET версии.
   По умолчанию все новые пулы приложений настроены для запуска ASP.NET версии 2.1 в интегрированном режиме.

IIS использует предварительно настроенные сопоставления обработчиков для автоматического выбора правильного набора сопоставлений обработчиков (для ASPNET_isapi.dll в классическом режиме или непосредственно для типов управляемых обработчиков в интегрированном режиме) в зависимости от настроенной версии CLR и управляемого режима интеграции пула приложений. Программа установки ASP.NET 2.0 устанавливает эти сопоставления обработчиков на уровне сервера.

Использование встроенного режима ASP.NET

В IIS приложения ASP.NET по умолчанию выполняются в интегрированном режиме. Тем не менее, чтобы воспользоваться преимуществами, предоставляемыми более жесткой интеграцией, необходимо внести некоторые изменения в конфигурацию приложения. Вы также можете разрабатывать новые ASP.NET компоненты, которые используют интегрированный режим, чтобы обеспечить мощные функциональные возможности приложения.

Включение служб ASP.NET для всех типов содержимого

В интегрированном режиме службы, предоставляемые модулями ASP.NET, доступны для запросов ко всем типам контента. Однако по умолчанию модули ASP.NET настроены только для запросов на ASP.NET содержимое для обратной совместимости.

Для этого подключите условие managedHandler к каждому модулю ASP.NET в разделе конфигурации на уровне сервера:

<modules> 
     <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" 
             preCondition="managedHandler" />
     <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" 
             preCondition="managedHandler" />
    ...
</modules>

Предварительным условием является правило, которое сервер вычисляет по каждому запросу, чтобы определить, будет ли выполнен модуль. Условие managedHandler является истинным только для запросов к типам контента, сопоставленным с обработчиками ASP.NET.

Чтобы применить функциональные возможности, предоставляемые модулем ASP.NET ко всем запросам, удалите запись модуля, а затем повторно добавьте ее без предварительных условий в корневом Web.config файле приложения.

Чтобы включить проверку подлинности ASP.NET Forms для всего приложения, измените файл Web.config следующим образом:

<modules> 
    <remove name="FormsAuthentication" /> 
    <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" /> 
    …
</modules>

При этом изменении модуль FormsAuthentication выполняется для всех запросов в приложении. Это позволяет защитить все данные приложения с помощью проверки подлинности с использованием форм. Дополнительные сведения о том, как использовать интегрированный режим для проверки подлинности форм для всего содержимого приложения, см. в пошаговом руководстве по использованию встроенного режима конвейера.

Вы также можете использовать ярлык для включения всех управляемых модулей (ASP.NET) для выполнения всех запросов в приложении независимо от предварительного условия managedHandler. Чтобы разрешить всем управляемым модулям выполняться для всех запросов без настройки каждой записи модуля для удаления предварительного условия managedHandler, используйте свойство runAllManagedModulesForAllRequests в <modules> разделе:

<modules runAllManagedModulesForAllRequests="true" />

Когда вы используете это, условие "managedHandler" не оказывает влияния, и все управляемые модули будут выполняться для всех запросов.

Экспериментируйте с включением других модулей ASP.NET для применения ко всему приложению. Например, используйте модуль кэша выходных данных ASP.NET для вывода страниц ASP или использования авторизации URL-адресов и диспетчера ролей для настройки правил управления доступом для фотографий. Или разработайте собственный модуль, чтобы использовать возможности ASP.NET на вашем веб-сайте.

Создание более мощных служб ASP.NET

В интегрированном режиме модули ASP.NET применяют свои службы ко всему содержимому. Кроме того, поскольку ASP.NET модули выполняются в едином конвейере обработки запросов в интегрированном режиме, они подписываются на те же этапы обработки запросов и выполняют те же задачи, что и модули собственного сервера. В то же время API ASP.NET в основном остаются одинаковыми, с несколькими ключевыми дополнениями, которые разблокируют ранее недоступные функции.

Точность среды выполнения

В интегрированном режиме ASP.NET этапы обработки запросов, предоставляемые модулям, напрямую подключены к соответствующим этапам конвейера IIS. Полный конвейер содержит следующие этапы, которые предоставляются как события HttpApplication в ASP.NET:

1. BeginRequest. Начинается обработка запроса.
2. АутентификацияЗапрос. Запрос проходит проверку подлинности. Модули аутентификации IIS и ASP.NET подключаются на данном этапе для выполнения проверки подлинности.
3. PostAuthenticateRequest.
4. ЗапросАвторизации. Запрос авторизован. Службы IIS и модули авторизации ASP.NET проверяют, имеет ли прошедший проверку подлинности пользователь доступ к запрошенным ресурсам.
5. PostAuthorizeRequest.
6. ResolveRequestCache. Модули кэша проверяют, существует ли ответ на этот запрос в кэше и возвращает его вместо того, чтобы продолжить остальные пути выполнения. Выполняются функции кэша вывода ASP.NET и кэша выходных данных IIS.
7. PostResolveRequestCache.
8. MapRequestHandler. Этот этап является внутренним в ASP.NET и используется для определения обработчика запросов.
9. PostMapRequestHandler.
10. AcquireRequestState. Извлекается состояние, необходимое для выполнения запроса. ASP.NET модули состояния сеанса и профиля получают свои данные.
11. PostAcquireRequestState.
12. PreExecuteRequestHandler. Все задачи выполняются перед выполнением обработчика.
13. ExecuteRequestHandler. Обработчик запроса выполняется. Обслуживаются страницы ASPX, страницы ASP, программы CGI и статические файлы.
14. PostExecuteRequestHandler
15. ReleaseRequestState. Изменения состояния запроса сохраняются, а состояние очищается здесь. ASP.NET модули состояния сеанса и профиля используют этот этап для очистки.
16. PostReleaseRequestState.
17. UpdateRequestCache. Ответ хранится в кэше для дальнейшего использования. Модули кэша вывода ASP.NET и кэш выходных данных IIS выполняются для сохранения ответа в свои кэши.
18. PostUpdateRequestCache.
19. LogRequest. На этом этапе регистрируется результаты запроса и гарантируется выполнение даже при возникновении ошибок.
20. PostLogRequest.
21. EndRequest. На этом этапе выполняется очистка окончательного запроса и гарантируется выполнение даже в случае возникновения ошибок.

Используя знакомые API-интерфейсы ASP.NET, возможность выполняться в тех же этапах, что и модули IIS, позволяет выполнять задачи, которые ранее были доступны только в нативных фильтрах и расширениях ISAPI, теперь в управляемом коде.

Например, теперь можно написать модули, которые выполняют следующие действия:

1. Перехватите запрос до того, как будет выполнена обработка, например перезапись URL-адресов или фильтрация безопасности.
2. Замените встроенные режимы проверки подлинности.
3. Измените содержимое входящего запроса, например заголовки запросов.
4. Фильтрация исходящих ответов для всех типов контента.

См. разработку модуля IIS 7 и выше с помощью .NET для хорошего примера того, как расширить возможности IIS с помощью пользовательского модуля аутентификации ASP.NET.

Расширенные API ASP.NET

API-интерфейсы ASP.NET остаются обратно совместимыми с предыдущими выпусками, что позволяет существующим модулям работать в IIS 7 и более поздних версиях без изменений и применять ко всему содержимому приложения без изменений кода.

Однако модули, написанные в режиме интеграции IIS, могут воспользоваться несколькими дополнительными API для включения сценариев обработки ключевых запросов, которые ранее недоступны.

Новая коллекция HttpResponse.Headers позволяет модулям проверять заголовки ответов и управлять ими, создаваемыми другими компонентами приложения. Например, можно изменить заголовок Content-Type, созданный страницей ASP, чтобы получить диалоговое окно скачивания в браузере. Коллекция файлов cookie в классе HttpResponse также расширена, чтобы разрешить изменение файлов cookie, созданных в рамках обработки запроса, даже если они были созданы вне ASP.NET.

Коллекция HttpRequest.Headers включена для записи, которая позволяет модулям управлять заголовками входящих запросов. Используйте это для изменения поведения других компонентов сервера, например, вы можете принудительно применить локализованное приложение для реагирования на клиент на другом языке, динамически изменив значение заголовка Accept-Language.

Наконец, коллекция HttpRequest.ServerVariables теперь доступна для записи, что позволяет задавать переменные сервера IIS. модули ASP.NET используют эту функцию для изменения значений, предоставляемых IIS, и для создания новых переменных сервера, видимых для других платформ приложений, таких как PHP.

Интеграция среды выполнения

Помимо новых API, интегрированный режим позволяет существующим ASP.NET функциональным возможностям обеспечить большее значение для приложения.

Средства трассировки, предоставляемые ASP.NET, включая класс System.Diagnostics.Trace и функцию трассировки страницы ASP.NET, теперь передают данные трассировки в систему трассировки IIS. Это позволяет размещать данные трассировки, создаваемые во время обработки запросов как службами IIS, так и компонентами ASP.NET, которые будут помещены в один файл журнала, упрощая более эффективную диагностику проблем с сервером.

Функция фильтрации ответов в ASP.NET, которая позволяет изменять ответы с помощью интерфейса потока (Stream) перед отправкой клиенту, была усовершенствована для разрешения фильтрации содержимого, не относящегося к ASP.NET. Поэтому можно использовать фильтрацию ASP.NET на всех серверах или выборочно установить фильтр только для запросов к содержимому, которое требуется обработать. С помощью этой возможности можно написать функции фильтрации, которые встраивают или цензурируют определенное содержимое в ответы сайта независимо от того, поступает ли это содержимое с страницы ASPX или из статического файла.

Сводка

Интеграция ASP.NET в IIS 7 и более поздних версиях раскрывает весь потенциал ASP.NET, позволяя разработчикам создавать мощные серверные компоненты с легкостью и богатством ASP.NET и .NET Framework. Дополнительные сведения о том, как использовать ASP.NET интегрированный режим для существующих приложений, см. в статье "Использование встроенного режима конвейера". Сведения о создании новых компонентов ASP.NET для расширения сервера см. в статье "Разработка модуля IIS 7 и выше" с помощью .NET.