Немного поздно здесь, но вот кое-что, что я только что обнаружил.
@ Филипп Лейберт и @CSharpAtl неверны. Свойство HttpApplication
Session
демонстрирует поведение, отличное от свойства HttpContext.Current.Session
. Они оба вернут ссылку на один и тот же HttpSessionState
экземпляр , если один доступен. Они отличаются тем, что делают, когда для текущего запроса нет экземпляра HttpSessionState
.
Не все HttpHandler
предоставляют состояние сеанса. Для этого HttpHandler
должен реализовать [один или оба?] Интерфейса маркеров IRequiresSessionState
или IReadOnlySessionState
.
HttpContext.Current.Session
просто возвращает null
, если сеанс недоступен.
Реализация HttpApplication
свойства Session
выдает HttpException
с сообщением Session state is not available in this context.
, а не возвращает ссылку null
.
Некоторые примеры HttpHandler
, которые не реализуют сеанс, являются обработчиками по умолчанию для обычно статических ресурсов, таких как изображения и файлы CSS. Любая ссылка на свойство HttpApplication
Session
в таких случаях (как в global.asax
обработчиках событий) приведет к выбросу HttpException
.
Излишне говорить, что неожиданный HttpException
предоставляет WTF ?! момент, если вы этого не ожидаете.
Свойство Session
класса HttpApplication
реализовано следующим образом (из Reflector):
[Browsable(false), DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
public HttpSessionState Session
{
get
{
HttpSessionState session = null;
if (this._session != null)
{
session = this._session;
}
else if (this._context != null)
{
session = this._context.Session;
}
if (session == null)
{
throw new HttpException(SR.GetString("Session_not_available"));
}
return session;
}
}