Поделиться через

Интеграция 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, а затем перенаправляли этот запрос в библиотеку DLL ISAPI ASP.NET, в которой размещен конвейер запросов ASP.NET и платформу страниц. Запросы на non-ASP.NET содержимое, например ASP-страницы или статические файлы, обрабатывались службами IIS или другими расширениями ISAPI и не были видны ASP.NET.

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

Схема, на которую показаны конвейеры I I I S 6 и AS P dot NET.

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

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

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

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

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

Схема, показывающая интегрированный режим I I I S 7 и выше.

Рис. 2. Интегрированный режим IIS 7 и более поздних версий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

  1. Найдите или создайте пул приложений, настроенный для использования требуемого режима.
    По умолчанию все новые пулы приложений выполняются в интегрированном режиме.
    Настроенная ASP.NET предоставляет пул приложений с именем "Классический пул приложений .NET", который выполняется в классическом режиме интеграции 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.

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

  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 для запуска в ASP.NET классическом режиме версии 2.1 или в другом пуле приложений по своему выбору.
  2. Настройте пул приложений, в котором выполняется приложение, для использования требуемой версии ASP.NET.
    По умолчанию все новые пулы приложений настроены для запуска ASP.NET версии 2.1 в интегрированном режиме.

Примечание

Не используйте параметры aspnet_regiis /i или /r для настройки версии ASP.NET для конкретного приложения или глобально.

СЛУЖБЫ 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 модули выполняются в едином конвейере обработки запросов в режиме интеграции, они подписываются на одни и те же этапы обработки запросов и выполняют те же задачи, что и собственные серверные модули. В то же время ASP.NET API-интерфейсы остаются в основном неизменными, с несколькими ключевыми дополнениями, которые разблокировки ранее недоступных функций.

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

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

  1. BeginRequest. Начнется обработка запроса.
  2. AuthenticateRequest. Запрос проходит проверку подлинности. Службы IIS и модули проверки подлинности ASP.NET подписываются на этот этап для выполнения проверки подлинности.
  3. PostAuthenticateRequest.
  4. AuthorizeRequest. Запрос авторизован. Модули авторизации 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 с помощью пользовательского модуля проверки подлинности ASP.NET см. в статье Разработка модуля IIS 7 и более поздних версий с помощью .NET .

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

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

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

Новая коллекция HttpResponse.Headers позволяет модулям проверять заголовки ответов, создаваемые другими компонентами приложения, и управлять ими. Например, можно изменить заголовок Content-Type, созданный asp-страницей, чтобы в браузере было предложено скачать диалоговое окно. Коллекция Cookies в классе 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 перед их передачей клиенту, улучшена для фильтрации содержимого non-ASP.NET. Поэтому можно использовать ASP.NET фильтрации для всего содержимого сервера или выборочно устанавливать фильтр только для запросов к содержимому, которое требуется обработать. С помощью этой возможности можно создавать функции фильтрации, которые внедряют или цензуруют определенное содержимое в ответах сайта, независимо от того, поступает ли это содержимое из ASPX-страницы или статического файла.

Сводка

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