Sporadic «Method» Get_Session »en type à partir de l'assemblage n'a pas d'implémentation»

Question

Soudain, l'application Web que je développe a commencé à donner ce message d'erreur - à l'utilisateur, mais pas à moi, et seulement parfois.

Je sais que cette erreur peut être causée par des versions de référence d'assemblage et d'implémentation des versions de référence. Mais je n'ai pas mis à jour la version de Sharp pendant longtemps (en utilisant toujours un très ancien pour ce projet). De plus, l'erreur ne se produit pas toujours, si c'était de mauvais assemblages, je suppose que cela échouerait toujours.

Quelle peut être la raison? Y a-t-il des outils de traçage / loggin dans Framework pour le savoir?

Method 'get_Session' in type 'Orders.Data.SafeSessionStorage' 
from assembly 'Orders.Data, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' 
does not have an implementation." 

System.TypeLoadException: Method 'get_Session' in type 'Orders.Data.SafeSessionStorage' from assembly 'Orders.Data, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
   at Orders.Web.MvcApplication.InitializeNHibernateSession()
   at Orders.Web.MvcApplication.<Application_BeginRequest>b__1d()
   at SharpArch.Data.NHibernate.NHibernateInitializer.InitializeNHibernateOnce(Action initMethod)
   at Orders.Web.MvcApplication.Application_BeginRequest(Object sender, EventArgs e)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Voici le SAFESESSESTSTORAGE. Il s'agit d'une version légèrement modifiée de l'une de Sharparch, pour prendre en charge l'exécution dans les threads d'arrière-plan.

public class SafeSessionStorage : ISessionStorage
{
  [ThreadStatic]
  private static ISession _session;

  public ISession Session
  {
     get
     {
        HttpContext context = HttpContext.Current;
        if (context == null)
           return _session;
        else
        {
           ISession session = context.Items[factoryKey] as ISession;
           return session;
        }
     }
     set
     {
        HttpContext context = HttpContext.Current;
        if (context == null)
           _session = value;
        else
           context.Items[factoryKey] = value;
     }
  }

  public string FactoryKey
  {
     get { return factoryKey; }
  }

  public static void End()
  {
     if (_session != null)
        _session.Close();
     _session = null;
  }

  public void EndRequest()
  {
     ISession session = Session;

     if (session != null)
     {
        session.Close();
        HttpContext context = HttpContext.Current;
        if (context != null)
           context.Items.Remove(factoryKey);
        else
           _session = null;
     }
  }

  private string factoryKey = NHibernateSession.DefaultFactoryKey;
}

Voici où se produit l'erreur:

  private void InitializeNHibernateSession()
  {
     NHibernateInitHelper.InitSession(safeSessionStorage,
        Server.MapPath("~/NHibernate.config"),
        Server.MapPath("~/bin/Orders.Data.dll"));
  }

Ici, INITSESSIE s'attend à ce que lestorage soit adopté, donc je suppose que c'est là que la vérification du type échoue. Et je soupçonne les versions des assemblages mais, comme je l'ai dit, cela fonctionne toujours pour moi et fonctionne parfois pour l'utilisateur.

Answer 1

Je ferais mieux d'accepter le commentaire de Sehe comme réponse, mais de toute façon. Le problème était un stackOverflowException en raison des données de DB récursives. Pour déboguer, j'ai dû ajouter la journalisation à de nombreuses lignes à l'intérieur du code suspect (l'erreur s'est produite sur SOAP Service Access and Mapping Data à l'aide de DB), puis analyser. Une autre approche consistait à déploier de la construction de débogage (il s'agit du serveur de développement) et d'utiliser WindBG, qui a donné le code d'exception correct 0xe053534f afin que je puisse me concentrer sur le code qui peut entraîner cela (méthode Linq récursive pour collecter des produits associés).

L'espace à faible conduite était un effet secondaire de dw20.exe (dr. Watson) mangeant 1,5 Go d'espace (et CPU).

La visionneuse d'événements a été un peu d'aide car elle montrait l'erreur "Kernel32.dll, adresse 0x0000BEE7" trop générique pourrait Soyez un débordement de pile et pourrait être autre chose.

Obtenir "la méthode n'a pas de mise en œuvre" est la dernière information que j'attend de ces conditions.