I would like to implement exception handling on a ASP.NET application. How do you suggest I implement it? Some requirements are:
User should see a friendly page when an exception occurs
Admin should get an email with exception details
I understand there are several ways of implementing exceptions (ex: Log messages in the event viewer)
What's the recommended approach?
The recommended approach really depends on what you need to do with the error information.
For simple apps, just setting up the web.config file to redirect to a friendly error page might be enough.
It's usually a good idea to record unhandled error information to a database, file, windows application log or web service by handling them with the Global.asax Application_Error event. You can also use the web.config to get your friendly page with that. Generally I wouldn't recommend using the windows error logs as they tend to be a bit obtuse, but there's nothing wrong with it.
For very detailed operational information, including warnings and info messages, tools like log4net are widely used. Usually you would go this route for products or enterprise level applications where your support teams need as much information as possible to diagnose the errors.
MSDN has a walkthrough of some of the basic error handling setups and what you can do with them.
I wrote an article on this that I think you'd really like
http://dotnetblogger.com/post/2008/12/03/ASPNET-Health-Monitor.aspx
As for the friendly page bit, I just use the built in exception handling in the web.config... since you are implementing the unknown exception stuff in the global.asax
You can also handle exceptions in try/catch blocks and add a note to it if you want. Then just bind the database to a nice gridview for admins to easily see the errors.
I have a nice reusable HttpModule that you can look at here. It can be used to easily deal with Exceptions that occur during normal user requests, and those that occur in background threads.
Related
I am building website, which is using ASP.NET, MS-SQL and AJAX.
I wonder, what is the best way to log errors in the entire website?
What I was thinking about, is just create some global log class (accessible from entire application) and log errors to "asperror.txt" file using try catch blocks in asp.net.
Is this good way to track errors? Maybe there is some better ways?
Thank you.
My humble opinion, and to not to reinvent the wheel, is to use ELMAH, which is great and easy to configure in ASP.NET.
It allows logging to Database, File, Email and so forth. It catches all unhandled exceptions and even allows you to see the last X (certain buffer is available, I believe is 500) number of messages through a web page. It even has a RSS feed if you want to subscribe to it.
Use ELMAH:
ELMAH with initial configuration for getting started quickly. ELMAH (Error Logging Modules and Handlers) is an application-wide error logging facility that is completely pluggable. It can be dynamically added to a running ASP.NET web application, or even all ASP.NET web applications on a machine, without any need for re-compilation or re-deployment.
Is there a way to test if the current request (HttpContext.Current.Request) is available in the Application_Error event of the Global.asax when using Integrated Pipeline with IIS7 in ASP.NET? Currently I am using a try-catch, but it seems like there should be a way to verify rather than catching an exception.
Unfortunately, I believe the answer to your question is no. This question seems to cover what you're asking. You can use reflection, but it doesn't seem very reliable. Articles like this blog post recommend not doing this, and even say:
"Because this event is intended for global initialization activities, any logic that references a specific request is typically a design oversight."
But what does he know about the design of your site, amirite? Your only choice if you really want this is to go back down to Classic.
My application needs to log informations about user actions (inserts, updates, deletes, etc) and exceptions and i want to store de log on Oracle10, so i'am searching some log framework to use.
I read a little bit about:
1 -Log4Net
2 - Logging Application Block
3 - Elmah
Whats your opinion about these log tools?
Whats a good framework (or way to implement) log on my application?
*After a discussion with the project manager, Logging Application Block
will be our choice, but, lets comment about this =)
Both log4net and Logging Application Block are valid choices. I think ELMAH is mostly focused on error logging, so that is probably not (the only thing) that you want.
At work, I use log4net on a couple of projects. It is stable, performant and extensible, and we have never had any problems with it.
I would probably do logging with log4net and log exceptions with ELMAH also. It can log unhandled exceptions manually, and any exception you catch and handle in your application can be logged with a single call to ELMAH. This might seem like double-logging (and it is :-)). But it is very valuable to have the ELMAH log when something unexpected has failed in your application.
I have heard good things about the NLog project, but haven't used it myself. It seems to be a bit more complex that log4net, but does have the added benefit of being able to add contextual information to log messages automatically (a bit like ELMAH).
My opinions about the different frameworks:
Log4Net - Love it. This is the logging system that I use most often. Everything is fairly easy to get started. It's also very flexible and allows you to log just about anything.
Logging Application Block - Also a good option. I still prefer Log4Net (but the reasons are mostly personal).
Elman - Great for dropping in to an ASP.NET application to log Exceptions. For general message logging though, I would still go with Log4Net.
And I'm guessing based on my opinions what I would suggest you do...
And if not, use Log4Net and create an Adapter you can use in your application to make logging simple.
I personally like BitFactory.Logging because it's lightweight and uses the right amount of abstractions to make the calling code easily testable.
That said, the things you want to log (inserts, updates, deletes) could be logged using only triggers, a solution that might perform better depending on your setup.
I personally always create a wrapper anyway, so I have my own ILog implementation, that works with whichever of these that you choose. This makes it easy to swap in or our implementations.
I tried #2 but it was kind of a pain; #1 would have worked out well for us but we didn't go for it, just went simple custom logging. All I know about #3 is that I know of someone having trouble implementing it in their org. Don't know why, but it actually looks pretty interesting. I don't think you can go wrong with any personally. It partially depends on the API that you like.
HTH.
Log4net is quiet good, it is basically a version of log4j. Elmah is nice also, especially if you find (like me) that you are unable to write to files on the production environment, since it writes to the DB instead. Also, Elmah is more suited for exception logging, and is cool because it allows you to log based on events. In my projects I normaly deploy both log4net and Elmah
If you are auditing data changes in a db then you can use triggers on the relevant table.
For logging in a dotNet app use TraceSource to write logging info and a custom TraceListener to write to a db. Don't need a framework beyond the base class library really.
What's the best way to log in ASP.net MVC? I mean any event, I'm currently using NLog but I know there are a lot of possible ways to do it.
I use log4net, its quite good. There are some issues to be aware of, you can learn more about them here. I also recommend Elmah, for me I use it on every project I do, its a prerequisite.
I don't think there is a best framework/tool or standard way in ASP.net MVC. Just do it the way you would in any other framework. When I set up logging, I usually think of it as a resource available to the rest of the application, rather than being tied to a particular tier. This is common, and in fact logging is the standard example given when introducing Aspect Oriented Programming. See:
Logging mentioned in the wikipedia entry on AOP
Another AOP into that uses logging as the example
Depending on what exactly you're trying to log, consider using action filters; a great way to log what page requests are made and for error handling coverage. Non-MVC asp.net apps usually do something in the global.asax, as mentioned here. In fact, even if you use the action filters, which I would suggest, also include some basic error handling in the global.asax 's application_error event; it will fire a little more dependably than the action filters if something really crazy happens.
Other than that, call your logging resource at the point where the stuff happens that's interesting to you. DB or File? Either works, and as long as it's encapsulated in a good method or two, you can always switch that later.
I'm looking at a fresh asp.net site in 3.5 that has absolutely no error handling or logging. What are some good options for logging and handling errors? I've used Log4Net on the 1.1 framework but hear there are potentially better options in 3.5.
One option is ELMAH. I asked a question about it here: ASP.NET Error Handling.
Since then, I have implemented a slightly modified version of it and the logging plus e-mail is great and easy to integrate via the web.config file.
We use two options for our logging:-
ELMAH for unexpected exception handling
NLog for expected, manual (debug, info and error) information.
ELMAH is a great out-of-the-box plugin that automatically captures exceptions (from 404's (page not found) to 500 exception thrown) and has a built in web-ui to visualize these errors. So it's a really quick and effective way of grabbing unexpected errors that occur.
Now NLog compliments this by having our developers manually insert debugging information into the code at specific spots, so when we need to get information out of a non-locahost system, it's very easy. For example, we litter log.Debug(..) code in most of our methods to see what the local variables are or returned values, etc. For more important information, we then use log.Info(..) .. but use this a lot less. Finally, for serious errors which we have trapped and handle, we use log.Error(..) or log.Warn(..) .. generally inside some try/catch scopes. So on our test or live servers, we then turn on all logging states (eg. Debug and greater) if we need to grab LOTS of data, live... or just the general important information, such as Info states and greater. We always have Warn, Error and Fatal states always on. Debug state generates a LOT of data, so we use that only sparingly.
So to summarize, I suggest you use TWO approaches to your WebApp. Elmah for excellent unexpected error trapping and NLog for expected information and errors.
Finally, NLog is WAAAY easier to use/get working than Log4Net. It basically superceeds it, IMO.
If you are used to log4net, stick with what you know. It's easy, fast, and works well. I've used it for years in 1.1, 2.0, and now 3.5.
ASP.NET Health Monitoring actually does a pretty decent job right out of the box!
MSDN, How to: Send E-mail for Health Monitoring Notifications
Enterprise Library maybe has a learning curve but is a good project.
In Asp.Net follow david hayden's article Enterprise Library 2.0 Logging Application Block
Personally, I havent tried log4net but seen the specs and examples for winforms, but my organization coded our own logging mechanism that reports and logs errors that are caught in the global.asax that reports everything we need to know about the stack trace, session (if exists), form's NVC, version of the app, URL that originated the error with querystring, and HTTP headers. Though I noticed that not all errors get logged there; such as forms authentication expiration or application pool restart/shutdown or anything reported by IIS that was not thrown by the application executing.