La demande n'est pas disponible dans ce contexte

J'exécute le mode intégré IIS 7 et j'obtiens

La demande n'est pas disponible dans ce contexte

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

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

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

Que puis-je vérifier d'autre que de vérifier HttpContext.Current.Request pour null ??

Une question similaire est postée @ La demande n'est pas disponible dans cette exception de contexte lors de l'exécution de mvc sur iis7.5

mais pas de réponse pertinente non plus.

Veuillez consulter IIS7 Integrated mode: Request is not available in this context exception in Application_Start :

L'exception «La demande n'est pas disponible dans ce contexte» est l'une des erreurs les plus courantes que vous pouvez recevoir lors du déplacement des applications ASP.NET en mode intégré sur IIS 7.0. Cette exception se produit dans votre implémentation de la méthode Application_Start dans le fichier global.asax si vous essayez d'accéder au HttpContext de la demande qui a démarré l'application.

Lorsque vous avez une logique de journalisation personnalisée, il est plutôt ennuyeux d'être forcé de ne pas journaliser application_start ou de laisser une exception se produire dans le journal (même si elle est gérée).

Il semble qu'au lieu de tester la Requestdisponibilité, vous pouvez tester la Handlerdisponibilité: quand il n'y en a pas Request, il serait étrange d'avoir encore un gestionnaire de requêtes. Et tester pour Handlerne soulève pas cette Request is not available in this contextexception redoutée .

Vous pouvez donc changer votre code en:

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

Attention, dans le contexte d'un module http, Handlerpeuvent ne pas être définis Requestet Responsesont définis (j'ai vu cela dans l'événement BeginRequest). Donc, si vous avez besoin d'une journalisation des demandes / réponses dans un module http personnalisé, ma réponse peut ne pas convenir.

C'est un cas très classique: si vous finissez par avoir à vérifier les données fournies par l'instance http, envisagez de déplacer ce code sous l' BeginRequestévénement.

void Application_BeginRequest(Object source, EventArgs e)

Ceci est le bon endroit pour vérifier http têtes, chaîne de requête et etc ... Application_Startest pour les paramètres applicables pour l'ensemble des applications temps d'exécution, tels que le routage, les filtres, l' exploitation forestière et ainsi de suite.

Veuillez ne pas appliquer de solutions de contournement telles que le .ctor statique ou le passage au mode classique à moins qu'il n'y ait aucun moyen de déplacer le code du Startvers BeginRequest. cela devrait être faisable pour la grande majorité de vos cas.

Puisqu'il n'y a plus de contexte de demande dans le pipeline lors du démarrage de l'application, je ne peux plus imaginer qu'il y ait un moyen de deviner sur quel serveur / port la prochaine demande réelle pourrait arriver. Vous devez le faire sur Begin_Session.

Voici ce que j'utilise lorsque je ne suis 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);
}

Sur la base des besoins détaillés du PO expliqués dans les commentaires , une solution plus appropriée existe. L'OP déclare qu'il souhaite ajouter des données personnalisées dans ses logs avec log4net, données liées aux demandes.

Plutôt que d'encapsuler chaque appel log4net dans un appel de journal centralisé personnalisé qui gère la récupération des données liées aux requêtes (à chaque appel de journal), log4net propose des dictionnaires de contexte pour configurer des données supplémentaires personnalisées à journaliser. L'utilisation de ces dictionnaires permet de positionner vos données de journal de requêtes pour la requête en cours à l'événement BeginRequest, puis de les rejeter à l'événement EndRequest. Toute connexion entre les deux bénéficiera de ces données personnalisées.

Et les choses qui ne se produisent pas dans un contexte de demande n'essaieront pas de consigner les données liées à la demande, éliminant ainsi le besoin de tester la disponibilité de la demande. Cette solution correspond au principe proposé par Arman McHitaryan dans sa réponse .

