Thursday, February 5, 2009

Complete example using custom errors and write errors to the Event log

Writing to the Windows 2000 Event Log is a powerful feature of the ASP.NET and .NET framework. For those individuals who work in a large company and want to make track application errors, writing to the event log is a must!Writing to the Windows 2000 Event Log is a powerful feature of the ASP.NET and .NET framework. For those individuals who work in a large company and want to make track application errors, writing to the event log is a must! There wasn't any complete demos actually showing from A - Z how this was setup for the novice/common developer like me. Most novice developers need to be spoon fed how things are done the first time, once they see a simple example, they'll understand how the process works! This example is my reference how to make a complete application from A - Z setup and fail to understand how it works.

Step 1
First of all the steps I followed was to create a simple web called eventlog. I also created the application root so the global.asax file would fire. Here is how to setup an application root:
1.Open Internet Service Manager MMC (Start button, Control Panel, Administrative Tools, Internet Service Manager)
2.Located on the left side of the MMC, locate the Default Web and click the + button to expand the list of webs.
3.Right-click on the web your going to make an application root and choose properties.
4.Click the Create button.
5.After your done, the folder picture will appear like a box that is open. The application root is now created.

Step 2
I opened the global web.config file and turned on custom errors. Path to this is c:\winnt\microsoft.net\framework\.. There are 3 choices available currently On, Off and RemoteOnly. From attending the conference, the recommended was RemoteOnly. This means anyone not on the console of the machine will see a friendly error and not the real thing. For this example I chose On. You also could leave the global web.config file custom errors turned off and configure at application level's web.config Either way works just fine. web.config -- this file is placed in the root of the \eventlog application root.








Step 3 The next few items are just to create sample pages to make the application complete. I created a web.config, global.asax, Default.aspx page, and three sample error pages. 404page.aspx, 403page.aspx and customerrorpage.aspx page. Here are those pages code for all pages.
Global.asax Page - This uses the Application_OnError event to capture stuff if an error happens
<%@ Import Namespace="System" %>
<%@ Import Namespace="System.Diagnostics" %>

Default.aspx page


<% @Language="VB" %>







Customerrorpage.aspx

custom error page



404page.aspx --Capture all 404(Not Found pages)
403page.aspx --Capture all 403(Restricted pages)

Step 4
After all webs are created, web.config files in place. It was time to test out the application to see if it works. Type in http://localhost/eventlog/default.aspx file, this will display a button. Click it and see if this actually creates the log and writes the information to the event log. Actually only the custom error page will be displayed, the eventlog.aspx page will error and be transfered to the customerrorpage.aspx. The URL will be something like this. http://localhost/eventlog/customerrorpage.aspx?aspxerrorpath=/eventlog/eventlog.aspx

Step 5
Verify the log was created and entry was placed in that log. Below is five possible types of Event log messages:
Error An error event. This indicates a significant problem the user should know about; usually a loss of functionality or data.
FailureAudit A failure audit event. This indicates a security event that occurs when an audited access attempt fails; for example, a failed attempt to open a file.
Information An information event. This indicates a significant, successful operation.
SuccessAudit A success audit event. This indicates a security event that occurs when an audited access attempt is successful; for example, logging on successfully.
Warning A warning event. This indicates a problem that is not immediately significant, but that may signify conditions that could cause future problems. Thats it! This was a high-level example with examples but hopefully helps in understanding how a sample application and using the new Error-handling features of ASP.NET... Enjoy!!

No comments:

Post a Comment