Menu
Application_Start event is fired only at the time of first time call to any page in Web-Application. Once this event is called, it will not be called till the time either virtual directory's structure drastically changed or your production server is Stopped/Restarted.
When an MVC application first starts, the Application_Start() method is called. This method, in turn, calls the RegisterRoutes() method. The RegisterRoutes() method creates the route table. The default route table contains a single route (named Default).
Application_Start. Called when the first resource (such as a page) in an ASP.NET application is requested. The Application_Start method is called only one time during the life cycle of an application. You can use this method to perform startup tasks such as loading data into the cache and initializing static values.
Application_Start. The Application_Start event is fired the first time when an application starts. Session_Start. The Session_Start event is fired the first time when a user's session is started. This typically contains for session initialization logic code.
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)
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):
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)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With