Pour que cette solution fonctionne, vous aurez également besoin d'une configuration supplémentaire sur vos appenders log4net afin qu'ils puissent enregistrer vos données personnalisées.

Cette solution peut être facilement implémentée en tant que module d'amélioration de journal personnalisé. Voici un exemple de code pour cela:

using System;
using System.Web;
using log4net;
using log4net.Core;

namespace YourNameSpace
{
    public class LogHttpModule : IHttpModule
    {
        public void Dispose()
        {
            // nothing to free
        }

        private const string _ipKey = "IP";
        private const string _urlKey = "URL";
        private const string _refererKey = "Referer";
        private const string _userAgentKey = "UserAgent";
        private const string _userNameKey = "userName";

        public void Init(HttpApplication context)
        {
            context.BeginRequest += WebAppli_BeginRequest;
            context.PostAuthenticateRequest += WebAppli_PostAuthenticateRequest;
            // All custom properties must be initialized, otherwise log4net will not get
            // them from HttpContext.
            InitValueProviders(_ipKey, _urlKey, _refererKey, _userAgentKey,
                _userNameKey);
        }

        private void InitValueProviders(params string[] valueKeys)
        {
            if (valueKeys == null)
                return;
            foreach(var key in valueKeys)
            {
                GlobalContext.Properties[key] = new HttpContextValueProvider(key);
            }
        }

        private void WebAppli_BeginRequest(object sender, EventArgs e)
        {
            var currContext = HttpContext.Current;
            currContext.Items[_ipKey] = currContext.Request.UserHostAddress;
            currContext.Items[_urlKey] = currContext.Request.Url.AbsoluteUri;
            currContext.Items[_refererKey] = currContext.Request.UrlReferrer != null ? 
                currContext.Request.UrlReferrer.AbsoluteUri : null;
            currContext.Items[_userAgentKey] = currContext.Request.UserAgent;
        }

        private void WebAppli_PostAuthenticateRequest(object sender, EventArgs e)
        {
            var currContext = HttpContext.Current;
            // log4net doc states that %identity is "extremely slow":
            // http://logging.apache.org/log4net/release/sdk/log4net.Layout.PatternLayout.html
            // So here is some custom retrieval logic for it, so bad, especialy since I
            // tend to think this is a missed copy/paste in that documentation.
            // Indeed, we can find by inspection in default properties fetch by log4net a
            // log4net:Identity property with the data, but it looks undocumented...
            currContext.Items[_userNameKey] = currContext.User.Identity.Name;
        }
    }

    // General idea coming from 
    // http://piers7.blogspot.fr/2005/12/log4net-context-problems-with-aspnet.html
    // We can not use log4net ThreadContext or LogicalThreadContext with asp.net, since
    // asp.net may switch thread while serving a request, and reset the call context
    // in the process.
    public class HttpContextValueProvider : IFixingRequired
    {
        private string _contextKey;
        public HttpContextValueProvider(string contextKey)
        {
            _contextKey = contextKey;
        }

        public override string ToString()
        {
            var currContext = HttpContext.Current;
            if (currContext == null)
                return null;
            var value = currContext.Items[_contextKey];
            if (value == null)
                return null;
            return value.ToString();
        }

        object IFixingRequired.GetFixedObject()
        {
            return ToString();
        }
    }
}

Ajoutez-le à votre site, exemple de configuration IIS 7+:

<system.webServer>
  <!-- other stuff removed ... -->
  <modules>
    <!-- other stuff removed ... -->
    <add name="LogEnhancer" type="YourNameSpace.LogHttpModule, YourAssemblyName" preCondition="managedHandler" />
    <!-- other stuff removed ... -->
  </modules>
  <!-- other stuff removed ... -->
</system.webServer>

Et configurez les appenders pour consigner ces propriétés supplémentaires, exemple de configuration:

