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.
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.
I'm trying to debug an ASP.NET MVC application which uses the .NET 4.5 version of WIF to provide user identity. As those claims are being generated by a remote STS specific for that user, it's hard to test which claims are being received for a given user in an development environment.
What I would like is a mechanism that will allow me to see a user's claims by looking over their shoulder as they use the system. I immediately thought of the ASP.NET WebForms trace system as a source of tracing information and a convenient mechanism to display it, but I don't know of an equivalent in ASP.NET MVC.
Are there any built-in mechanisms to expose this information to me whilst debugging with a tester?
Options
Glimpse- like webform inpage trage/trace.axd on steroids. Works nice for MVC apps, has little to offer webforms though (the team has been promising big things though, it's an area to watch).
trace.axd - Trace.Write output should appear here, I've never tried to run it on a busy server. Access to trace.axd should work for an mcv app, not sure if inpage trace works for mvc-- I would guess not but I have never tried.
<% "Some trace" %> -- I sometimes dump diagnostics to all screens and put it in the footer, or put it in the footer then make the text white on white, so I can instruct the user on how see it and copy it, but they won't normally see it.
System.Diagnostics TraceSource and associated classes -- It's better than Trace.Write but has some flaws if you use trace a lot. Still, there are scenarios when you can't assume your favorite trace/logging library will be available. If I were to use this, I'd write a custom listener and write to your user's diagnostic data to the database, or a file, listeners already exist for files.
Log4Net -- a trace/logging framework. Supports writing to a variety of places-- console, database, file, etc. Has fewer design flaws that System.Diagnostics, but requires adding noe more dependency to your app. Use same as System.Diagnostics -- log to a file or database and inspect your users STS values there.
I've never had the good fortune of using WIF or STS, but I imagine that pretty printing an object and it's properties is the same for much any object. You may want to post a WIF/STS question separately if you need to know how to extract a particular piece of info from it.
Well - Trace.Write data shows up in the output window in VS while debugging. Maybe thats good enough. You can also add a trace listener for the System.IdentityModel trace source to get more insight into the token/claims processing.
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.
I am involved in designing a asp.net webforms application using .NET 3.5. I have a requirement where we need to log exceptions.
What is the best approach for exception handling, given that there would be concurrent users for this application?
Is there a need or possibility to log in exceptions at a user level? My support team in-charge wants to have a feature where the support team can get user specific log files.
To give you a background, this application is currently on VB 6.0 and we are migrating it along with some enhancements. So, today the support personnel have a provision to get user specific log files.
My vote is for ELMAH. It is the easiest to set up and automagically lets you find bugs that never get reported back from the end-user.
While this is a bit self promotion, CuttingEdge.Logging allows native support for logging the user name in who's context a log event occured. When you configure the AspNetSqlLoggingProvider with the userNameRetrievalType set to "Membership", it allows retrieving the user name from from the HttpContext.
The AspNetSqlLoggingProvider logs to a database. The framework does not contain any tools for analyzing logs. When you want this, you can take a look at ELMAH, and I believe there are tools (both open source and commercially) available for log4net.
Good luck.
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.