回答:
（完全性のために更新）
セッション変数には、任意のページまたはコントロールを使用Session["loginId"]して、任意のクラスから（たとえば、クラスライブラリ内から）、以下を使用してアクセスできます。System.Web.HttpContext.Current.Session["loginId"].
しかし、私の元の答えを読んでください...
私は常にASP.NETセッションのラッパークラスを使用して、セッション変数へのアクセスを簡略化しています。
public class MySession
{
// private constructor
private MySession()
{
Property1 = "default value";
}
// Gets the current session.
public static MySession Current
{
get
{
MySession session =
(MySession)HttpContext.Current.Session["__MySession__"];
if (session == null)
{
session = new MySession();
HttpContext.Current.Session["__MySession__"] = session;
}
return session;
}
}
// **** add your session properties here, e.g like this:
public string Property1 { get; set; }
public DateTime MyDate { get; set; }
public int LoginId { get; set; }
}
このクラスは、ASP.NETセッションに自身の1つのインスタンスを格納し、次のように、任意のクラスからタイプセーフな方法でセッションプロパティにアクセスできるようにします。
int loginId = MySession.Current.LoginId;
string property1 = MySession.Current.Property1;
MySession.Current.Property1 = newValue;
DateTime myDate = MySession.Current.MyDate;
MySession.Current.MyDate = DateTime.Now;
このアプローチにはいくつかの利点があります。
スレッドHttpContextを介してセッションにアクセスします：
HttpContext.Current.Session["loginId"]提案されたソリューションの問題は、アウトプロセスセッションストレージを使用している場合、SessionStateに組み込まれている一部のパフォーマンス機能を破壊する可能性があることです。（「状態サーバーモード」または「SQLサーバーモード」）。oopモードでは、セッションデータをページリクエストの最後にシリアル化し、ページリクエストの最初にデシリアライズする必要があるため、コストがかかる可能性があります。パフォーマンスを向上させるために、SessionStateは、最初にアクセスされたときに変数だけをデシリアライズすることで必要なものだけをデシリアライズしようとし、変更された変数のみを再シリアライズして置き換えます。多くのセッション変数があり、それらをすべて1つのクラスに移動する場合、基本的に、セッションを使用するすべてのページリクエストでセッション内のすべてがデシリアライズされ、クラスが変更されたために1つのプロパティのみが変更された場合でも、すべてを再度シリアル化する必要があります。たくさんのセッションとoopモードを使用している場合に考慮すべきことです。
私の前に提示された答えは問題に対する適切な解決策を提供しますが、このエラーが発生する理由を理解することが重要であると私は感じています：
のSessionプロパティは、その特定のリクエストに関連するPageタイプのインスタンスを返しますHttpSessionState。Page.Session実際にはを呼び出すことと同じPage.Context.Sessionです。
MSDNはこれがどのように可能であるかを説明しています：
ASP.NETページにはSystem.Web名前空間（
HttpContextクラスを含む）へのデフォルトの参照が含まれているためHttpContext、への完全修飾クラス参照なしで.aspxページののメンバーを参照できますHttpContext。
ただし、App_Codeのクラス内でこのプロパティにアクセスしようとすると、クラスがページクラスから派生していない限り、プロパティを使用できません。
このよく遭遇するシナリオに対する私の解決策は、ページオブジェクトをクラスに渡さないことです。必要に応じて、Sessionページから必要なオブジェクトを抽出し、名前と値のコレクション/配列/リストの形式でクラスに渡します。
asp.netコアでは、これは動作が異なります。
public class SomeOtherClass
{
private readonly IHttpContextAccessor _httpContextAccessor;
private ISession _session => _httpContextAccessor.HttpContext.Session;
public SomeOtherClass(IHttpContextAccessor httpContextAccessor)
{
_httpContextAccessor = httpContextAccessor;
}
public void TestSet()
{
_session.SetString("Test", "Ben Rules!");
}
public void TestGet()
{
var message = _session.GetString("Test");
}
}ソース：https : //benjii.me/2016/07/using-sessions-and-httpcontext-in-aspnetcore-and-mvc-core/
これは、アプリケーションと開発者の両方にとってより効率的であるはずです。
次のクラスをWebプロジェクトに追加します。
/// <summary>
/// This holds all of the session variables for the site.
/// </summary>
public class SessionCentralized
{
protected internal static void Save<T>(string sessionName, T value)
{
HttpContext.Current.Session[sessionName] = value;
}
protected internal static T Get<T>(string sessionName)
{
return (T)HttpContext.Current.Session[sessionName];
}
public static int? WhatEverSessionVariableYouWantToHold
{
get
{
return Get<int?>(nameof(WhatEverSessionVariableYouWantToHold));
}
set
{
Save(nameof(WhatEverSessionVariableYouWantToHold), value);
}
}
}ここに実装があります：
SessionCentralized.WhatEverSessionVariableYouWantToHold = id;