Navigation for log4net - Caught By .Net!

All coders are quite familiar with error messages. They are quite handy when developing stuff but you don't want them around after the release of your system and the users don't really think they are too funny.

So, how can we get rid of these ugly messages and still get nice information when your functions break down? I have written some code (with some inspiration from other error logging examples) that provide your system with some nice features:

- On error, it redirects the user to a page that in English explains that an error has occurred. - You can set the object to either send an email or write in the EventLog, or both - All the browser information is included in the email for support help.- It can also present an "Alert" message to the user.

Trace Listening in ASP.NET Applications

If you are interested in writing your own trace listener (say to write to a database), you can do so from inheriting the System.Diagnostics.TraceListener class, which you can find examples on the web. However, if you want to use it in your web application, there are several steps you need to take, which you can find documented here: http://msdn2.microsoft.com/en-us/library/b0ectfxd.aspx

Autoflush means messages will be written automatically to the listener; if false, then a manual Flush() method call must be peformed before trace information is written. You add your custom class using the <add> element, like many other sections in the code. I left out the initializeData property, which may or may not be allowed with trace listeners.

Once defined, you can use tracing in two ways. First, you can use it manually:

System.Diagnostics.Trace.Write()

Or you can use the tracing that comes with the Page class (System.Web.TraceContext), defining this in the web.config:

writeToDiagnosticsTrace means that all tracing will run through the trace listeners you setup in the <system.diagnostics> section. The last step is to setup the compilers to output the switch /d:Trace, as defined below:

For windows projects, you can set up the /d:Trace switch in the property settings for the project. However, with web applications, you must specify the information here. If you don't specify the compiler options, tracing information through the diagnostics trace listener is ignored completely, which I found out the hard way when debugging.

To do this, you would add an EventLogTraceListener object either programmatically or by using the configuration file that uses the same procedure as for the WebPageTraceListener. You can open the Event Log to review the trace messages that your application writes to the Event Log.

Change the business component to work with database data instead of with an XML file. You do not need to make any change to the controls on the page.

Tracing in ASP.NET is somewhat orthogonal to tracing in the .NET Framework. The Systems.Diagnostics namespace defines two classes, Trace and Debug, whose methods are used to trace the code. The Trace and Debug classes are essentially identical and work on top of more specialized modules known as listeners. A listener collects and stores messages in the Windows event log, a text file, or some other similar file. Each application can have its own set of listeners; all registered listeners receive all emitted messages. The tracing subsystem of ASP.NET 2.0 has been enhanced to include support for forwarding ASP.NET tracing information to any registered .NET trace listeners. You enable this feature by turning on the writeToDiagnosticsTrace attribute in the <trace> section of the web.config file, like so:

Setting the writeToDiagnosticsTrace attribute is not enough, though. You also need to register one or more listeners for the Web application. Use the <trace> section under the <system.diagnostics> section to do that, as shown here:

There are two important things to note here. First, only text written through either Write or Warn is forwarded to the listeners. That is, the listener won't store a copy of the standard ASP.NET trace information; the information tracked is limited to the contents of the Trace Information section. The second thing is that you can write custom listeners to send trace information to the medium of your choice—for example, a SQL Server database. All you have to do is inherit a class from System.Diagnostics.TraceListener and override a few methods. Next, you register the new class with the web.config file of the Web application you plan to trace. (For more information on writing custom TraceListener types, see msdn.microsoft.com/msdnmag/issues/06/04/CLRInsideOut.) One interesting thing to note is that System.Web.dll now includes a TraceListener-derived type, WebPageTraceListener, whose job is to serve as the counterpart to writeToDiagnosticsTrace. When an instance of WebPageTraceListener is added to the trace listeners collection, messages written to the .NET diagnostics trace will also be written to the ASP.NET trace.

Finally, you should be aware that in ASP.NET 2.0 a new <deployment> section has been added to the Web configuration section related to tracing.