Il y a maintenant un ELMAH.MVC package NuGet qui inclut une amélioration de la solution par Atif et également un contrôleur qui gère le elmah interface MVC de routage (pas besoin d'utiliser cette axd plus)
Le problème avec cette solution (et avec tous ceux ici) est que, d'une façon ou d'une autre la elmah gestionnaire d'erreur est en fait de la manipulation de l'erreur, en ignorant ce que vous voulez définir en tant que customError tag ou par l'intermédiaire de ErrorHandler ou de votre propre gestionnaire d'erreur
La meilleure solution à mon humble avis est de créer un filtre de loi à la fin de tous les autres filtres et de consigner les événements qui ont été déjà traitées. Le elmah module doit prendre soin de loging les autres erreurs non gérées par l'application. Cela vous permettra également d'utiliser le moniteur de la santé et tous les autres modules qui peuvent être ajoutés à asp.net à regarder les événements d'erreur
J'ai écrit cette recherche avec réflecteur à la ErrorHandler à l'intérieur de elmah.mvc
public class ElmahMVCErrorFilter : IExceptionFilter
{
private static ErrorFilterConfiguration _config;
public void OnException(ExceptionContext context)
{
if (context.ExceptionHandled) //The unhandled ones will be picked by the elmah module
{
var e = context.Exception;
var context2 = context.HttpContext.ApplicationInstance.Context;
//TODO: Add additional variables to context.HttpContext.Request.ServerVariables for both handled and unhandled exceptions
if ((context2 == null) || (!_RaiseErrorSignal(e, context2) && !_IsFiltered(e, context2)))
{
_LogException(e, context2);
}
}
}
private static bool _IsFiltered(System.Exception e, System.Web.HttpContext context)
{
if (_config == null)
{
_config = (context.GetSection("elmah/errorFilter") as ErrorFilterConfiguration) ?? new ErrorFilterConfiguration();
}
var context2 = new ErrorFilterModule.AssertionHelperContext((System.Exception)e, context);
return _config.Assertion.Test(context2);
}
private static void _LogException(System.Exception e, System.Web.HttpContext context)
{
ErrorLog.GetDefault((System.Web.HttpContext)context).Log(new Elmah.Error((System.Exception)e, (System.Web.HttpContext)context));
}
private static bool _RaiseErrorSignal(System.Exception e, System.Web.HttpContext context)
{
var signal = ErrorSignal.FromContext((System.Web.HttpContext)context);
if (signal == null)
{
return false;
}
signal.Raise((System.Exception)e, (System.Web.HttpContext)context);
return true;
}
}
Maintenant, dans votre filtre config que vous voulez faire quelque chose comme ceci:
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
//These filters should go at the end of the pipeline, add all error handlers before
filters.Add(new ElmahMVCErrorFilter());
}
L'avis que j'ai laissé un commentaire pour rappeler aux gens que s'ils veulent ajouter un filtre global qui va gérer l'exception, il faut aller de l'AVANT de ce dernier filtre, sinon, vous courez dans le cas où l'exception non gérée seront ignorés par le ElmahMVCErrorFilter parce qu'il n'a pas été manipulé et qu'il doit être interjeté par le Elmah module, mais ensuite le filtre suivant les marques de l'exception, comme manipulés et le module ignore, résultant de l'exception ne jamais en faire elmah.
Maintenant, assurez-vous que le appsettings pour elmah dans votre webconfig ressembler à quelque chose comme ceci:
<add key="elmah.mvc.disableHandler" value="false" /> <!-- This handles elmah controller pages, if disabled elmah pages will not work -->
<add key="elmah.mvc.disableHandleErrorFilter" value="true" /> <!-- This uses the default filter for elmah, set to disabled to use our own -->
<add key="elmah.mvc.requiresAuthentication" value="false" /> <!-- Manages authentication for elmah pages -->
<add key="elmah.mvc.allowedRoles" value="*" /> <!-- Manages authentication for elmah pages -->
<add key="elmah.mvc.route" value="errortracking" /> <!-- Base route for elmah pages -->
L'important ici est "elmah.mvc.disableHandleErrorFilter", si c'est faux, il va utiliser le gestionnaire à l'intérieur de elmah.mvc qui va gérer l'exception en utilisant la valeur par défaut HandleErrorHandler qui ignore votre customError paramètres
Cette configuration vous permet de définir votre propre ErrorHandler balises dans les classes et les points de vue, tout en continuant de loging ces erreurs par le biais de la ElmahMVCErrorFilter, l'ajout d'un customError configuration de votre site web.config à travers le elmah module, même l'écriture de vos propres Gestionnaires d'Erreur. La seule chose que vous devez faire est de se rappeler de ne pas ajouter des filtres qui va gérer l'erreur avant la elmah filtres que nous avons écrit. Et j'ai oublié de mentionner: pas de doublons dans elmah.
