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.
Related
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/
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 have already done a proof where I can include Node.JS within an ASP.NET MVC application.
Assume that I am going to use an external session provider like windows server appfabric Cache or memcache.
I have an application where there is a quite sophisticated assembly that we use to build middle tier objects that we then store in the session. The assembly and the objects it produces is our most valuable piece and I cannot justify rewriting this C# project into something this is more Node.JS friendly.
This data is stored in an external cache, and now the node.JS developers need access to that.
What techniques have you guys used in situations like this? I am pretty sure that I am going to have to have some sort of service interface provide by the asp.net side as it is the one that owns this system of record.
I am also looking for a green field option for new projects that allow both ASP.NET MVC and Node.Js work together well in a hybrid fashion anyway, so perhaps this could be solved by data being stored in a convention that works for both.
Thanks.
I wouldn't use ASP.NET session at all. Maybe a database would be a more interoperable approach. SQL Server or even NoSQL solution such as RavenDB might be a good choice.
The problem with ASP.NET out-of-proc session state providers is that they use non-interoperable serializers (such as BinaryFormatter or NetDataContractSerializer) so you cannot read the data back from NodeJs. There might even be differences in the serialization mechanism between the different versions of the .NET framework so even with 2 ASP.NET applications running on different versions of the framework it might be a challenge to share session data.
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.
I just switch my website over to MVC from Webforms and I am using ajax very heavily. MVC seems to be slower but I haven't set up anything to record benchmarks.
Does anyone know which is faster for ajax handling and why it's faster?
You shouldn't see any difference from one framework to the next. They are essentially the same with an exception of less things going on in the execution pipeline of the MVC framework, less stored (no state tracking), etc. How are you doing ajax in your site? Are you using partials? Full views? Rendering json or fully formatted html chunks?
A good tool to use for profiling is either Firebug in Firefox, or Fiddler for IE/Chrome.
AJAX is known for being very chatty with the web server without the users knowledge , whereas a Webform is very explicit in showing when it is posting data back to the server.
It could be psychological, but profile the HTTP connections yourself and see!