Application_Start and Application_End are called only once during the lifetime of the application domain – thus they aren’t called for each HttpApplication instance
Application_Start runs when first user requests a page, thus when the first instance of the HttpApplication class is created, while Application_End runs when the last instance of an HttpApplication class is destroyed.
But what if at the time of application domain being restarted there wasn’t any user requests and thus no HttpApplication instances created? Will in that case Application_End still be fired?
Thank you
If I understand your question correctly, you're saying that no requests ever came, if no requests ever come in the application will never be started (i.e. no Application_Start is fired) and therefore no the Application_end wouldn't fire either.
This is not withstanding any kind of "pre-warming" code which fires up the application before requests are received in order to load up caches or things like that.
Related
Actually I am new to ASP.NET and I came through these concepts.
What is the difference between Application_Start Vs Session_Start?
And also how to know how many users are currently active in our application? Is by using Application_Start or by using Session_Start?
Application_Start executes just once when the application/worker process starts or IIS restarts. You can instantiate application variables, for example.
Session_start executes each time a Session is created, such as to instantiate and manage visitor data.
Application_Start Method is Fired on When the Application Started
Application_Start runs once before Files are Processed
Where
Session_Start Method is Fired at the beginning of each session.
Session_Start runs at the starts of each unique user session.
I'm having a Web application that also integrates a Web API. Just today I've found myself surprised to see that the first REST request on the Web API re-triggers the execution of Application_Start (although it has been run already when starting the web page). After reading ASP.NET HttpApplication lifecycle and ASP.NET Application Life Cycle Overview, it seems that the REST request is spawning a new HttpApplication.
Further, on the MSDN it says:
The first time that an ASP.NET page or process is requested in an application, a new instance of the HttpApplication class is created. However, to maximize performance, HttpApplication instances might be reused for multiple requests.
This sounds to me that each request could potentially spawn a new HttpApplication and that thus, Application_Start must be written in a re-entrant or idempotent way. Is this conclusion right?
In my concrete case, I'm initializing a log writer in Application_Start which fails the second time because the file is already being used. I guess in the case of an application pool recycling this wouldn't be a problem, as the resources are freed in-between.
You can read further down on the provided link
The Application_Start and Application_End methods are special methods that do not represent HttpApplication events. ASP.NET calls them once for the lifetime of the application domain, not for each HttpApplication instance.
So there is no need to write Application_Start in a re-entrant or idempotent way.
Furthermore Application_Start is not called on the recycling of IIS. It gets called on the first request after recycling when the application is actually loaded by IIS.
As for your error, make sure you're disposing off your logger on Application_End so the file handle gets released.
Having a read of the application lifecycle in IIS 7.0, on msdn and confused by the following line about halfway down , "The first time that an ASP.NET page or process is requested in an application, a new instance of the HttpApplication class is created. However, to maximize performance, HttpApplication instances might be reused for multiple requests.". That would suggest that discounting performance, the majority of the time a new instance of the HttpApplication class is created per request.
If that is correct, that would mean Application_Start firing on each request. I only ever thought it fired once when the appdomain is started
Web application initialization is as follows:
As we know when IIS receives the first request for a particular Asp.net application resource, IIS creates an instance of a HttpApplication (defined in global.asax codebehind).
When this new instance is created it's initialization happens that also checks all configured HTTP modules.
All modules are then instantiated and put in the application's Modules collection (of type HttpModuleCollection)
modules are looped through and their Init() method is called (when they register for request events)
As far as I understand it the above scenario happens when a web application is started/initialized (hence application start event).
What happens with modules?
Are they (re)instatiated on each request or reused from the Modules property on each consecutive request while the web application is alive? As I understand IIS and Asp.net they are reused through the whole life of a web application.
If they are reused, can we assume that their Init() method is actually a pseudo event handler for application start event? The thing is we can't attach to application level events within http modules. But if they are being reused we could use Init() as application start event and do whatever we'd put in global.asax instead.
Question
Can we assume that module's Init() method is called only on application start event? Could we use this assumption to i.e. register routes for applications whose global.asax codebehind we can't change? web.config is usually accessible and we can change it the way we want.
Would this actually work?
Additional info
We can check HttpApplication code and check its InitModulesCommon() method. This one actually calls Init() of each registered HTTP module. What is more interesting is that this method is only used by InitIntegratedModules() and InitModules() methods. Which are both used only in HttpApplication.InitInternal() method. This is the basis of my assumptions, but I would like to know whether someone has abused IHttpModule.Init() for application start event.
Init() is called only once (per HttpApplication instance)
After I tested this the inner workings of IHttpModule initialization are as follows:
Every IHttpModule is initialized at web application start by instatiating and a call to Init() method
HttpApplication stores all module instances in its Modules property
Modules are then reused for the whole life of an HttpApplication and are not discarded/reinitialized as long as the application is alive
So the best outcome is
You can't attach an IHttpModule to application level events, but you can use its Init() method as pseudo application start event delegate. Inside it you can execute any code that you'd usually put inside Application_Start delegate in your Global.asax.
You can also read detailed information about it in my blog post.
But be careful in real-life web server environment
But IIS uses something called application pools. And each pool can have an arbitrary number of HttpApplication instances. Yes multiple. Application starting creates all these instances. Every one of them initializes their own list of modules but only the first one executes the Application_OnStart event handler.
So whenever your module modifies some common shared resource, you should take extra measures to indicate that the first module has done that and others won't do it again. Read an additional blog post about it that will show you how and when to use thread locking with your module to make it actually act as an Application_OnStart event handler. BTW: It's also possible to handle Application_OnEnd event if you need to. ;)
Detailed blog post links
Writing a custom IHttpModule that handles Application_OnStart event
How to correctly use IHttpModule to handle Application_OnStart event
Application_Start is only run once for the lifetime of your application.
IHttpModule.Init is run for each instance of HttpApplication, before request processing begins. See the walkthrough. Init is where you can register events used to process the request.
An instance of HttpApplication can be reused for multiple requests. ASP.Net pools HttpApplication objects, so the Init will be called once for every new instance of HttpApplication
When to use and not to use global.asax file in asp.net application? I heard that you should use that file only at a pinch.
The Global.asax file is used to implement application and session level events, such as:
Application_Init - fired when an application first initializes
Application_Start - fired when the application first starts
Application_End - the final event fired when the application ends or times out
Session_Start - fired the first time a user’s session is started
Application_BeginRequest - fired with each new request
Application_EndRequest - fired when the application ends
Application_AuthenticateRequest - the event indicates that a request is ready to be authenticated.
Application_Error - fired when an unhandled error occurs within the application
Session_End - fired whenever a single user Session ends or times out.
Implementing these handlers can all be legitimate uses of the global.asax. For example, the Application_Error event handler typically logs any global errors, and the Application_End event handler typically contains application cleanup logic. These are good uses of the Global.asax. Use them whenever necessary, and don't be afraid if the file grows.
However, I have seen cases where developers have added all sorts of global methods to the global.asax that are indeed un-justified. For example, keep business logic related to a particular domain object inside the object itself rather than in the global.asax. If you find methods in the Global.asax that shouldn't be there refactor the work into the right location.
global.asax is a HTTPModule. All requests go through the global.asax and other modules before they reach your page handlers. Use this to perform certain tasks on your request or response, like url routing, global error handlign etc.
If you need something special to happen on Application start/end or Session start/end, or globally handle exceptions you could use it to map the events in the Apllication and Session life cycles.