Application_Start not firing?

I have an ASP.NET MVC (beta) application that I'm working on, and am having trouble figuring out if I'm doing something wrong, or if my Application_Start method in Global.asax.cs is in fact not firing when I try to debug the application.

I put a breakpoint on a line in my Application_Start method, and am expecting that when I attempt to debug the application that the breakpoint should get hit... but it never does. Not after I reset IIS, not after I reboot, not ever. Am I missing something? Why is this method never getting called?

Note : a nice easy alternative to using the inbuilt "Visual Studio Development Server" or IIS Express (e.g. because you are developing against IIS and have particular settings you need for proper functioning of your app) is to simply stay running run in IIS (I use the Custom Web Server + hosts file entry + IIS binding to same domain)

1. wait for debugging session to fire up ok
2. then just make a whitespace edit to the root web.config and save the file
3. refresh your page (Ctrl + F5)

Your breakpoint should be hit nicely, and you can continue to debug in your natural IIS habitat. Great !

If this is in IIS, the app can get started before the debugger has attached. If so, I am not sure if you can thread sleep long enough to get attached.

In Visual Studio, you can attach the debugger to a process. You do this by clicking Debug >> Attach to process. Attach to the browser and then hit your application. To be safe, then restart IIS and hit the site. I am not 100% convinced this will solve the problem, but it will do much better than firing off a thread sleep in App_Start.

Another option is temporarily host in the built in web server until you finish debugging application start.

