aidez-moi à trouver une solution de journalisation à friction minimale pour les applications asp.net

Question

Supposons que, pour des raisons d'argumentation, j'ai 30 applications Web asp.net (et sites, blerg) qui nécessitent un cadre de journalisation. Ma solution actuelle consiste à utiliser Enterprise Library Logging. Obtenir ce cours sur un site comprend les étapes suivantes:

1. ajouter des références à deux ensembles (Logging EL et communes)
2. ajouter du code à Global.asax.cs d'erreur générique piégeage non gérée
3. copie enterpriseLibrary .config, copié à partir d'une autre application qui a déjà la connexion copie
4. dans FileConfigurationSource.cs (ce qui vous permet de passer outre l'exigence d'un chemin hardcoded au enterpriseLibrary.config)
5. espace de noms de changement de FileConfigurationSource.cs au nouveau projet
6. copie sections web.config d'un autre projet qui sont spécifiques à EL (2 sections)
7. des espaces de noms de changement dans web.config pour EL dans le nouveau projet de test
8. et assurez-vous qu'il fonctionne (habituellement en prenant la base de données en ligne

Tout cela est la friction dont je parle. C'est beaucoup de violations de DRY si vous me demandez, en particulier dans tous les paramètres enterpriseLibrary.config. Idéalement, l'ajout de la notation serait un processus en deux étapes - cela m'aidera à l'adopter dans toute l'équipe.

Je me demande s'il existe une solution de journalisation pour .net que n'a pas toutes ces répétitions? Tous ceux que je peux trouver (log4net, nlog, EL Logging) semblent utiliser ce modèle "chaque application a sa propre configuration avec beaucoup de répétition". Peut-être qu'il me manque quelque chose.

En pratique, chacune de nos applications aura une solution de journalisation identique à 99% aux autres. Ils différeront dans l'endroit où ils stockent leurs journaux et ce que l'application est appelée. Existe-t-il un moyen d'utiliser l'une des trois grandes solutions de journalisation qui vous permettent de définir le comportement de journalisation au niveau de la machine ou dans un endroit plus centralisé? Je réalise qu'il y a des inconvénients à avoir une configuration de journalisation centralisée.

Il est également important: doit être en mesure de modifier le niveau de journalisation à la volée (pas de stockage config d'enregistrement dans web.config, ce qui provoque un redémarrage de l'application) et l'enregistrement doit être configurable dans le cadre d'un déploiement (ne veulent pas un email à envoyer sur les erreurs critiques sur le serveur bêta). Ces deux rendent difficile l'utilisation de web.config transforme depuis l'exécution d'une transformation sur un .config dans le cadre de votre build qui n'est pas un web.config est difficile.

Answer 1

J'ai trouvé une solution parfaite pour un problème similaire au vôtre.

J'ai dix applications de la console, deux sites ASP .NET et trois SharePoint webparts Se connecter à un seul répertoire, les journaux étant séparés par date, nom de l'application, etc. La solution est très configurable et flexible et permet la configuration changements à la volée. Toute cette gloire a été animée par NLog, ce qui permet de créer un fichier de configuration unique included à partir de fichiers de configuration spécifiques à l'application.

Pour être plus précis, dans notre cas, chaque projet contient individuel config NLog qui se lit comme:

<?xml version="1.0" encoding="utf-8" ?> 
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     autoReload="true"> 
    <include file="PATH TO THE SHARED CONFIG" /> <!-- change this line --> 
</nlog> 

Pour web applications, configuration NLog individuelle can be read from:

• fichier d'application Web standard web.config
• web.nlog situé dans le même répertoire que web.config
• NLog.config dans le répertoire de l'application
• NLog.dll.nlog dans un répertoire où NLog.dll est situé

fichier de configuration partagée peut être placé partout processus ASP .NET peut lire , et a également autoReload="true" qui permet des modifications à la volée. Dans notre cas, il définit différents targets pour les messages de journal, tels que les e-mails, les fichiers journaux dans différents répertoires, et cetera.