I implemented Serilog for a ASP.NET MVC project which will be hosted in Azure and Serilog provides sinks to log to Azure storage.
I then wanted a better way to handle exceptions and ran into this very informative article on integrating ASP.NET MVC with Elmah - http://www.hanselman.com/blog/ELMAHErrorLoggingModulesAndHandlersForASPNETAndMVCToo.aspx
I like it that Elmah lets you view exceptions and has ways to notify admins when exceptions occur. Given that I already have Serilog, should I replace it with Elmah or use it in conjunction with it?
Elmah is only used to log unhandled exceptions. That is, exceptions that would otherwise result in a yellow screen of death. It has a very nice log viewer as well, but ultimately, it's only used for exception logging.
Serilog can do everything that Elmah can do, with the exception (no pun intended) of the built-in viewer. However, there are lots of ways to view your exceptions.
Serilog will also do tracing or "event logging", which Elmah won't do (by default, there are ways to use Elmah's infrastructure to do this).
Finally, you don't get the structure of Serilog's logging with Elmah. You just get flat logfiles.
You can use both if you want, but I'd rather just configure an Exception handler to log to Serilog.
FYI, Serilog can log to Elmah.
http://blog.elmah.io/logging-to-elmah-io-from-serilog/
There's a good blog entry on the Elmah website about the difference between Elmah and Log4net. Many of the same reasons apply with Serilog, although obviously there is also Serilog's structured logging which you wouldn't get with either of those.
http://blog.elmah.io/elmah-vs-log4net/
Also, despite the fact I've linked to elmah.io, don't be confused. There are two versions of Elmah. One of them is free (and open source), the other is not (although it is partially open source). Elmah.io is cloud based, and not free. Elmah is still open source and free.
http://code.google.com/p/elmah/
Related
Recently I faced this problem where an ASP.Net MVC website with Autofac as DI was working fine in my local IIS but when I published it in Azure, it was not getting redirected to the default controller, instead it was showing me the welcome page.
I did a lot of things to finally know what was the problem like checking the web.config file line by line.
Is there any easy mechanism to catch DI failures in production / published environment?
It is no easier mechanism for Autofac specifically, than what you would need to debug the rest of the application. Logging is the first tool you should implement. Given that this is a production environment, you probably already have some form of logging infrastructure in place.
Resolve failures in Autofac (e.g. when Autofac is unable to fulfill constructor parameter requirements) causes exceptions, which unless handled explicitly, can be handled and logged at the application level using the Application_Error event handler.
In case there are no exceptions, or exceptions are swallowed somewhere in the MVC stack, you could hook up to the container Scope and Resolve events and log the activity. That way you can get a picture of what Autofac is doing in the production environment. This SO question discusses both container events and component registration events.
The way to do this is by verifying if all root registrations can be created. You can create a unit test that loops over all registrations and try to resolve them one by one. Being able to do this is very important, since with DI the application code itself isn't responsible for maintaining the dependencies between implementations, and the compiler will therefore not be able to verify whether the dependency graph is correct. Although it is impossible for the compiler to verify the dependency graph, verifying the dependency graph is still possible and advisable, because not doing this will force you to click through the complete application and eventually leads to the situation you got yourself into.
Unfortunately, I found that this is actually very hard to do with Autofac. I pretty sure that this should be possible, but I never got this working. Some other DI containers make it considerably easier to verify the container's configuration and check for other common configuration mistakes.
I've got a project that I'm working on that's going to be running on a Web Farm, we are also planning to use Elmah as our exception handler, we had a few custom requirements that I'm not sure are technically possible.
We want each Server within the web farm to log to a local database (ie SqlLite, SqlCompact etc)
We want to have a 'monitoring' web site that would get the combination of the errors from ALL servers (they would obviously have access to eachother through network shares etc)
We would prefer to use as much of the built in Elmah error handling as possible, ie the Elmah.axd if possible.
I know it's certainly possible to do this using a combination of SqlExpress, Linked Databases and a distributed view. My knowledge of SqlLite & SqlCompact are a lot more limited though so I can't find any information on translating that knowledge across to those platforms.
Any ideas/help would be much appreciated.
Michael
Since ELMAH supports SQL Compact, data can be logged separately for each server, but as far as i know ELMAH uses one connection string, which means write is not a problem but reads are as the data is now scattered.
ELMAH codebase would require changes to achieve writing and reading from different databases. And then ELMAH can read from a central error repository.
Hi,
I am looking for a simple way to log exceptions to the database in my ASP.NET MVC application. I have looked at the "Exception Management Application Block" but I can´t find any simple and clear articels about how to handle this in ASP.NET MVC?
Maby I should just catch the exception as far up as possible and then log it to database but Im not sure how to do that in ASP.NET MVC. In WindowsForms there is diffrent events(like unexpectedException) to listen to where I can log, is there anything like that in ASP.NET MVC?
BestRegards
Edit1: I found a tool called elmah http://code.google.com/p/elmah/ but im not sure if this is a good solution and if it works well with ASP.NET MVC.
Then I also found this article http://www.davidjuth.com/asp-net-mvc-error-handler.aspx that looks easy and clear but I also do not know if this is the right way to go?
Use ELMAH, it is available on NuGet. It will log unhandled exceptions in a web app and provide an interface to view them. It can log to a variety of storage mechanisms including xml and sql databases, it can also email you errors. It is basically the solution for logging exceptions in ASP.Net applications (both WebForms and MVC).
If you are using ELMAH in an MVC app, there are some integration points that should be addressed. These can be handled pretty well in one shot by installing the ELMAH.Mvc package from NuGet.
I would suggest you have a look at NLog for logging exceptions: http://nlog-project.org - you can configure it to dump the exceptions into a database really easily.
As for MVC error logging - this question Error Handling in ASP.NET MVC has some really good solutions in it.
This might at first glance seem rather similar to this question, but in my case I have implemented standard AspNetSqlMembershipProvider based security in my MVC application.
When I deploy my application on localhost or a in-house staging server, everything works as expected - most of the HomeController and AccountController actions are visible to unauthenticated users and all others are protected (I use [Authorize] attribute for marking up classes and methods that need to be protected)
The problem is that when I deployed my application to the live hosting server, basically all the requests get redirected to the login page without any apparent reason.
I realize that I must be overlooking some simple but crucial bit of configuration, but since I am new to this whole .NET thing (never mind the ASP and MVC) I can not for the life of me figure out what's wrong or missing
If more information is required, please let me know and I will be glad to provide.
Edit: There are no <location> elements in the Web.config. Also, the differences in staging vs. live site Web.config are only in connection strings and Elmah logger configurations.
Also, the code that registers global filters is quite standard (I have not touched this):
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}
Maybe there is something in the server configuration that might cause the different behavior? Where should I look?
As it turned out, the issue was indeed a "trivial configuration problem", although it had nothing to do with asp.net or mvc as such.
In my hosting provider's control panel I simply had to grant Anonymous user permission to read files from the physical folder of the application.
Once this was done, the application code worked as expected.
It seems that since the anonymous (unauthenticated) user did not have read permissions to anything from the physical filesystem IIS interpreted this as 401 error and automatically redirected all the requests to the configured login method (which was set to "Forms"), resulting in this semingly weird error message.
Following code throws (handled) exceptions, it appears that MVC uses exceptions to test for control locations.
<% Html.RenderPartial("LogOnUserControl"); %>
Application works as expected, I can see that exception is thrown couple times trying different locations (Views, Shared). Same thing happens with other controls. Apparently MVC uses exceptions to probe different possible locations for the file.
IIRC using exceptions for flow control is evil, and is not cool.
So, am I doing something wrong, or MVC is cool no more?
Note: having IDE stop on all thrown exception makes debugging easier, and I normally leave it on. That's how I got to that exception from RenderPartial.
It is not true that MVC 2.0 uses exceptions for control flow.
However, System.Web.dll v2.0 (the core component of ASP.NET up to .NET 3.5) has some inefficient APIs for instantiating objects from virtual paths. MVC 2.0 mitigates this problem by having a cache of view lookups. By default this cache is disabled during development so that the changes you make are immediately visible, which is why you are seeing these exceptions. On a real production server these exceptions would not occur after the lookups are cached.
As a side note, MVC 3 will be using new APIs added in .NET 4 so this should not be a problem anymore.
When running in Release mode view locations are cached.