Разработчики, начавшие использовать IIS 7.0, могут столкнуться с интересной проблемой, которая не была актуальна для систем, работающих на базе IIS 6.0. Суть проблемы заключается в том, что если для приложения разработан свой обработчик ошибок, обрабатывающий разные типы исключений и выполняющий редирект на разные страницы, то этот редирект будет проигнорирован и пользователь увидит стандартный "желтый экран" IIS.
Решение же проблемы оказалось куда банальнее, чем сама проблема :)
Исследования выявили интересное нововведение в классе HttpRequest, которое появилось в версиях .NET 3.5, 3.0 SP1 и 2.0 SP1 - свойство TrySkipIisCustomErrors. Оно указывает IIS7, игнорировать ли стандартный обработчик ошибок, разрешая пользовательскую обработку, или обрабатывать ошибки сугубо стандартными средствами. При этом, "ручное" выставление этого свойства ни к чему не приводит. По все видимости, это свойство играет сугубо сервисную роль и используется самой инфраструктурой ASP.NET. Да и завязка на наличие SP у .NET как-то не очень вселяет оптимизм.
Впрочем, все решилось достаточно изящно. В документации к этому свойству нашлось:
The TrySkipIisCustomErrors property is used only when your application is hosted in IIS 7.0. When running in Classic mode in IIS 7.0 the TrySkipIisCustomErrors property default value is true. When running in Integrated mode, the TrySkipIisCustomErrors property default value is false.
Дейтсвительно, стоило для приложения указать использование Classic Pool вместо Default Pool, и все заработало точно так же, как на старом добром IIS 6.0 :)
| Опубликовать | Tweet |
Сообщения
Комментариев нет:
Отправить комментарий