La semplice risposta è no, non è possibile. Si noti inoltre che HttpContext non eredita da HttpContextBase, ma entrambi implementano IServiceProvider. Infine, HttpContext è sigillato, suggerendo che gli autori non volevano che le persone facessero altro che consumare questa classe.
Come senza dubbio infastidito da HttpContextBase ha un costruttore senza parametri quindi non ti dà nemmeno la possibilità di istanziarlo dalla richiesta e risposta come HttpContext!
Usiamo un 'decompiler' di dare uno sguardo alla realizzazione di HttpContext.Current:
// System.Web.HttpContext
/// <summary>Gets or sets the <see cref="T:System.Web.HttpContext" /> object for the current HTTP request.</summary>
/// <returns>The <see cref="T:System.Web.HttpContext" /> for the current HTTP request.</returns>
public static HttpContext Current
{
get
{
return ContextBase.Current as HttpContext;
}
set
{
ContextBase.Current = value;
}
}
Se diamo uno sguardo al ContextBase.Current (da System.Web.Hosting.ContextBase):
// System.Web.Hosting.ContextBase
internal static object Current
{
get
{
return CallContext.HostContext;
}
[SecurityPermission(SecurityAction.Demand, Unrestricted = true)]
set
{
CallContext.HostContext = value;
}
}
e CallContext (in System.Runtime.Messaging):
// System.Runtime.Remoting.Messaging.CallContext
/// <summary>Gets or sets the host context associated with the current thread.</summary>
/// <returns>The host context associated with the current thread.</returns>
/// <exception cref="T:System.Security.SecurityException">The immediate caller does not have infrastructure permission. </exception>
public static object HostContext
{
[SecurityCritical]
get
{
IllogicalCallContext illogicalCallContext = Thread.CurrentThread.GetIllogicalCallContext();
object hostContext = illogicalCallContext.HostContext;
if (hostContext == null)
{
LogicalCallContext logicalCallContext = CallContext.GetLogicalCallContext();
hostContext = logicalCallContext.HostContext;
}
return hostContext;
}
[SecurityCritical]
set
{
if (value is ILogicalThreadAffinative)
{
IllogicalCallContext illogicalCallContext = Thread.CurrentThread.GetIllogicalCallContext();
illogicalCallContext.HostContext = null;
LogicalCallContext logicalCallContext = CallContext.GetLogicalCallContext();
logicalCallContext.HostContext = value;
return;
}
LogicalCallContext logicalCallContext2 = CallContext.GetLogicalCallContext();
logicalCallContext2.HostContext = null;
IllogicalCallContext illogicalCallContext2 = Thread.CurrentThread.GetIllogicalCallContext();
illogicalCallContext2.HostContext = value;
}
}
iniziamo per avere un'idea di come viene recuperato HttpContext. Viene inserito nel thread con cui l'utente corrente ha iniziato quando ha visitato il sito Web (il che ha perfettamente senso!). Addentrandoci ulteriormente possiamo vederli anche ricreati per richiesta (vedi sotto).
Possiamo anche vedere, a livello di interfaccia, HttpContext.Current non può essere modificato per puntare al proprio HttpContext come la proprietà non è virtuale. Utilizza inoltre molte classi BCL private o interne, quindi non è possibile copiare semplicemente la maggior parte dell'implementazione.
Ciò che sarebbe più semplice e anche meno incline a qualsiasi altro problema sarebbe semplicemente racchiudere HttpContext con il proprio oggetto CustomContext. Si può semplicemente racchiudere HttpContext.Current in una proprietà BaseContext, quindi avere le proprie proprietà sulla classe (e utilizzare qualsiasi meccanismo di archiviazione di stato basato su sessione, database o richiesta in cui si desidera archiviare e recuperare le proprie proprietà).
Personalmente, userei la mia classe per archiviare le mie informazioni personali, dato che appartiene alla mia applicazione e utente, ecc. E non ha nulla a che fare con la pipeline http o l'elaborazione richiesta/risposta.
Consulta anche: