I've recently joined an asp.net mvc project well under way where there isnt much consistency in dealing with exceptions in the controller; some devs return data to the client to let the user know whats wrong, others throw them back so they get to the server-level handler that processes and logs them - without letting the user know whats up.
It seems obvious to me that both approaches are wrong on their own, and need to complement each other instead; what I'm stuck at, is how to do that. I assume the eventual exception handler / logger could redirect the user to an error webpage upon catching something particularly nasty, but that limits the mechanism to just severe stuff.
I'm kind of looking for a way to do both "throw" and "return ..." at a time when I catch an exception, so I get it sorted and logged server side and get data client side that lets me tell the user there's been a hiccup.
My expertise with asp.net is very limited, and while I believe I understand mvc enough for it to not be an issue, this is kind of a "what is the best practice?" question from someone working with people who dont bother with best practices much.
There is a good project called Elmah for logging errors and exceptions in ASP.NET applications. You can find it here
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.
Once ELMAH has been dropped into a running web application and
configured appropriately, you get the following facilities without
changing a single line of your code:
Logging of nearly all unhandled exceptions.
A web page to remotely
view the entire log of recoded exceptions.
A web page to remotely view
the full details of any one logged exception, including colored stack
traces.
In many cases, you can review the original yellow screen of
death that ASP.NET generated for a given exception, even with
customErrors mode turned off.
An e-mail notification of each error at
the time it occurs.
An RSS feed of the last 15 errors from the log.
The MVC application that I am working on implements the Application_Error in the Global.asax to handle exceptions thrown from the application and then redirects the user to a standard error page. The Controller for the error page handles the logging as well as displays just enough information about the error to allow a support person to find their session in the system and help resolve any issues.
Related
I'm having a strange problem in a Silverlight Business Application that calls an external API. I'm sure it's just one line wrong or something. The API has one call that uses digest authentication and I handle that all myself. My code was working before, but then I began a transition to hosting the backend API and this front-end website on Azure and something must have changed. Now, before the request comes back to my code to handle, the browser is popping up a login dialog of its own. If I cancel out of that dialog, it moves on to my code and authenticates successfully.
It seems as if the browser is handling the request, noticing the 401 status code, and attempting to resolve it itself. But I do register the ClientHttp factory for the http:// prefix as suggested, and the request type that is created is a ClientHttpWebRequest. Like I said, this was all working about a week ago using the same authentication code and everything, so I'm sure it's just going to be some setting. But I'm not sure where that could be and I haven't found anyone else with this problem.
Curiously, when I publish the ASP project to an Azure website, it all looks and acts as expected, but the login doesn't even pop up the dialog. It simply doesn't do anything when I click "login." So that part looks like maybe an unhandled exception is being thrown then it's not telling me about it, but I'm not sure why that would be the case on Azure but not IIS Express.
Basically, I just don't want that dialog coming up. I am inclined to assume that the same problem that's causing that is whatever is making the Azure-hosted version not do anything.
I've done a fair bit of searching and found this question, "How can I supress the browser's authentication dialog?" which seems to be the same issue, but as I stated a few times, this was working just last week. I do have full control of the API and this site, so I could alter some things to make it suppress HTTP statuses and simply return a 200 with details in the content as a substitute, but I'd rather avoid that extra layer of complexity if it really is something simple, as I imagine it is.
After some fiddling, it seems the best way to handle this error is simply to use the WebRequest.Credentials property and populate it, rather than forming my Digest authorization header myself. It isn't exactly what I was going for, but it will do for now. I still don't know why this stopped working in the first place. But what fun is programming if everything goes according to plan?
Once one has a logging and tracing setup using log4net in place for ASP.NET Web API, what are the specific aspects that need to be logged and/or traced?
I am asking this specifically from Web API perspective. Is there a series of MUST Log this or MUST trace this.
Like, INFO traces about a controller's request, any NULL checks, etc.
Is there a reference list that can be validated against to ensure optimum logging and tracing coverage in ASP.NET Web API ?
So I will assume your goal for the logging is, as it should be, to debug the application rather than measure for performance.
While I think there is no one 'right' answer to this, at the minimum I would always try to log
Timestamps, class/function names and thread name (if yr running a multithreaded app) in every log line
Quick log line # every entry point, along with the full contents of
the passed in request, preferably in a format that would make it
easier for you to reissue the same request from fiddler or a similar
tool (this can be done via a custom action filter - see how the
author uses these for performance monitoring a web api app here )
If you are doing any database queries as part of your action, log
the full query sql string if possible (once again to make it easier
to repeat during debugging) as well as at least the # of rows
returned
If you are doing any external service calls, log both the full
request and response strings
Use try/catch blocks to log any exceptions (you can also use
something like the ELMAH library to do this automatically rather
than handling in code - link here and here
Anything that is resolved during runtime - think values from config files, database queries, calculated values, should also be logged
I'm sure there is more missing from this list - after all this varies on what yr doing in the app. You should be asking yourself at every step of the way - what could go wrong in my application? What things would I or the poor chap that will work on this after me find useful whilst debugging a problem?
If you are hosting your webapi in IIS, you can enable IIS LOG and counters:
http://www.iis.net/configreference/system.applicationhost/sites/site/logfile
Performance Counters:
http://msdn.microsoft.com/en-us/library/fxk122b4%28v=VS.100%29.aspx
http://www.iis.net/learn/extensions/configuring-application-request-routing-(arr)/using-performance-counters
An additional category of items to log for a service code that implements authorization authentication and impersonation where elevated access is required. These should be configurable to log either success failure or both.
Hi I have recently uploaded my site on a deluxe shared hosting account (GD). Once in a while I get a plane page containing only the text "your request is timed out. please retry the request." I'm unable to figure out the cause. I'm using IE8 for testing. On server side, I have custom MVC like architecture and the errors are being handled globally. Whenever this error appears, it appear instantly when I try post back. Going back and retrying the same solves the issue. No app logging occurs as it doesn't seem to be issue with the code. Does somebody have an idea as to What's wrong here?
It looks like it could be an issue with having PHP enabled on your asp.net hosting package.
http://www.mynetnuke.com/2011/02/your-request-timed-out-please-retry.html
If that's not it, I would try to narrow it down via tracing.
Enable tracing for the page.
http://msdn.microsoft.com/en-us/library/94c55d08.aspx
Enable tracing for the application and access it via trace.axd (e.g., http://website.com/trace.axd)
http://msdn.microsoft.com/en-us/library/0x5wc973.aspx
Use Elmah to trace / gather more information
http://code.google.com/p/elmah/
If all else fails, contact GoDaddy support.
I believe this thread is your problem.
http://community.godaddy.com/groups/web-hosting/forum/topic/your-request-timed-out-please-retry-the-request/?topic_page=5&num=15
What is your best solution for pulling out an exception occurring on a user computer?
For example I send automatically a email when an exception is thrown which body contains the call stack.
Have you experience other quick way to handle user bug?
Unless this is a corporate app, be sure to ask the user if they want to submit anything first.
Then, generally I would recommend submitting it via web service. Better to leverage the end-user's existing proxy settings if any.
ELMAH is a good tool for logging exceptions in ASP.NET websites - it can log the exception to a local database as well as emailing it.
"Once ELMAH has been dropped into a
running web application and configured
appropriately, you get the following
facilities without changing a single
line of your code: Logging of nearly
all unhandled exceptions.
A web page to remotely view the entire log of recoded exceptions.
A web page to remotely view the full details of any one logged
exception.
In many cases, you can review the original yellow screen of death that
ASP.NET generated for a given
exception, even with customErrors
mode turned off.
An e-mail notification of each error at the time it occurs. An
RSS feed of the last 15 errors from
the log."
BugzScout with FogBugz worked wonders for me. An API to your bug database in general is the way to go.
With respect to emailing it, you can simulate some of the features of a bug tracking database but it's not as good as the real thing. If you keep with the email option, be sure to send them to a generic bugs#companyX.com email instead of a personal so they can be routed to a different person quickly if necessary.
Our client recently complains that when they work on our production server, the user menu switch randomly, but this happens only occasionally .
The application has two types of user menu: regular user and restricted user. The target browser is IE. It's a ASP.NET3.5 application written in C#.
We can never reproduce this issue in our local environment. So it is very difficult to debug it.
Anybody met this type of issue or any clue how to debug it?
Web App Logging
Have you looked into adding a variable to your web.config to have your application perfrom less or more logging. I've done this in the past to track down bugs.
Client-side Logging
Perhaps not the intended use, but http://www.clicktale.com/ provides a javascript site analytics tools that can record all user mouse/keyboard activity that you could correlate to the web app logs. However it cost $$$.
Log Messages. Log them all over that has anything to do with the menu. Then the next time the user reports seeing it look at the log message.
Does the production environment use any load balancing s/w? Perhaps there is a problem with some session scope variables.