Блог

Главная - Вопросы по программированию - Получение «Запрос недоступен в этом контексте» при инициализации default.aspx

Получение «Запрос недоступен в этом контексте» при инициализации default.aspx

#c# #asp.net

Вопрос:

Короче говоря, я получаю исключение, упомянутое в названии, только на одном из 7 серверов, на которых развернута эта сборка. Это происходит при запуске веб-приложения путем запроса на главную страницу по умолчанию. Этот сервер, на котором он выходит из строя — назовем его F -, работает под управлением IIS 8.5. Остальные, которые работают, я не уверен во всех, но по крайней мере три из них работают на IIS 8.0.

Вот информация о том, когда это происходит.

 System.TypeInitializationException: The type initializer for 'Innova._8R00.cUrls' threw an exception. ---> System.Web.HttpException: Request is not available in this context
    at System.Web.HttpContext.get_Request()
    at Innova._8R00.cUrls..cctor()
    --- End of inner exception stack trace ---
    at RequestPortal.BasePage..ctor(String callerMember, String callerPath)
    at RequestPortal._Default..ctor()
    at ASP.default_aspx..ctor() in c:WindowsMicrosoft.NETFrameworkv4.0.30319Temporary ASP.NET Filesrequestportalfbdfb9ed97c3a4bApp_Web_rguuv5sc.2.cs:line 0
    at __ASP.FastObjectFactory_app_web_rguuv5sc.Create_ASP_default_aspx() in c:WindowsMicrosoft.NETFrameworkv4.0.30319Temporary ASP.NET Filesrequestportalfbdfb9ed97c3a4bApp_Web_rguuv5sc.3.cs:line 0
    at System.Web.Compilation.BuildResultCompiledType.CreateInstance()

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

 public struct cUrls
{
...
        public static string URL_PAGE = HttpContext.Current.Request.Url.AbsoluteUri;
        public static string PROTOCOL = HttpContext.Current.Request.Url.Scheme;
        public static string FQDN = HttpContext.Current.Request.Url.Host;
        public static string APP_PATH = HttpContext.Current.Request.ApplicationPath;
...
}

Я провел много исследований в Интернете, и я знаю, что это в основном связано с IIS 7 и попыткой использовать HttpContext из Application_Start. Как вы можете видеть, это не так. Существует код, который использует завиток.APP_PATH в Application_Start, но это, кажется, нормально, плюс это приводит к сбою в IIS 8.5, и помните, что это отлично работает на нескольких других машинах.

Я говорю, что это должно быть что-то связанное с окружающей средой, настройкой в machine.config или чем-то еще, что отличается на машине F. Есть какие-нибудь идеи?

Комментарии:

1. «Я говорю, что это должно быть что-то, связанное с окружающей средой, настройкой в machine.config или чем-то еще, что отличается на машине F. Есть какие-нибудь идеи?» Можете ли вы проверить конфигурацию режима управляемого конвейера в настройках пула приложений IIS8 для вашего приложения? У меня такое чувство, что вы можете обнаружить, что он установлен Integrated на сервере, где этот код не работает, и Classic на других. Если это так, то есть объяснение

2. К сожалению, я еще не мог просмотреть конфигурацию IIS в этой среде. Ожидается, что веб-приложение работает в интегрированном режиме во всех средах, и оно не должно было измениться. Если бы какой-либо из пулов приложений был установлен на Классический, приложение не работало бы (оно содержит код, который в этом случае вышел бы из строя). Как только я получу разрешение на доступ к этой среде (большая компания, доступ заблокирован), Я смогу сравнить конфигурации.

Ответ №1:

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

Длинный ответ: Ожидая одобрения доступа к конфигурации IIS, мы попробовали приложение еще раз, и, к нашему удивлению (или, может быть, ожидаемому), на этот раз оно сработало. Никаких исключений, просто плавное плавание. Тем временем мы получили доступ к серверу/среде F, где произошел сбой, чтобы иметь возможность проверить конфигурацию IIS и сравнить ее с рабочими средами, но теперь уже слишком поздно, мы, возможно, никогда не узнаем, что стало причиной этого. Мы, тем не менее, проверили, но конфигурация идентична.

Эти серверы (всего 7) Я говорил в оригинальном посте о локальных(1), DEV(1), QA(2), UAT(1) и PROD(2) средах, всего 7, и только одна была неудачной — UAT. Я не знаю, когда он снова начал работать, так как он не сильно используется, если только мы не находимся в фазе UAT.

В качестве вывода я знаю, что не имеет смысла не иметь объекта запроса, доступного в экземпляре HttpContext на этом этапе, в то время как в конструкторе ASP.Net страница, но это случилось. Код, как оказалось, был просто в порядке и не нуждался в разборе. Все это было связано с окружающей средой (это корпоративная среда, и обновления и изменения иногда происходят на этих серверах без нашего ведома). Я просто надеялся, что кто-то еще проходил через это раньше и распознает закономерность.

Метки: