Pourquoi Log4Net ne crée-t-il pas de fichier journal en production?

Question

J'utilise VS2005, un projet de site Web, un projet de déploiement Web et Log4Net. Je peux utiliser la journalisation lorsque je me développe localement. Je peux voir les fichiers journaux et tout va bien. Lorsque je compile mon site Web (à l'aide du projet de déploiement Web), j'utilise le déploiement en tant qu'option DLL unique. Lorsque je vérifie ensuite l'emplacement de mes fichiers journaux, je ne vois aucun fichier.

Existe-t-il un moyen de résoudre ce problème? Je ne pense pas que l'ajout de la valeur de débogage aux paramètres de l'application aidera parce que je n'ai pas de console parce que c'est un site Web.

EDIT Je ne veux pas que le 150 rep se vide une dernière fois. J'ai comparé la trace interne de mon environnement de développement à la trace de la production. Ma trace de l'environnement de développement montre l'appel du configurateur Xml où celui de production ne l'est pas. J'ai du code dans la méthode global.asax sur application_start(). J'ai mis du code de débogage dedans et il est appelé en dev mais pas en production.

Je pense que c'est là que le projet de déploiement Web provoque des problèmes. Est-ce que global.asax est compilé dans la DLL unique? Quand je fais une construction dans le répertoire de déploiement, je vois un fichier global.compiled. Cela doit-il aller dans le dossier bin en production? Ou est le code global.asax dans la DLL unique? Avoir à la fois dans le dossier bin ou juste la DLL n'a rien changé.

Answer 1

J'ai trouvé le problème. Les autorisations étaient CORRECT. Il s'avère que l'utilisation d'un projet de déploiement Web crée également un fichier precompliled.config à la racine. Je n'avais pas copié cela à l'enivornment de production. Dès que c'était dans le tout travaillé. Désolé personne n'a eu la prime.

Answer 2

Cela m'est déjà arrivé et était autorisations sur l'utilisateur ASPNET pour créer les fichiers où nécessaire. Peut vérifier s'il y a quelque chose dans le journal des événements de Windows l'indiquant?

Pour vérifier le type de chose (nous regardons l'observateur!) Nous sortons où le log4net allait fonctionner en écrivant ceci en utilisant le OutputDebugString() via pinvoke.. Nous avons également mis cela dans un essai pour s'assurer que nous découvrons des erreurs à ce sujet car il est très important d'utiliser pour pouvoir se connecter correctement.

Answer 3

Le processus de travail dispose-t-il de privilèges suffisants pour écrire dans le répertoire des journaux? Je suppose que ce n'est pas le cas. Vous pouvez donner au groupe de processus de travail les droits d'écrire dans le répertoire et voir si cela résout votre problème.

Answer 4

Vérifiez les autorisations sur le répertoire de sortie attendu et assurez-vous que le service Web peut y écrire. La façon la plus simple de le faire est de lancer filemon.exe (une application SysInternals) et de la restreindre en conséquence. Cela devrait vous indiquer si quelque chose échoue et vous pouvez corriger si nécessaire.

Answer 5

Assurez-vous que la configuration de log4net est correctement configurée. Peut-être que la DLL est correcte, mais le fichier de configuration est manquant? log4net pourrait être là mais n'a aucun appender actif.

Answer 6

Pour vous assurer que la configuration de log4net est correcte, je crée un Appender UDP qui se connecte au port 9090. J'utilise la tronçonneuse http://logging.apache.org/chainsaw/index.html pour vérifier les entrées du journal. Cela vous permet de vérifier qu'au moins certaines entrées de journal sont terminées et que l'enregistreur est en cours d'exécution.

UDP Appender Config

<appender name="UdpAppender" type="log4net.Appender.UdpAppender"> 
     <remoteAddress value="localhost" /> 
     <remotePort value="9090" /> 
     <layout type="log4net.Layout.XmlLayoutSchemaLog4j"> 
      <locationInfo value="true" /> 
     </layout> 
</appender> 

Chainsaw XML

<?xml version="1.0" encoding="UTF-8" ?> 
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> 
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">  
    <plugin name="LocalReceiver" class="org.apache.log4j.net.UDPReceiver"> 
     <param name="Port" value="9090" /> 
    </plugin>  
</log4j:configuration> 

Answer 7

Il ressemble à la racine de votre problème est que l'événement Application_Start dans global.asax ne se déclenche pas.

Il existe un problème «connu» lors du déploiement de VS 2005 vers Windows 2003, que Application_Start ne déclenche pas.

Le contenu de Global.asax.cs sera compilé dans la DLL. Mais Application_Start ne s'exécutera que si le fichier Global.asax est présent.

Voici quelques liens pertinents:

http://accidentaltechnologist.com/asp-net/application_start-not-firing-and-the-globalasax/

http://www.velocityreviews.com/forums/t300292-web-deployment-projects-globalasax-problem.html

Il y a d'autres possibilités qui sont couvertes par les liens ci-dessus.

Hope this helps

Shiraz

Answer 8

Ajouter ce fichier dans AssemblyInfo.cs et vérifiez

[assembly: log4net.Config.XmlConfigurator(Watch=true)]