La demande n'est pas disponible dans ce contexte

Question

Je suis exécutant IIS 7 mode Intégré et je suis de

La demande n'est pas disponible dans ce contexte

lorsque j'essaie d'accéder à un Log4Net liées à la fonction qui est appelée à partir d' Application_Start. C'est la ligne de code que j'ai

if (HttpContext.Current != null && HttpContext.Current.Request != null)

et une exception est levée pour la deuxième comparaison.

Quoi d'autre puis-je vérifier d'autres que la vérification de HttpContext.Actuel.La demande pour les nuls??

---

Une question similaire est posté @ http://stackoverflow.com/questions/2056398/request-is-not-available-in-this-context-exception-when-runnig-mvc-on-iis7-5

mais pas de réponse pertinente.

Answer 1

Veuillez voir IIS7 mode Intégré: Demande n'est pas disponible dans ce contexte exception dans Application_Start:

"La Demande n'est pas disponible en ce contexte de" l'exception " est l'un des plus les erreurs courantes que vous pouvez recevoir lorsque le déplacement ASP.NET les applications de Le mode intégré sur IIS 7.0. Cette exception qui se passe dans votre la mise en œuvre de la Méthode Application_Start dans le mondiale.asax fichier si vous essayez de accéder à la HttpContext de la demande qui a commencé l'application.

Answer 2

Lorsque vous avez personnalisé la journalisation de la logique, c'est plutôt gênant d'être forcé de ne pas se connecter application_start ou à laisser une exception se produit dans l'enregistreur (même si elle est traitée).

Il semble que plutôt que de tester pour Request de la disponibilité, vous pouvez tester pour Handler disponibilité: quand il n'y a pas d' Request, il serait étrange d'avoir encore un gestionnaire de requêtes. Et de tests pour Handler ne soulève pas que redouté Request is not available in this context d'exception.

De sorte que vous pouvez changer votre code:

var currContext = HttpContext.Current;
if (currContext != null && currContext.Handler != null)

Attention, dans le cadre d'un module http, Handler ne peut pas être définie si Request et Response (j'ai vu que dans BeginRequest de l'événement). Donc, si vous avez besoin de demande/réponse de l'ouverture d'un module http personnalisé, ma réponse peut ne pas être approprié.

Answer 3

C'est très classique: en effet, Si vous finissez par avoir à vérifier les données fournies par le http instance, puis envisager le déplacement de ce code, en vertu de l' BeginRequest événement.

void Application_BeginRequest(Object source, EventArgs e)

C'est le bon endroit pour vérifier les en-têtes http, chaîne de requête et etc... Application_Start est pour les paramètres qui s'appliquent pour l'application entière moment de l'exécution, telles que le routage, les filtres, l'enregistrement et ainsi de suite.

S'il vous plaît, ne pas appliquer les solutions de contournement comme statique .ctor ou de basculer sur le mode Classique moins qu'il n'y a pas moyen de déplacer le code de l' Start de BeginRequest. qui devrait être faisable pour la grande majorité des cas.

Answer 4

C'est un double post de cette entrée

Car il n'y a pas de contexte de Demande dans le pipeline durant l'application démarre plus, je ne peux pas imaginer il n'y a aucun moyen de deviner quel serveur/port de la prochaine demande réelle peut venir dans sur. Vous devez donc sur Begin_Session.

Voici ce que je suis en utilisant lorsqu'il n'est pas en Mode Classique. La surcharge est négligeable.

/// <summary>
/// Class is called only on the first request
/// </summary>
private class AppStart
{
    static bool _init = false;
    private static Object _lock = new Object();

    /// <summary>
    /// Does nothing after first request
    /// </summary>
    /// <param name="context"></param>
    public static void Start(HttpContext context)
    {
        if (_init)
        {
            return;
        }
        //create class level lock in case multiple sessions start simultaneously
        lock (_lock)
        {
            if (!_init)
            {
                string server = context.Request.ServerVariables["SERVER_NAME"];
                string port = context.Request.ServerVariables["SERVER_PORT"];
                HttpRuntime.Cache.Insert("basePath", "http://" + server + ":" + port + "/");
                _init = true;
            }
        }
    }
}

protected void Session_Start(object sender, EventArgs e)
{
    //initializes Cache on first request
    AppStart.Start(HttpContext.Current);
}

Answer 5

Vous pouvez contourner le problème sans avoir à passer en mode classique et toujours utiliser Application_Start

public class Global : HttpApplication
{
   private static HttpRequest initialRequest;

   static Global()
   {
      initialRequest = HttpContext.Current.Request;       
   }

   void Application_Start(object sender, EventArgs e)
   {
      //access the initial request here
   }

Pour une raison quelconque, le type statique est créé avec une demande en son HTTPContext, vous permettant de stocker et de la réutiliser immédiatement dans l'événement Application_Start