The following helps in any case (no matter if you're using IIS, Cassini or whatever):

1. Set your breakpoint in Application_Start
2. Start debugging (breakpoint most probably is not hit) -> a page is shown in the browser
3. Change web.config (e.g. enter a blank line) and save it
4. Reload the page in the browser -> breakpoint is hit!

Why does this work? When web.config is changed, the web server (IIS, Cassini, etc.) does a recycle, but in this case (for whatever reason), the process keeps the same, so you keep attached to it with the debugger (Visual Studio).

I'm too having problems with breakpoints in application_start with IIS a hosted app. A good workaround is using Debugger.Break(); in code instead of the VS breakpoint

I have just the same problem. I have made a lot of renaming in my solution. After it I got two not working web-applications and several another web-applications were all right. I got error that I have wrong routes. When I have tried to setup break point in Application_Start method, and then restart IIS, VS didn't break execution. With workable web-applications break was working. Then I have recalled that "clean solution" and "rebuild" doesn't delete assemblies that left after renaming. And that was solution! I have manually cleaned bin directories of my buggy-web-applications and then saw new error in Global.asax Inherits="" attribute was referenced old dll. I have changed it on new and break began to work. Suppose that, during renaming Global.asax wasn't updated, and IIS took old assembly (with wrong routes) to start application.

Had the same problem in a Project we had taken over after another vendor built it. The problem was that while there were a number of commands written by the previous vendor in Global.asax.cs, which might lead you to believe it was in use, it was actually being ignored entirely. Global.asax wasn't inheriting from it, and it's easy to never see this file if the .cs file is present - you have to right-click Global.asax and click View Markup to actually see it.

Global.asax:

<%@ Application Language="C#" %>

Needed to be changed to:

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

Where ProjectNamespace is whatever the namespace is of your Global.asax.cs class (usually the name of your Project).

In our case the file contained a bunch of inline code, some of which was copy-pasted from the .cs file, some not. We just dumped the inline code over to the .cs file and gradually merged our changes back in.

Try switching the managed pipeline mode for the app pool to "Classic" instead of "Integrated". That solved the problem for me. Looking into the reason now...

(Props for this answer belong to Flores (see his comment on his own answer), I just wanted to provide this as a separate answer to draw more attention to it)

Make sure that your global.asax in not under a subdirectory. It has to be placed at root level into your project.

We had a similar problem, where global.asax.cs was being ignored.

It turns out that the site was upgraded from a precompiled .NET 2 web site to a .NET 4.0 site. On the server, the PrecompiledApp.config file had not been deleted from the root folder. After deleting it, and recycling the IIS app pool and touching web.config to restart the application, code in Global.asax.cs started working fine.

I had a problem once where the Global.asax and Global.asax.cs were not actually copied to IIS folder by the deployment scripts... So it worked when debugging on the development server, but not under IIS.

A late entry...

To test whether or not the IIS Application gets started before the debugger has had enough time to attach just add this to the top or bottom of your GLOBAL.ASAX's Application_Start.

throw new ApplicationException("Yup, it fired");

I faced this problem when using a static page (e.g. index.html) as the start up page - Application-Start does not get called. I discovered that serving a static page does not actually start the application. Requesting an .aspx page does.

Make sure the namespaces in Global.asax and Global.asax.cs are same. If they are different it will not throw any error but will not hit the breakpoint also because it is not executing application_start at all.

When you say "debug", do you mean actually launching the application from Visual Studio's built-in webserver for debugging, or do you mean attaching to the process in IIS? If it's the former, you should hit Application_Start, but if it's the latter, it can be difficult to be on the process early enough to catch it.

Close Visual Studio and delete the bin and obj folders in your web project (or all projects in the solution).

Here are commands to delete these folders from all of your projects:

rm *\bin -r
rm *\obj -r

I had made some changes based on "Code Analysis on Build" from Visual Studio. Code Analysis suggested "CA1822 Mark members as static" for Application_Start() in Global.asax. I did that and ended up with this problem.

I suggest suppressing this Code Analysis message, and not alter the signature of methods/classes automatically created by platform used for bootstrapping the Application. The signature of the method Application_Start probably was non-static for a reason.

I reverted to this method-signature and Application_Start() was firing again:

    protected void Application_Start()
    { ... }

I think the application start event only gets fired when the first request is made, are you hitting your website (i.e. making a request)?

I had this issue in a .net 4 web forms vs2010 project and tried everything mentioned on this page. Ended up removing and adding global.asax actually resolved the issue for me.

I hade the same problem, couldn't catch Application_Start. And the reason was that it was not firing do to a missmatch in the markup file. The markup file Global.asax was inheriting another class...

Did you check the Project settings? I had this problem and I had the Start URL going to a different port than my server specific port. It took me too long to figure out...

After trying as many of the other answers as were applicable in my situation and having no luck with any of them, I went into the properties for the Web project (the server-side project for a Silverlight app using RIA Services), clicked on the "Web" tab and changed the selected Server from "Local IIS" to "IIS Express". (Note I'm using VS2013.) This solved the problem. Application_Start executes under "IIS Express" but not under "Local IIS". Interesting...

I was trying to step through code in RegisterRoutes() called from Application start and not hitting my breakpoint. I determined Application_Start was not getting called. I had to make a change to make a superficial change to App_start/RouteConfig.cs and save it before Application_Start would get called. I guess these files get cached somewhere and are not called unless a change is made.

My same issue has been resolved by Adding reference of System.Web.Routing assembly in project

If you are using the System.Diagnostics.Debugger.Break(); workaround (which I think is just fine for temporary use) and it's "just not working" on your Windows 8 Machine. The reason is a bug in Visual Studio's "Just in time debugging".

The fix is as follows is to fix the key for the "Visual Studio Just-In-Time Debugger"

Open regedit and go to HKEY_CLASSES_ROOT\AppID{E62A7A31-6025-408E-87F6-81AEB0DC9347} for the ‘AppIDFlags’ registry value, set the flag to 0x8

More info here: http://connect.microsoft.com/VisualStudio/feedback/details/770786/just-in-time-debugging-operation-attempted-is-not-supported

In my case, killing the built-in ASP.NET Development Server instance via the system tray resolved the issue.

Weird and crazy stuff... but debugging on a server machine and another user left IIS Express running on their session. I had to logoff that user to kill his running IIS Express processes. That seems to have fixed the problem!

Update

After spending more than 1 hour chasing what was causing the problem... here's the deal: I somewhat managed to type an s inside the <appSettings> section in Web.config. Visual Studio tried to warn me in the Error List window with a warning. I confess I rarely check warnings... should start checking it from now on. :D As soon as I removed the offending s the breakpoint got hit in Application_Start.

I had this problem when trying to initialize log4net. I decided to just make a static constructor for the Global.asax

static Global(){
//Do your initialization here statically
}

Problem mainly occurs when you try to relocate the Global.asax file to another solution directory. Relocate the Global.asax file again into the default location. It will work as expected.

None of the solutions described above worked for me. However reinstalling the package

Microsoft.CodeDom.Providers.DotNetCompilerPlatform 

using nuget gui is a (not too nice) walkaround