Outils d'enregistrement des exceptions dans .Net

Question

Je suis à la recherche d'un bon outil qui me donnera une analyse détaillée des exceptions dans les versions de production.

Je connais EurekaLog et j'ai vu une fois un ajout pour un logiciel avec une grenouille ou quelque chose de similaire dans son nom, cherché dans Google sans aucun résultat.

Quelqu'un a-t-il des recommandations?

Mon objectif principal est bien sûr d'extraire le maximum d'informations utiles lorsqu'un crash se produit en production.

Également, peut-être un peu hors sujet, quelque chose de similaire pour la détection de verrouillage mort.

Answer 1

Log4Net

Answer 2

Nous utilisons Enterprise Library journalisation bloc d'application.

http://msdn.microsoft.com/en-us/library/dd139916.aspx

Vous déterminez à quel point est connecté, grâce à la configuration et où vous placez les déclarations de journalisation. Il vous permet également de modifier la quantité d'informations enregistrées sans arrêter le système.

Answer 3

Pas vraiment sûr si vous cherchez une solution Winforms ou ASP.NET ici. Mais pour ASP.NET j'utilise Elmah (http://code.google.com/p/elmah/).

Answer 4

Si vous voulez la liberté de choix sans créer une forte dépendance à une infrastructure de journalisation spécifique (Log4Net, nLog, EntLib), vous pouvez consulter la bibliothèque Common.Logging. Il résume essentiellement l'implémentation de l'enregistreur, en n'exposant qu'une interface commune à tous les blocs de journalisation disponibles.

Voir:

http://netcommon.sourceforge.net/

Avertissement: Je ne l'ai pas utilisé moi-même (encore), mais je ne l'intention d'essayer quelque temps bientôt. L'idée de ne pas être lié à un enregistreur spécifique me plaît, car j'aime coller à une bibliothèque de journaux par projet. Imaginez que vous construisiez un projet qui utilise nLog pour la journalisation, mais ensuite vous ajoutez NHibernate. NH utilise Log4Net, alors maintenant nous avons deux bibliothèques de journalisation dans nos dépendances ;-)

Answer 5

Merci pour vos réponses, mais ce n'est pas la direction que je cherchais. Je suis plus intéressé par les exception rapports d'erreurs inattendues/accidents, et la quantité maximale de données qui peuvent être extraites pour comprendre pourquoi cela est arrivé, comme tous les threads traces de pile, dernières actions (clics) l'utilisateur a fait , etc.

les cadres d'exploitation forestière ne sont aussi précieux que les choses que j'écris.