I am using ELMAH to log errors in my asp.net MVC(C#) application.
I am able to log errors in xml or database. How to log errors to the eventlog using ELMAH?
ELMAH does not include an event log option.
ELMAH error log classes are not write-only; they also read the log data so that it can be displayed in the ELMAH web interface. Additionally, ELMAH logs more than just exception information. It also logs server variables, the form collection, and the information necessary to reproduce the yellow screen of death. Even if you were to log all of this information to the event log it would be difficult to read as plain text, and very difficult to read back in such a way that the ELMAH web interface could use it. If you are not going to use the ELMAH web interface then clearly that is not an issue.
If you want to log basic exception data to the event log you can create your own error log by subclassing ErrorLog. ELMAH supports multiple error logs, so you could continue to log detailed data to XML or a database (to service the ELMAH web interface) and then log a subset of that data to the event log.
Out of the box, you can't. You'd have to write a custom handler.
You can do something like this.
Elmah.ErrorSignal.FromCurrentContext().Raise(new Exception("My Exception");
Related
There is a generic authentication error which does not seem to hit any debug points, and ALWAYS sends the user to "/home/error".
I've searched far and wide, web.config, routing, etc... and can find no trace of a default error handling sending users to /home/error
I would really like to handle my own exceptions with custom messages, and this is preventing that. Any idea where I can look to find some manner of default error handling?
I am running a Windows Service on a Windows Server 2003 R2. We are using Exchange Server to send out the emails.
I am using log4net.dll 1.2.11.0.
I have situation where log4net sometimes sends emails and sometimes don't eventhough no changes has been made to the set up.
All the other log4net logging works very fine. And as said sometimes the application sends out emails and some times it don't, having made no change to the application.
All my methods are in try-catch clauses, but I don't get any errors.
When I run the the Windows Service on my local machine, the log4net email always works, and as said on the remote server, sometimes the log4net email works, sometimes it don't, having made no changes to the setup.
I am using log4net.Internal.Debug and have a System.Diagnostics.TextWriterTraceListener file where stuff is written to.
Scanning thorugh this file I haven't noticed anything in particular, but I don't know what specific to look for.
Any ideas about what the problem is or what to do?
If the SMTP appender cannot send an email it would log an exception with this text: Error occurred while sending e-mail notification. This would be visible if internal debugging is enabled. Maybe you have filters or something like that configured that prevents log4net from sending an email.
You could download the source code of log4net and add extra logging to the SMTP appender to find out if the "SendMail" method of the appender gets called at all. If it does and no email and no error is shown, then we need to assume that the exchange server somehow swallows the emails. If the appender is not triggered, then you need to review your filter / buffer / threshold configuration.
Alternatively you could try to use the SmtpPickupDirAppender.
Due to ongoing issues with ASP.NET MVC 4 and WebAPI, see link:
MVC 4 Web API - CreateResponse(status, object) causes HTTP 500
I need to instrument the internal Web API pipeline and see what's going on.
How do I do this?
Thanks
Luke
**UPDATE **
I have an ITraceWriter now implemented and I can now see that there's an Exception property on the TraceRecord which I can dump or even break around, maybe.
Thanks, I think answers the question.
More info here:
http://www.asp.net/web-api/overview/testing-and-debugging/tracing-in-aspnet-web-api
you can enable all levels of tracing (from the basic, "info" tracing) for the entire stack.
If you use one of the popular libraries (i.e. nLog), you can easily write it all to file or event log if you wish.
just replace the default ITraceWriter with your custom class:
GlobalConfiguration.Configuration.Services.Replace(typeof(ITraceWriter), new NLogger());
You'll see all kinds of internal tracing messages filling up the logs.
I blogged about that here http://www.strathweb.com/2012/06/using-nlog-to-provide-custom-tracing-for-your-asp-net-web-api/
Have you tried setting:
GlobalConfiguration.Configuration.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;
This is good post on Error Handling and tracing in Web API.
Which is the best way to handle a system error in ASP.NET MVC? I've watched a video on DimeCast.net in which the guy used the global.ascx file to write a method Application_Error to handle the errors. But currently, I'm handling my errors inside the web.config file.
Could someone point me in the right direction on how to properly handle errors? This could be:
syntax error
exceptions
404 and other page/file not found errors
The application is fairly large.
Take a look at elmah for logging of unhandled exceptions, there's actually a quick example on nuget demo video
I use combination of elmah for unhandled exceptions, and nLog to log ones that I can handle but still want to log. Thus far the combination has worked out very well.
Very likely you are going to need a combination of approaches. Some errors can be handled directly in your models, others in your controllers, and some others might need to be handled all the way to the application level (either via web.config or via the global.ascx.)
I prefer to handle the errors in the global.ascx rather than via redirection in web.config because in the global.ascx I have more information about the request that caused the error where as if I do a redirect via the web.config settings some of that information is lost by the time my error page receives the request.
A few weeks ago I just noticed that 404 errors are better not handled via the web.config because that (by design) causes an HTTP redirect code 302 rather than a true HTTP 404 code that indicates the client that the resource does not exist. I have a post on my blog where I cover this in detail http://hectorcorrea.com/Blog/Returning-HTTP-404-in-ASP.NET-MVC
Using ELMAH as Brook suggested is also a very good idea.
Error: Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.
Details: Error parsing near '
http://servername/ScriptResource.axd?d=EltQ7pexCbRndWc7D3a....b2a49de
Line: 5
I recently converted a SmartPart + UserControl web part to a 'real' web part. The user control part remained essentially unchanged and contains an UpdatePanel. The aim is to have an interactive calendar control which updates its own data but does not cause a full page refresh. The main reason for converting to a real web part is to make use of personal storage so that users can choose a particular setting and store it.
The problem I now have is that when one of the LinkButtons in my web part are clicked I get the error listed above. I am not doing any Response.Writes and there don't seem to be any HttpHeader entries in IIS.
Can anyone help here? Thanks.
New clue
Just noticed that the postback events work when the page is checked out but not when it has been published. What is the significance of this?
Have you added the sharepoint script manager:
http://msdn.microsoft.com/en-us/library/ff650218.aspx
It sounds like a HttpModule is altering the json postback of the update panel