2010-01-28 18 views
8

Per risolvere un problema con l'invio di e-mail tramite un server smtp in cui le e-mail non vengono inviate, ho consigliato di abilitare la registrazione usando System.Diagnosis .TextWriterTraceListener per tracciare la comunicazione con smtp-server per tracciare eventuali errori. Ho aggiunto il seguente al mio web.config sotto il nodo:Problema con System.Diagnosis.TextWriterTraceListener che non scrive alcun log sul filesystem

<system.diagnostics> 
     <trace autoflush="true" /> 
     <sources> 
     <source name="System.Net" > 
      <listeners> 
      <add name="MyTraceFile"/> 
      </listeners> 
     </source> 

     <source name="System.Net.Sockets"> 
      <listeners> 
      <add name="MyTraceFile"/> 
      </listeners> 
     </source> 
     </sources> 

     <sharedListeners> 
     <add 
      name="MyTraceFile" 
      type="System.Diagnostics.TextWriterTraceListener" 
      initializeData="System.Net.trace.log"    /> 
     </sharedListeners> 

     <switches> 
     <add name="System.Net" value="Verbose" /> 
     <add name="System.Net.Sockets" value="Verbose" /> 
     </switches> 
    </system.diagnostics> 

ho provato sulla mia macchina di sviluppo e ha funzionato bene! Ho potuto facilmente leggere la comunicazione completa con il server smtp. Tuttavia, nell'ambiente di produzione (eseguito su IIS 6 in Windows 2003 Server), non funziona affatto. Nessun log viene scritto sul filesystem. Il mio primo pensiero è stato che forse l'account del processo di lavoro ASP.NET (NETWORK SERVICE) non aveva diritti sufficienti per scrivere sul filesystem nel percorso specificato. Ho riparato quello, ma ancora non ottengo il registro. In secondo luogo, ho pensato che forse la cartella era impostata su "sola lettura" e ha risolto anche quello. Ma continuo a non scrivere nessun log.

Qualcuno ha un'idea di quale potrebbe essere il problema? O forse qualche consiglio su come potrei risolvere questo problema? Grazie in anticipo!

risposta

3

Prima di tutto, controllerei se la traccia funziona effettivamente senza scrivere nulla sul file system. Cioè, vorrei solo usare la normale traccia di Windows. Per visualizzare l'output di traccia, userei Windows Sysinternals' DebugView. Certo, forse dovresti cambiare il tuo file di configurazione, non sono così familiare con la sintassi.

Ora, se tutto funziona correttamente per entrambi gli ambienti (sviluppo e produzione), in modo che sia possibile visualizzare i messaggi di traccia nel visualizzatore, il problema è più focalizzato sul file system e sul salvataggio dei registri.

Dove pensi che il tuo file di registro sia stato salvato? Forse è un posto diverso quando si tratta di un ambiente di produzione. Penso che su Windows Server 2003 dovresti cercare il tuo file da qualche parte sotto WinDir, e non nelle cartelle dell'applicazione web.

Quando si tratta di eseguire il debug di questi problemi, eseguire l'escalation dell'account di IIS all'amministratore locale/di dominio solo per vedere se il problema è risolto o meno. Se è risolto, c'è un problema con le autorizzazioni qui.

Buona fortuna!

2

È la stessa build nello sviluppo e nella produzione? Frequentemente la costante di compilazione condizionale TRACE non è definita in modalità di rilascio. Quindi nessuna traccia apparirà.

+0

Sì, è lo stesso sia nello sviluppo che nella produzione. Ho anche verificato abilitando la traccia sulla stessa identica versione ma in un diverso ambiente di produzione, e lì ha funzionato bene. Grazie per il suggerimento! –

1

Hai provato a utilizzare Process Monitor per verificare se il file System.Net.trace.log è stato scritto o se si è verificato un errore durante la creazione? È possibile che sia stato scritto solo in un posto strano che non si sta cercando (credo che l'impostazione predefinita dovrebbe essere la directory di lavoro corrente del processo di lavoro ASP.NET).

2

vorrei iniziare mettendo un percorso completo nell'attributo initializeData:

<add 
     name="MyTraceFile" 
     type="System.Diagnostics.TextWriterTraceListener" 
     initializeData="c:\SomePath\System.Net.trace.log"     
/> 

Se necessario, verificare la vostra applicazione ha accesso in scrittura a quel percorso con l'aggiunta di una pagina di prova che crea un file nella stessa directory.

Quando si utilizza un percorso relativo come nella configurazione corrente, credo che sarà relativo alla directory radice dell'applicazione quando è in esecuzione in IIS. Ma quando si esegue sotto Cassini su una macchina di sviluppo, questo non sarà il caso - IIRC sarà relativo a% WINDIR% \ System32, ma non fare affidamento su questo.

+0

Solo per i record, sembra che tu abbia torto e l'implementazione Microsoft verificherà se il percorso fornito in initializeData è relativo o meno. http://nicholas.piasecki.name/blog/2009/03/on-textwritertracelistener-inheritance-initializedata-aspnet-and-paths/ – Oscar

+0

@Oscar - blog interessante che fa notare che alcuni ingegneri Microsoft hanno avuto una brutta giornata. Ma la soluzione "MungeFileName" proposta potrebbe essere sostituita dal più semplice "Path.Combine (AppDomain.CurrentDomain.BaseDirectory, fileName)". Il metodo Path.Combine è abbastanza intelligente da gestire il caso in cui il suo secondo argomento è un percorso assoluto a sé stante. – Joe

1

Il mio problema era che la costante TRACE non era stata definita in un progetto dipendente, quindi, anche se era stata impostata nel progetto principale, non registrava ancora. Una volta aggiunta la costante TRACE al progetto dipendente, ha funzionato come previsto.

Problemi correlati