Why does not the Application_Start() event fire when I debug my ASP.NET MVC app?

I currently have the following routines in my Global.asax.cs file:

public static void RegisterRoutes(RouteCollection routes)
{
	routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
	routes.MapRoute(
		"Default",                                          
		"{controller}/{action}/{id}",                       
		new { controller = "Arrangement", action = "Index", id = "" }
	);
}

protected void Application_Start()
{
	RegisterRoutes(RouteTable.Routes);
	// Debugs the routes with Phil Haacks routing debugger (link below)
	RouteDebug.RouteDebugger.RewriteRoutesForTesting(RouteTable.Routes);
}

Routing debugger...

When I hit F5, the application fires up and unless I have a view named Index.aspx in the ~/Views/Home/ folder, I get the "View missing" error message, although I have re-defined the default route and removed the HomeController. I would expect to get the routing debugger, and if not that at least a request for ~/Views/Arrangement/Index.aspx.
A breakpoint on RegisterRoutes(Routetable.Routes); is never hit when debugging.

I have tried building, rebuilding, restarting VS, cleaning, rebuilding again etc, but nothing seems to work. Why doesn't the application run the current version of the code?

I found the following answer on forums.asp.net:

>Are you using IIS7 as the server or the built-in web server? I noticed when using IIS7 that if you start the debugger, let a page come up, then change Global.asax (the markup file, not code-behind) while the debugger is still running, then refresh the page, breakpoints in Application_Start will be hit. > >I think what's happening is that pressing "play", VS just fires up the process, then attaches to it, but by the time it attaches to it the start event has already run. By changing Global.asax, you cause the app to restart and since the debugger's already attached you can hit the breakpoint. Not a great solution, but it seems to work.

Thats's what was happening in my case.

Add a System.Diagnostics.Debugger.Break(); to Application_Start().
This will force a breakpoint.

This line should be commented out to avoid the breakpoint to happen and #ifdef debug to get sure never gets to production.

NOTE: this is a problem with IIS. Since I wrote this answer, things have changed, and you can avoid doing this by using other servers, like IIS Express.

The problem is Application_Start() triggers first then the debugger attaches.

So the goal is to do something that would cause Application_Start() to trigger again while its still running. For debugging purposes, just run the debugger like you normally do then edit (eg add a newline) and save the web.config file.

I believe you have to shutdown/stop the local debugging server in order for the Application_Start() event to fire again... you should be able to right click on it in the system tray and choose "Stop".

I hit with the same problem today and was using Local IIS.

I believe this arises because because of the way page is loaded. All you need to do is, put a breakpoint in Application_Start. Run the application(In my case, it took to Login Screen ) and then go to web.config. Edit it - by adding some spaces. and then refresh in Browser.that will hit the breakpoint on Application_Start.

I found the problem:

This MVC application was part of a larger solution, in which I had at one point set another project to build for an x86 environment (I'm running x64). When I did that, apparently all other projects - even those added later - were set not to build on Ctrl+Shift+B, and I suppose that's why the debugger didn't hit my breakpoint.

Solution:

Go into the solution build properties (right-click Solution, select properties, and select Build on the menu on the left), and put a check in the Build checkbox next to the project name in the list.

In my case the problem was between chair and keyboard - after renaming mvc project assembly, I forgot to update Global.asax to point to the correct class. So check the "Inherits" in Global.asax (in visual studio right-click on Global.asax -> View Markup)

<%@ Application Codebehind="Global.asax.cs" 
  Inherits="Monster.MgsMvc.Web.MvcApplication" 
  Language="C#" %>

if it really matches your Global.asax.cs class/namespace declaration

In my case was I using

Local IIS Web server in web project settings

and I change to Use Visual Studio Development Server, and this works.

Below technique worked for me:
Simple workaround is to touch global.asax after the debugger is attached in order to force an application recycle. Then during the next request, the break point that you set on Application_Start will be hit.

I found this here:
http://connect.microsoft.com/VisualStudio/feedback/details/634919/cannot-debug-application-start-event-in-global-asax

Maybe my solution will help someone:

1. Stop the debugger.
2. Update the RegisterRoutes code (example - add\remove int i = 1;).
3. Rebuild.
4. Place a break point in RegisterRoutes.

I've just had this problem and swapped from Local IIS to IIS Express in project properties -> web to sort it out

project -> property -> web

check "Native code".