<log4net>
  <appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">
    <!-- other stuff removed ... -->
    <layout type="log4net.Layout.PatternLayout">
      <conversionPattern value="%date [%thread] %-5level %logger - %message - %property%newline%exception" />
    </layout>
  </appender>
  <appender name="SqlAppender" type="log4net.Appender.AdoNetAppender">
    <!-- other stuff removed ... -->
    <commandText value="INSERT INTO YourLogTable ([Date],[Thread],[Level],[Logger],[UserName],[Message],[Exception],[Ip],[Url],[Referer],[UserAgent]) VALUES (@log_date, @thread, @log_level, @logger, @userName, @message, @exception, @Ip, @Url, @Referer, @UserAgent)" />
    <!-- other parameters removed ... -->
    <parameter>
      <parameterName value="@userName" />
      <dbType value="String" />
      <size value="255" />
      <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%property{userName}" />
      </layout>
    </parameter>
    <parameter>
      <parameterName value="@Ip"/>
      <dbType value="String" />
      <size value="255" />
      <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%property{Ip}" />
      </layout>
    </parameter>
    <parameter>
      <parameterName value="@Url"/>
      <dbType value="String" />
      <size value="255" />
      <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%property{Url}" />
      </layout>
    </parameter>
    <parameter>
      <parameterName value="@Referer"/>
      <dbType value="String" />
      <size value="255" />
      <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%property{Referer}" />
      </layout>
    </parameter>
    <parameter>
      <parameterName value="@UserAgent"/>
      <dbType value="String" />
      <size value="255" />
      <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%property{UserAgent}" />
      </layout>
    </parameter>
  </appender>
  <!-- other stuff removed ... -->
</log4net>

Vous pouvez contourner le problème sans 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 requête dans son HTTPContext, vous permettant de le stocker et de le réutiliser immédiatement dans l'événement Application_Start

J'ai pu contourner / pirater ce problème en passant en mode "Classique" à partir du mode "intégré".

Cela a fonctionné pour moi - si vous devez vous connecter à Application_Start, faites-le avant de modifier le contexte. Vous obtiendrez une entrée de journal, juste sans source, comme:

2019-03-12 09: 35: 43,659 INFO (null) - Application démarrée

Je consigne généralement à la fois Application_Start et Session_Start, donc je vois plus de détails dans le message suivant

2019-03-12 09: 35: 45,064 INFO ~ / Leads / Leads.aspx - Session démarrée (Local)

        protected void Application_Start(object sender, EventArgs e)
        {
            log4net.Config.XmlConfigurator.Configure();
            log.Info("Application Started");
            GlobalContext.Properties["page"] = new GetCurrentPage();
        }

        protected void Session_Start(object sender, EventArgs e)
        {
            Globals._Environment = WebAppConfig.getEnvironment(Request.Url.AbsoluteUri, Properties.Settings.Default.LocalOverride);
            log.Info(string.Format("Session Started ({0})", Globals._Environment));
        }

Dans Visual Studio 2012, lorsque j'ai publié la solution par erreur avec l'option «debug», j'ai obtenu cette exception. Avec l'option «release», cela ne s'est jamais produit. J'espère que ça aide.

Vous pouvez utiliser les éléments suivants:

    protected void Application_Start(object sender, EventArgs e)
    {
        ThreadPool.QueueUserWorkItem(new WaitCallback(StartMySystem));
    }

    private void StartMySystem(object state)
    {
        Log(HttpContext.Current.Request.ToString());
    }

faites ceci dans global.asax.cs:

protected void Application_Start()
{
  //string ServerSoftware = Context.Request.ServerVariables["SERVER_SOFTWARE"];
  string server = Context.Request.ServerVariables["SERVER_NAME"];
  string port = Context.Request.ServerVariables["SERVER_PORT"];
  HttpRuntime.Cache.Insert("basePath", "http://" + server + ":" + port + "/");
  // ...
}

fonctionne comme un charme. this.Context.Request est là ...

this.Request lève une exception intentionnellement basée sur un indicateur