I have a class called Global that derives from HttpApplication.
Oddly, I see a lot of methods inside Global that look like:
void Application_Start(object sender, EventArgs e)
{
}
The code is definitely executing inside this method, so the method is being called from somewhere, but where? The methods aren't marked overload?
Secondly, I derived a class from Global, let's call it GlobalFoo.
Again, if I create a method called Application_Start() it will get called inside my derived class, otherwise nothing that's in Global will get called so I might as well be deriving from an empty class.
Can anyone offer any advice? Am I missing some fundamental part of ASP.NET?
so the method is being called from somewhere, but where?
This functions are called from the Application Pool (from each pool that you have assign), to signal start-up/end events of your application and help your with initializations.
Every pool that is assign to run your web application runs those functions.
asp.net is helping you create different objects/code external or not that can run together, and that's why you see that all of your registered code run. Its a help to create more than one "start up" routines that do different thinks.
This is an example, this module just check the secure protocol by him self... and you do not need to change anything on your code, just register it.
IIS calls the different Global.asax events through the asp.net isapi filter.
Perhaps this article will help explain.
The Global.asax file is an optional file used to declare and handle application and session-level events and objects for an ASP.NET web site running on an IIS Web Server
some of the key events in this file are:
Application_Init: Fires when the application initializes for the first time.
Application_Start: Fires the first time an application starts.
Session_Start: Fires the first time when a user’s session is started.
Application_BeginRequest: Fires each time a new request comes in.
Application_EndRequest: Fires when the application terminates.
Application_AuthenticateRequest: Indicates that a request is ready to be authenticated.
Application_Error: Fires when an unhandled error occurs within the application.
Session_End: Fires whenever a single user Session ends or times out.
Application_End: Fires when the application ends or times out (Typically used for application cleanup logic).
For a complete list of Global.asax events see "Global.asax Events".
Related
I'm working on an application and i want to understand it's behavior.
Once i have already logged into the system i make one request through ajax to the back-end, it's a void method that will process some information and feed a table.
Meanwhile i have another tab, also in the same session as the one that called the void method, and i want to go to the system's dashboard, so i press the corresponding button in the menu. This second tab will ONLY go to the dashboard when the void method is done.
Why? I would need static webservices to do that for me? I assumed that once it's a void method and i don't need its answer that would work.
You need to provide more details about the state of the application during the execution and the conditions around your requests.
If you're using AJAX to call the backend method and it doesn't return anything, your second request in the other tab should process normally. Web Applications are usually capable of handling multiple requests almost simoultaneously (barring any DDoS attack or unusually high load limits reached), so one thing i would ask is ¿are you debugging the application while sending the second request?, if you have a breakpoint on the server method that's being called and it's being hit by your first request, you need to step out of that execution manually before you can process the next request.
Another thing you might want to review is, if this method is a very resource/time-consuming operation, you might want to use tasks or threads to avoid creating bottlenecks between requests.
I want an event which gets fired only once when my website launches for the first time...
Actually the situation is, I am creating an e-commerce website in asp.net, and i have created a cart table for storing the orders of clients.
So i want to empty that table the first time the website launches, so the next user does not see the orders of the previous user...
I tried the application_start and session_start event but both are being fired every time when any new page is opened... I don't want to fire that event for every page.
I am a beginner in asp.net.. any help would be appreciated..
Thanks in advance friends..
I think you are getting a bit confused here...
"So i want to empty that table the first time the website launches, so the next user does not see the orders of the previous user."
Application_Start should only fire when the site is first visited, it will not fire again for another user unless it is in a stopped state when they visit it.
If you are creating the table data in memory, then it will be new for every user, no need for Application_Start.
You could store the userid / session id in the cart table to, then only retrieve the basket for the correct user whenever they visit your site, or even better store them in a cookie so they can revisit your site before cookie expiration and still have their cart.
If Application_Start is firing everytime you visit a page then your IIS settings are a bit suspect.
Use the following function in the global.asax file...
void Application_Start(object sender, EventArgs e)
{
// Code that runs on application startup
}
Taken from MSDN...
"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."
Events of the global.asax file are what you are looking for. Perhaps this techrepublic post could provide you some guidance on using the Application_Init and Application_Start events.
Hope I helped!
I've written an HttpModule that is an NHibernate Session Provider. It simply opens a SessionFactory in Init method of HttpModule and gets a new Session in BeginRequest and closes it in EndRequest. At the other side, I wrote a method in Global.asax that uses a session from this HttpModule named GetData. I run that method (GetData) in Init method of Global.asax. The problem is when I use my HttpModule in integrated mode it seems that my HttpModule does not Initialize before running Init method of Global.asax.
I've searched for order of running these methods and life cycle of events but nothing useful found!
In IIS 7.x, modules and handlers should be registered within system.webServer xml element in your web.config file.
Check this MSDN article:
http://msdn.microsoft.com/en-us/library/ms227673.aspx
ASP.NET does not provide any guarantees on when HttpModule Init() methods are called with respect to one another (not unlike static initializers). In general, the Init() methods should be used to wire up event handlers, and any "real work" should be done in the event handlers.
All registered event handlers for a specific event are called from all HttpModules, including Global.asax, before moving on to the next event -- so you have control over order that way.
I've the following doubt. I've a page "MyPage" and i've declared few dictionary objects in the page class.
My doubt is
If i declare the dictionary as a private non-static object i'm not able to use it across the functions in that page class (the object is getting nulled)
But if i declare the dictionary to be static i'm able to across the object across the functions. But will that object be same across all the users who have opened the page right now (guessing that each user will have an instance of the page in turn has an instance for the page class and static variables of a class are invariable across all the instances of the class)
Is my understanding right? How to declare the object to be available across all the functions within the page class and unique for each instance of the page (user).
Update1
Okie, i find that the initialization of the dictionary object in the page class is done in a different thread (WCF Duplex callback). But in the main page thread the dictionary object is still remaining as null (uninitialized). Any ideas?
Update2
Marshalling - useful by any chance?
Update3
In reply to John-
Thanks for your reply. The problem i'm facing now is to pass the data from the WCF callback class at the client side(which will be invoked in a separate thread) to the asp.net page. So how can i do that? View state may help me to persist the data across requests. But when the callback is invoked by the server notifying for a change how should i pass the changes (data) to the UI thread (asp.net page)?
Don't do things like this.
If you need to maintain data between pages, use Session state. That's what it's for. You should remember that you get a new instance of your page class on every request. Do not use statics to keep changing data around for subsequent requests. You will probably get into trouble with multiple requests updating the data at the same time.
You can't do things like this with ASP.NET!
You seem to be treating this as though it were a desktop program - as though your class instance and all state will still be there for you next time you execute a method on the page. That's not true - when the request is complete, your page will be Disposed. Nothing about the page will remain valid.
In particular, if the callback doesn't happen before the request ends, then the callback method had better not reference anything having to do with the request, like your page. That's because the callback might fire after the request is already over! The state is corrupt or worse.
Unless you are going to have the page wait for the callback, you'd really better not use them in your pages. Instead, create a separate Windows Service or something and have it issue the requests and await the callback. The page can then use Ajax or something to ask if the request is complete, and to get the response once complete.
If you think you heard me say to call back to an ASP.NET page, then you misunderstood.
Create a Windows Service. Your Windows Service will host a WCF service that the ASP.NET application will talk to. The WCF Service will keep track of things like who's joined a chat, who's typing, etc.
The web application cannot be notified when something interesting happens. Instead, the web application will have to poll the WCF service, asking if anything interesting has happened. When something happens, the WCF service will pass the "something" back to the ASP.NET application (or possibly, back to the page, called by AJAX).
I misspoke earlier. You simply cannot use a callback contract at all in this situation. It's not like the web pages are like a desktop application, one per user, waiting to be notified. They're more like a desktop application where, when the user makes a request, you take his PC and give him a new one just like it, before the response arrives.
You are right in the second case. In your first case I'm guessing you mean that if a user clicks multiple controls on your page then the event handlers are seeing that the dictionary is null (instead of having the result from the previous event handler).
Remember that every request on a page (even from the same user) creates a new instance of your page class. That means that each time a request starts, your dictionary will be null. The only way for a variable to maintain its value between subsequent requests is to persist it server-side (for example, in user-specific session information on the server) or to push it to the client with the page content so that it can be part of the subsequent request data (so it's stored in ViewState or other storage at the client's browser between requests).
Rereading this question, there are three seperate state machines, and none of them are being coupled together - hence the problem :)
State of the "user state" - these are the key/value pairs in the dictionary, their lifetime spans multiple page requests and callbacks
State of a "page", which needs to consume the data from "user state". Pages are destroyed after each and every page request.
State of the "service call" which needs to populate the data in "user state" Service calls are generally destroyed after each invocation.
There are a few strategies that could enable you to couple the systems:
ViewState such that the state machine for "user state" is sent down as part of the state of the page, and sent back on postbacks. This may constrain how you perform service callbacks
Session such that the state machine for "user state" is stored server side, and can be accessed by key.
Static dictionary of user states, where the key for the outer dictionary would be the identity of the "user state", where the 1st page request would create the "user state" entry, and you'd need to manage teardown. (v.similar to session - though works without ASP.NET).
There are lots of nuances to each solution - I'd advise light reading :)
you are right that a static member will be the same for all instances of the page, and thus all individual users. You need to make it a non-static member if you want to access it from every method in the class. You should look into why the object is null. Are you properly instantiating it at the proper time?
How can we use global.asax in asp.net? And what is that?
MSDN has an outline of the purpose of the global.asax file.
Effectively, global.asax allows you to write code that runs in response to "system level" events, such as the application starting, a session ending, an application error occuring, without having to try and shoe-horn that code into each and every page of your site.
You can use it by by choosing Add > New Item > Global Application Class in Visual Studio. Once you've added the file, you can add code under any of the events that are listed (and created by default, at least in Visual Studio 2008):
Application_Start
Application_End
Session_Start
Session_End
Application_BeginRequest
Application_AuthenticateRequest
Application_Error
There are other events that you can also hook into, such as "LogRequest".
Global asax events explained
Application_Init: Fired when an application initializes or is first called. It's invoked for all HttpApplication object instances.
Application_Disposed: Fired just before an application is destroyed. This is the ideal location for cleaning up previously used resources.
Application_Error: Fired when an unhandled exception is encountered within the application.
Application_Start: Fired when the first instance of the HttpApplication class is created. It allows you to create objects that are accessible by all HttpApplication instances.
Application_End: Fired when the last instance of an HttpApplication class is destroyed. It's fired only once during an application's lifetime.
Application_BeginRequest: Fired when an application request is received. It's the first event fired for a request, which is often a page request (URL) that a user enters.
Application_EndRequest: The last event fired for an application request.
Application_PreRequestHandlerExecute: Fired before the ASP.NET page framework begins executing an event handler like a page or Web service.
Application_PostRequestHandlerExecute: Fired when the ASP.NET page framework is finished executing an event handler.
Applcation_PreSendRequestHeaders: Fired before the ASP.NET page framework sends HTTP headers to a requesting client (browser).
Application_PreSendContent: Fired before the ASP.NET page framework sends content to a requesting client (browser).
Application_AcquireRequestState: Fired when the ASP.NET page framework gets the current state (Session state) related to the current request.
Application_ReleaseRequestState: Fired when the ASP.NET page framework completes execution of all event handlers. This results in all state modules to save their current state data.
Application_ResolveRequestCache: Fired when the ASP.NET page framework completes an authorization request. It allows caching modules to serve the request from the cache, thus bypassing handler execution.
Application_UpdateRequestCache: Fired when the ASP.NET page framework completes handler execution to allow caching modules to store responses to be used to handle subsequent requests.
Application_AuthenticateRequest: Fired when the security module has established the current user's identity as valid. At this point, the user's credentials have been validated.
Application_AuthorizeRequest: Fired when the security module has verified that a user can access resources.
Session_Start: Fired when a new user visits the application Web site.
Session_End: Fired when a user's session times out, ends, or they leave the application Web site.
The Global.asax file, also known as
the ASP.NET application file, is an
optional file that contains code for
responding to application-level and
session-level events raised by ASP.NET
or by HTTP modules.
http://msdn.microsoft.com/en-us/library/2027ewzw.aspx
Global.asax is the asp.net application file.
It is an optional file that handles events raised by ASP.NET or by HttpModules. Mostly used for application and session start/end events and for global error handling.
When used, it should be in the root of the website.
The root directory of a web application has a special significance and certain content can be present on in that folder.
It can have a special file called as “Global.asax”. ASP.Net framework uses the content in the global.asax and creates a
class at runtime which is inherited from HttpApplication.
During the lifetime of an application, ASP.NET maintains a pool of Global.asax derived HttpApplication instances. When
an application receives an http request, the ASP.Net page framework assigns one of these instances to process that
request. That instance is responsible for managing the entire lifetime of the request it is assigned to and the instance
can only be reused after the request has been completed when it is returned to the pool.
The instance members in Global.asax cannot be used for sharing data across requests but static member can be.
Global.asax can contain the event handlers of HttpApplication object and some other important methods which
would execute at various points in a web application
The Global.asax can be used to handle events arising from the application. This link provides a good explanation: http://aspalliance.com/1114