元の投稿から、HttpContext
が実際に欠落しているものであるかどうかは明らかではありません。HttpContext.User
プロパティは、ライフサイクルの特定の段階でnullになる可能性もあります。これにより、まったく同じ例外が発生します。他のすべての問題はさておき、ソースをステップスルーして、式のどの部分が実際にあるかを確認する必要がありますnull
。
のような静的メソッド/プロパティを参照するコードをHttpContext.Current
作成する場合、メソッド/プロパティが実際に使用可能になったときにコードが実行されることが保証されていないことを認識して、コードを作成する必要があります。通常、次のようなものがあります。
static string GetCurrentUserName()
{
HttpContext context = HttpContext.Current;
if (context == null)
return null;
IPrincipal user = context.User;
if (user == null)
return null;
return user.Identity.Name;
}
これでは実際には問題が解決しないと思いますが、例外を取り除くだけです。Application_BeginRequest
この問題は、バックグラウンドスレッド、静的コンストラクター、フィールド初期化子、メソッド、または同様の場所など、コンテキストが単に利用できない時間または場所でこのメソッドを呼び出している可能性が高くなります。
静的メソッドを、インスタンスに依存するクラスのインスタンスメソッドに変更することから始めるかもしれませんHttpContext
(つまり、コンストラクターで取得されます)。のようなメソッドは単純な「ユーティリティ」メソッドであると思い込むのは簡単ですが、実際にはそうではありません。また、静的プロパティを介して参照するメソッドを、まだ持っていない場所からGetCurrentUserName
呼び出すことは一般的に無効です。同じものへHttpContext.Current
のインスタンス参照HttpContext
(つまり、Page
クラスから)。次のようにクラスを書き直し始めると、オッズは次のようになります。
public class UserResolver
{
private HttpContext context;
public UserResolver(HttpContext context)
{
if (context == null)
throw new ArgumentNullException("context");
this.context = context;
}
public string GetUserName()
{
return (context.User != null) ? context.User.Identity.Name : null;
}
}
...そうすると、チェーンがどこで壊れているかがすぐにわかります。HttpContext.Current
これは、他の場所からは取得できないため、参照する必要があるポイントになります。
この特定のケースでは、明らかに、のスタックトレースを取得しNullReferenceException
てチェーンが開始する場所/タイミングを見つけるだけで問題を解決できるため、上記で説明した変更を行う必要はありません-私は単純です将来、この種の「シングルトンの欠落」エラーを減らすのに役立つ一般的なアプローチを推奨します。