views:

554

answers:

4

Hi,

To solve an issue with sending e-mail through a smtp-server where e-mails are not getting sent, I was adviced to enable logging using System.Diagnosis.TextWriterTraceListener to trace the communication with the smtp-server to track any errors. I added the following to my web.config under the node:

<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>

I tried it out on my development machine and it worked just fine! I could easely read out the complete communication with the smtp-server. However, at the production environment (running on IIS 6 in Windows 2003 Server), it does not work at all. No log is getting written to the filesystem. My first thought was that perhaps the ASP.NET worker process account (NETWORK SERVICE) did not have sufficient rights to write to the filesystem at the specified location. I fixed that, but still get no log. Second, I thought that perhaps the folder was set to "read only" and fixed that as well. But still I get no log written.

Do anyone have an idea what the problem might be? Or perhaps some advice on how I could fix this? Thanx in advance!

A: 

Is it the same build in development and production? Frequently the TRACE conditional compilation constant is not defined in release mode. Then no tracing will show up.

Mike Two
Yes it is the same in both development and production. I also verified by enabling tracing on the exact same version but in a different production environment, and there it worked just fine. Thanks for the tip tho!
Clean
A: 

Have you tried using Process Monitor to see if the System.Net.trace.log file is being written or if there's an error creating it? Is it possible that it's just being written to a weird place you aren't looking for (I believe the default should be the current working directory of the ASP.NET worker process).

Matt Ellis
+1  A: 

First of all, I'd check if the trace actually works without writing anything to the file system. That is, I'd just use the regular windows trace. In order to view the trace output, I'd use Windows Sysinternals' DebugView. Of course, perhaps you should change your config file, I'm not that familiar with the syntax.

Now, if everything works fine for both environments (development and production), so that you can view the trace messages in the viewer, then the problem is more focused on the file system and log saving.

Where do you think your log file is saved to? Maybe it's a different location when it comes to production environment. I think that on Windows Server 2003 you should look for your file somewhere under WinDir, and not in the web application's folder(s).

When it comes to debugging such issues, I'd escalate the IIS' account to local/domain administrator just to see if the problem is solved or not. If it's solved then there's a permissions issue here.

Good luck!

Ron Klein
A: 

I would start by putting a fully-qualified path in the initializeData attribute:

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

If necessary, verify your app has write access to that path by adding a test page that creates a file in the same directory.

When you use a relative path as in your current configuration, I believe it will be relative to the application's root directory when running under IIS. But when running under Cassini on a development machine, this won't be the case - IIRC it will be relative to %WINDIR%\System32, but I wouldn't rely on this.

Joe