System.Diagnosis.TextWriterTraceListener 未将任何日志写入文件系统的问题
为了解决通过 smtp 服务器发送电子邮件而无法发送电子邮件的问题，建议我使用 System.Diagnosis.TextWriterTraceListener 启用日志记录，以跟踪与 smtp 服务器的通信以跟踪任何错误。我将以下内容添加到节点下的 web.config 中：
<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>
我在我的开发计算机上尝试了它，它工作得很好！我可以轻松读出与 smtp 服务器的完整通信。然而，在生产环境（运行在Windows 2003 Server中的IIS 6上），它根本不起作用。没有日志写入文件系统。我的第一个想法是，ASP.NET 工作进程帐户 (NETWORK SERVICE) 可能没有足够的权限写入指定位置的文件系统。我修复了这个问题，但仍然没有日志。其次，我认为该文件夹可能被设置为“只读”并修复了该问题。但我仍然没有写任何日志。
有谁知道问题可能是什么？或者也许对我如何解决这个问题有一些建议？提前致谢！
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!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
首先，我会检查跟踪是否确实有效，而不向文件系统写入任何内容。也就是说，我只使用常规的 Windows 跟踪。为了查看跟踪输出，我将使用 Windows Sysinternals 的 DebugView。当然，也许你应该更改你的配置文件，我对语法不太熟悉。
现在，如果两个环境（开发和生产）一切正常，以便您可以在查看器中查看跟踪消息，那么问题更集中在文件系统和日志保存上。
您认为您的日志文件保存在哪里？也许是生产环境不同。我认为在 Windows Server 2003 上，您应该在 WinDir 下的某个位置查找文件，而不是在 Web 应用程序的文件夹中。
当涉及到调试此类问题时，我会将 IIS 帐户升级到本地/域管理员，只是为了看看问题是否得到解决。如果解决了，那么这里存在权限问题。
祝你好运！
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!
开发和生产的构建是否相同？通常，TRACE 条件编译常量不是在发布模式下定义的。那么就不会出现任何跟踪。
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.
首先，我将在initializeData属性中放置一个完全限定的路径：
如有必要，通过添加在同一目录中创建文件的测试页来验证您的应用程序是否具有对该路径的写访问权限。
当您在当前配置中使用相对路径时，我相信在 IIS 下运行时它将相对于应用程序的根目录。但是，当在开发计算机上的 Cassini 下运行时，情况不会如此 - IIRC 它将相对于 %WINDIR%\System32，但我不会依赖于此。
I would start by putting a fully-qualified path in the initializeData attribute:
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.
您是否尝试过使用 进程监视器 来查看 System.Net.正在写入trace.log 文件或者创建它时是否出现错误？是否有可能它只是被写入您不需要的奇怪位置（我相信默认值应该是 ASP.NET 工作进程的当前工作目录）。
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).
我的问题是 TRACE 常量没有在依赖项目中定义，所以即使它在主项目中设置，它仍然不会记录。一旦我将 TRACE 常量添加到依赖项目中，它就会按预期工作。
My problem was that the TRACE constant was not defined in a dependent project, so even though it was set in the main project, it still wouldn't log. Once I added the TRACE constant to the dependent project, it worked as expected.