我有企业日志记录&在我的web应用程序中启用异常日志记录。 web.config被设置，所以一切都应该工作。它之前在其他服务器上工作过，因为位于应用程序根目录中的trace.log文件中包含跟踪信息。 我在我的本地机器上清除了我的trace.log，以便在出现异常时测试它是否正在工作。我创建了一个引发异常的测试页面。然后我调用ExceptionPolicy.HandleException（例如，“Exception Policy”）并在需要时重新引发。 我的trace.log保持空着，所以我无法弄清楚它为什么不起作用。 我对此很新，但我知道这一定是以前的工作。我不确定的是，异常是否会写入日志文件，或者只是由于HandleException（）调用？EnterpriseLibrary异常处理不写入我的日志文件
我正在努力调试为什么这不起作用。
我最终这样做了，并正在记录帮助我&其他人。这是因为我缺乏对这种工作方式的了解以及我们承包商编写的奇怪代码。
基本上我们的堆栈由
DA层 BO层 应用层
的BO层访问DA的。如果出现问题，则在Try/Catch中处理。它在catch内部调用ExceptionPolicy.HandleException（）并返回rethrow布尔值。但是它不会检查这个值来执行另一次抛出，这意味着错误不会引发到ASP.NET错误运行时。
奇怪的是，他们在BO对象上设置了一个IsExceptionGenerated标志，然后在App层上进行检查。应用层然后重定向到'〜\ error.aspx'。
我改变了这个，所以检查策略并重新抛出异常。但是没有任何地方记录了这种怀疑。在重定向到error.aspx之前，我不希望在整个应用程序中散布大量日志记录。因此我添加了global.asax错误处理程序来记录错误。我也可以删除所有的重定向，并让web.config使用CustomErrors部分指定直接到错误页面。
它现在似乎工作！
我想知道在我的应用程序中response.redirects（“error.aspx”）是不好的做法。我想知道他们在写这些时在想什么。我可以理解，有时候你可能想要错误，有时继续优雅地继续追踪它，但肯定可以通过使用不同的例外策略来处理。
任何想法的人？
答案的最后部分更多的是一个问题。这应该可能是一个新问题。 – 2010-05-19 13:43:21
我同意我将发布为不同的问题 – jaffa 2010-05-20 08:39:29