Comment traquer les problèmes de log4net

J'utilise log4net tout le temps, mais une chose que je n'ai jamais compris est comment savoir ce qui se passe à l'intérieur. Par exemple, j'ai un appender de console et un appender de base de données dans mon projet. J'ai apporté quelques modifications à la base de données et au code, et maintenant l'appender de base de données ne fonctionne plus. Je vais éventuellement comprendre pourquoi, mais cela aiderait beaucoup si je pouvais voir ce qui se passe dans log4net.

Log4net génère-t-il un type de sortie que je peux afficher pour essayer de déterminer la source de mon problème?

Vous devez d'abord définir cette valeur sur le fichier de configuration de l'application:

<configuration>
   <appSettings>
      <add key="log4net.Internal.Debug" value="true"/>
   </appSettings>
</configuration>

Ensuite, pour déterminer le fichier dans lequel vous souhaitez enregistrer la sortie, vous pouvez ajouter le code suivant dans le même fichier .config:

<configuration>
...

<system.diagnostics>
    <trace autoflush="true">
        <listeners>
            <add 
                name="textWriterTraceListener" 
                type="System.Diagnostics.TextWriterTraceListener" 
                initializeData="C:\tmp\log4net.txt" />
        </listeners>
    </trace>
</system.diagnostics>

...
</configuration>

Vous pouvez trouver une explication plus détaillée sous «Comment activer le débogage interne de log4net?» dans la page FAQ de log4net .

Si vous utilisez un fichier de configuration log4net, vous pouvez également y activer le débogage en modifiant le nœud supérieur en:

<log4net debug="true">

Cela fonctionnera une fois la configuration rechargée et en supposant que votre écouteur de trace est correctement configuré.

En plus de la réponse ci-dessus, vous pouvez utiliser cette ligne pour voir le journal en temps réel au lieu de la sortie c: \ tmp \ log4net.txt.

log4net.Util.LogLog.InternalDebugging = true;

Par exemple, dans une application console, vous pouvez ajouter ceci, puis regarder la sortie en temps réel. C'est bon pour déboguer log4net dans un petit faisceau de test pour voir ce qui se passe avec l'appender que vous testez.

Assurez-vous que l'application racine où se trouve votre point d'entrée enregistre quelque chose dans log4net. Donnez-lui l'un de ceux-ci:

private static ILog logger = LogManager.GetLogger(typeof(Program));
static void Main(string[] args)
{
    logger.InfoFormat("{0} v.{1} started.", Assembly.GetExecutingAssembly().GetName().Name, Assembly.GetExecutingAssembly().GetName().Version.ToString());

Avec 2.0.8, j'ai eu une situation intéressante. J'ai créé un projet de bibliothèque et un projet d'exe de test qui démontreraient ses capacités. Le projet de bibliothèque a été configuré pour utiliser Log4net, tout comme le projet exe. Le projet exe a utilisé l'attribut assemblyinfo pour enregistrer la configuration, mais je n'obtenais aucune sortie de journalisation vers la console ou le fichier journal. Lorsque j'ai activé la journalisation du débogage interne de log4net, j'ai reçu des messages internes écrits sur la console, mais toujours aucun de mes journaux normaux. Aucune erreur n'a été signalée. Tout a commencé à fonctionner lorsque j'ai ajouté le code ci-dessus à mon programme. Log4net était par ailleurs correctement configuré.

Si le journal interne ne vous donne pas suffisamment d'informations, il est très facile de créer et de déboguer le code source . Si vous ne voulez pas mélanger cela avec votre projet de développement, ajoutez une application console simple qui enregistre simplement un message, copiez votre projet log4net.configdans cette application et déboguez la classe en question.

Dans log4net 2.0.8, il semble impossible d'effectuer la journalisation avec log4net dans une DLL distincte. Si j'ai essayé cela, les résultats sont très étranges: aucune journalisation n'est plus effectuée. Et l'initialisation de log4net avec l'option de débogage ne montre aucune erreur.

Comme K0D4 l'a dit, vous devriez avoir une référence à log4net dans votre module principal et si vous l'appelez une fois au début du programme, tout va bien.

Dans la prochaine version de log4net, ce bogue sera probablement corrigé.