В чем разница между этими двумя HttpContext.Current.Session и Session - asp.net 4.0

Они фактически одинаковы в том, что они будут обращаться к одним и тем же данным сеанса.

Причина, по которой вы можете вызвать Session в коде программной части, состоит в том, что страницы ASP.Net по умолчанию расширяют тип System.Web.UI.Page. Это Session общедоступное свойство. Если вы посмотрите на код этого в Reflector, вы увидите, что он просто вызывает HttpContext.Current.Session сам (через собственное свойство Context).

В других классах у вас не будет доступа к этому свойству, но вместо этого вы можете использовать HttpContext.Current.Session для доступа к данным сеанса, если вы работаете в контексте веб-приложения.

По стандартному сценарию они такие же. Разница в том, что первая инструкция также будет работать в статических контекстах, таких как WebMethod.

Есть разница. Второй (Session) является свойством многих объектов .NET, например, Page. Таким образом, вы не можете получить к нему доступ, например, в конструкторе этих объектов. Однако первый (HttpContext.Current.Session) всегда готов и находится в вашем распоряжении (конечно, после загрузки сеанса в конвейер обработки запросов).

Нет никакой разницы. Page.Session возвращает HttpContext.Current.Session

С учетом сказанного, я написал .dll, которые действуют как расширения для веб-приложений. Эти .dll не имеют понятия Session. В этих случаях я могу получить доступ к текущему сеансу веб-приложения, использующего мою .dll, указав HttpContext.Current.Session

Нет никакой разницы. Это одно и то же; вторая форма короче :)

Нет никакой разницы в поведении. Если вы используете код в своем настраиваемом классе, где HttpContext недоступен напрямую и хотите получить доступ к значению сеанса, мы используем первую строку кода, а вторая строка используется при доступе к классам Page или управляющим классам.

Еще один довольно подробный ответ от Николаса Кэри https://stackoverflow.com/a/6021261/365017

«Свойство Session HttpApplication демонстрирует другое поведение, чем свойство HttpContext.Current.Session. Оба они возвращают ссылку на один и тот же экземпляр HttpSessionState, если он доступен. Они различаются тем, что они делают, когда нет экземпляра HttpSessionState, доступного для текущий запрос.

Не все HttpHandler предоставляют состояние сеанса. Для этого HttpHandler должен реализовать [один или оба?] Интерфейсы маркеров IRequiresSessionState или IReadOnlySessionState.

HttpContext.Current.Session просто возвращает null, если сеанс недоступен.

Реализация свойства Session в HttpApplication генерирует исключение HttpException с сообщением. Состояние сеанса недоступно в этом контексте. вместо того, чтобы возвращать пустую ссылку ".

Внутри Page.Session указывает только на It's HttpContext.Current.Session, но все же есть два различия в зависимости от того, откуда он вызван.

Доступ к Page.Session можно получить только из классов, унаследованных от System.Web.UI.Page, и он будет вызывать HttpException при доступе из WebMethod.
Где HttpContext.Current.Session может быть доступен из любого места, пока вы работаете в контексте веб-приложения.


Другое важное отличие: вы можете получить доступ к Page.Session, но не можете получить доступ к HttpContext.Current.Session:

Если на вашей странице есть метод с именем GetData (унаследованный от System.Web .UI.Page), который выполняется одновременно в потоках, отличных от какого-либо другого метода страницы, метод GetData может получить доступ к Page.Seession, но вы не можете получить доступ к HttpContext.Current.Session.

Это потому, что GetData был вызван из другого потока, поэтому HttpContext.Current имеет значение null, а HttpContext.Current.Session вызовет исключение нулевой ссылки, но Page.Session все равно будет прикреплен к объекту страницы, поэтому метод страницы GetData может получить доступ Страница. Сессия.