Perché Log4Net non crea il file di registro in produzione?

Question

Sto utilizzando VS2005, un progetto di sito Web, un progetto di distribuzione Web e Log4Net. Posso usare la registrazione quando sto sviluppando localmente. Posso vedere i file di registro e tutto va bene. Quando creo il mio sito Web, (utilizzando il progetto di distribuzione Web), utilizzo la distribuzione come una singola opzione DLL. Quando quindi controllo le posizioni di dove dovrebbero essere i miei file di registro non riesco a vedere alcun file.

C'è un modo per risolvere questo problema. Non credo che l'aggiunta del valore di debug alle Impostazioni app sarà di aiuto perché non ho una console perché è un sito web.

MODIFICA Non voglio che il rappresentante da 150 giri sprechi così un'ultima volta. Ho confrontato la traccia interna dal mio ambiente di sviluppo alla traccia proveniente dalla produzione. La traccia del mio ambiente di sviluppo mostra la chiamata a Xml Configurator dove non è presente la produzione. Ho il codice nel global.asax sul metodo application_start(). Inserisco il codice di debug e viene chiamato in dev ma non in produzione.

Penso che questo sia il punto in cui il progetto di distribuzione Web sta causando alcuni problemi. Il file global.asax viene compilato nella singola DLL? Quando eseguo una compilazione nella directory di distribuzione, vedo un file global.compiled. Deve questo andare nella cartella bin in produzione? O è il codice global.asax nella singola DLL? Avere entrambi nella cartella bin o semplicemente la DLL non ha cambiato nulla.

Answer 1

ho trovato il problema. Le autorizzazioni erano corrette. Si scopre che l'utilizzo di un progetto di distribuzione Web crea anche un file precompliled.config nella root. Non l'avevo copiato sull'ambiente di produzione. Non appena è stato tutto ha funzionato. Spiacente, nessuno ha la taglia.

Answer 2

Questo mi è successo prima ed era permessi all'utente di ASPNET per creare i file dove necessario. Può controllare se c'è qualcosa nel registro eventi di Windows che indica questo?

Per verificare il tipo di cosa (guardiamo l'osservatore!), Emettiamo dove log4net avrebbe funzionato scrivendo questo usando lo OutputDebugString() via pinvoke.. Mettiamo anche questo in un tentativo di cattura per garantire che scopriamo gli errori in questo senso in quanto è molto importante utilizzare per essere in grado di accedere correttamente.

Answer 3

Il processo di lavoro dispone di privilegi sufficienti per scrivere nella directory del registro? Suppongo che non sia così. Si potrebbe desiderare di assegnare ai diritti del gruppo di processi worker di scrivere nella directory e vedere se questo risolve il problema.

Answer 4

Verificare le autorizzazioni sulla directory di output prevista e assicurarsi che il servizio Web possa scrivere su di esso. Il modo più semplice per farlo è eseguire filemon.exe (un'app SysInternals) e limitarlo di conseguenza. Questo dovrebbe dirti se qualcosa non funziona e puoi correggere se necessario

Answer 5

Assicurarsi che log4net get sia configurato correttamente. Forse la dll va bene ma manca il file di configurazione? log4net potrebbe essere lì ma semplicemente non ha appendici attive.

Answer 6

per assicurarsi che log4net sia configurato correttamente creo un UDP Appender che registra sulla porta 9090. Io uso la motosega http://logging.apache.org/chainsaw/index.html per controllare le voci del registro.

con questo è possibile verificare che almeno alcune voci di registro siano state eseguite e che il logger sia in esecuzione.

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

Sembra che la radice del problema è che l'evento Application_Start in Global.asax non sta sparando.

C'è un problema "noto" quando si esegue la distribuzione da VS 2005 a Windows 2003, che Application_Start non attiva.

Il contenuto di Global.asax.cs verrà compilato nella DLL. Ma Application_Start non verrà eseguito a meno che non sia presente il file Global.asax.

Qui ci sono un paio di link pertinenti:

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

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

Ci sono alcune altre possibilità che sono coperti in link qui sopra.

Spero che questo aiuti

Shiraz

Answer 8

Aggiungere questo nel file AssemblyInfo.cs e controllare

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