Warum erstellt Log4Net keine Protokolldatei in der Produktion?

Question

Ich verwende VS2005, ein Website-Projekt, ein Web-Deployment-Projekt und Log4Net. Ich kann Protokollierung verwenden, wenn ich mich lokal entwickle. Ich kann die Protokolldateien sehen und alles ist in Ordnung. Wenn ich meine Website (mithilfe des Webbereitstellungsprojekts) erstelle, verwende ich die Bereitstellung als einzelne DLL-Option. Wenn ich dann den Speicherort der Protokolldateien überprüfe, kann ich keine Dateien sehen.

Gibt es eine Möglichkeit, dies zu beheben. Ich denke nicht, dass das Hinzufügen des Debug-Werts zu den App-Einstellungen hilfreich ist, da ich keine Konsole habe, weil es eine Website ist.

EDIT Ich will nicht die 150 rep zu verschwenden so ein letztes Mal zu gehen. Ich habe die interne Ablaufverfolgung von meiner Entwicklungsumgebung mit der Ablaufverfolgung von der Produktion verglichen. Mein Dev-Environment-Trace zeigt den Aufruf des Xml Configurator an, wo der Production nicht ist. Ich habe Code in der global.asax auf application_start() -Methode. Ich habe Debug-Code dort eingegeben und es wird im Dev aufgerufen, aber nicht in der Produktion.

Ich denke, dies ist, wo das Web-Deployment-Projekt einige Probleme verursacht. Wird die Datei global.asax in die einzelne DLL kompiliert? Wenn ich ein Build im Deployment-Verzeichnis mache, sehe ich eine global.compiled-Datei. Muss das in den bin Ordner in der Produktion gehen? Oder ist der global.asax-Code in der einzelnen DLL? Haben beide im bin Ordner oder nur die DLL nichts geändert.

Answer 1

ich das Problem gefunden zu haben. Berechtigungen waren RICHTIG. Es zeigt sich, dass bei der Verwendung eines Web-Bereitstellungsprojekts auch eine vorkompilierte.config-Datei im Stammverzeichnis erstellt wird. Ich hatte das nicht in die Produktion kopiert. Sobald das in der alles funktionierte. Tut mir leid, niemand hat das Kopfgeld bekommen.

Answer 2

Dies ist mir schon einmal passiert und war Berechtigungen für den ASPNET-Benutzer, um die Dateien wo erforderlich zu erstellen. Kann überprüfen, ob im Windows-Ereignisprotokoll etwas angezeigt wird, das dies anzeigt?

Um nach der Art der Sache zu suchen (wir beobachten den Beobachter!) Geben wir aus, wo das log4net arbeiten würde, indem wir dies mit OutputDebugString() via pinvoke. schreiben. Wir versuchen auch, Fehler zu finden, da dies sehr wichtig ist, um korrekt zu loggen.

Answer 3

Hat der Worker-Prozess ausreichende Berechtigungen, um in das Protokollverzeichnis zu schreiben? Ich schätze, das ist nicht der Fall. Vielleicht möchten Sie der Worker-Prozessgruppe Rechte zum Schreiben in das Verzeichnis erteilen und sehen, ob das Ihr Problem behebt.

Answer 4

Überprüfen Sie die Berechtigungen für das erwartete Ausgabeverzeichnis, und vergewissern Sie sich, dass der Webservice darauf schreiben kann. Der einfachste Weg ist, filemon.exe (eine SysInternals-App) auszuführen und entsprechend zu beschränken. Dies sollte Ihnen sagen, wenn etwas fehlschlägt und Sie können wie erforderlich beheben

Answer 5

Stellen Sie sicher, dass log4net richtig konfiguriert ist. Vielleicht ist die DLL in Ordnung, aber die Konfigurationsdatei fehlt? log4net könnte da sein, hat aber gerade keine aktiven Appender.

Answer 6

um sicher zu gehen, dass log4net richtig konfiguriert ist, erstelle ich einen UDP Appender, der sich an Port 9090 anmeldet. Ich benutze die Kettensäge http://logging.apache.org/chainsaw/index.html, um die Protokolleinträge zu überprüfen.

Mit diesem können Sie überprüfen, dass mindestens einige Log-Einträge gemacht werden und dass der Logger läuft.

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

Es ist wie die Wurzel des Problems sieht ist, dass das Ereignis Application_Start in global.asax feuert nicht.

Es gibt ein "bekanntes" Problem bei der Bereitstellung von VS 2005 nach Windows 2003, dass Application_Start nicht ausgelöst wird.

Der Inhalt von Global.asax.cs wird in die DLL kompiliert. Aber der Application_Start wird nur ausgeführt, wenn die Datei Global.asax vorhanden ist.

Hier sind ein paar relevante Links:

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

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

Es gibt einige andere Möglichkeiten, die in den obigen Links abgedeckt sind.

hoffe, das hilft

Shiraz

Answer 8

diese Datei in AssemblyInfo.cs hinzufügen und

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