Asp.net applications built with any other .Net compatible language are hosted by the Internet Information Server (IIS), which accepts client (HTTP) requests (a "call" for an .aspx page from your Web Browser) and passes the requests on to the Web application. The Asp.Net runtime engine delegates those requests to a wide variety of handler classes (in a separate process from IIS). In most cases, read: when an .aspx page is requested from a Web server, IIS "redirects" requests to the aspnet_isapi.dll ISAPI application - which in turn hands the request off to the aspnet_wp.exe worker process. This worker process handles the rest of the request by just-in-time compiling the code in the page (in any code-behind files) if no cached version of the requested resource exists. What happens afterwards is something called "The ASP.NET Page Life Cycle"
When an ASPX file is requested for the very first time, the ASP.NET runtime engine performs a number of different steps behind the scenes before presenting the page to the user. First based on the class name specified in the inherits tag a list of depended files is created and all the information is stored in form of an XML files with same name as that of the ASPX page, this file can be located under
<<>>\Microsoft.NET\Framework\<<.net version number>>\Temporary ASP.NET Files\<
You might see some random numbers; these are generated as a result of recompilation which happens every time we change the ASPX file.
The ASPX file is dynamically compiled into a DLL having reference to the assembly placed under the bin directory. You could locate the source code generated for the ASPX page under the same directory (look for .cs files) and you could also see how these files are getting compiled by looking at the contents of ".cmdline" files.
So just to summaries this process the ASP.NET engine scans through each of the assemblies under the bin folder to create a list of dependent files for each ASPX, parses each ASPX file into C# code (I am not sure if it would generate some VB code if I change the language for my code behind to VB)
Compiles the code generated and includes all the dependent assemblies as reference to this assembly.
Hence because of the reference the ASPX file is automatically linked to the corresponding assembly in the bin folder.
why we need to place the assembly in the bin folder and not anywhere else?
Every .NET application has a private path where the assemblies are loaded from by default it's GAC and the root directory of the application but this behavior can be changed using what is called as "probing" using the following configuration elements
How ASP.Net Maintains State
When Microsoft developed ASP.Net, they analyzed the various types of common functionality which ASP programmers have had to incorporate into their applications, and developed the ASP.Net object model around this. Because ASP.Net is object-oriented and event-driven, classes were developed which would handle this sort of thing automatically. For this reason, and several others we will explore later, Microsoft developed Web Controls and HTML Controls. We will see that all of the differences in the programming interface add up to the same basic operation as ASP for maintaining state.
ASP.Net adds a hidden form field to a WebForm, called "__VIEWSTATE". This form field corresponds to a server-side object called ViewState. The ViewState object is a Collection of values from the form, which includes the values of all Web Controls and HTML Controls which have been set to maintain their state1 between PostBacks (a "PostBack" is simply the posting of the WebForm back to itself).
How ViewState Works
Here's how it's done. When the WebForm's HTML output is streamed to the browser, the hidden "__VIEWSTATE" field is added to the form. When the form is posted back to the server, the Request.Form Collection (same as ASP) contains the values of the posted form. The Server Control reads the form POST data, extracts the values, and updates (rewrites) the ViewState value to be sent back to the client. At the same time, the Server Control adds the appropriate HTML to the HTML object text to "set" it in it's proper (remembered) state, that is, the state the form field was in when the form was posted. In essence, ASP.Net is doing the same thing that ASP does, although you don't have to write all that code to make it so.
How Events Works
When something happens, whether it is something a User has done through an interface, or something internal to a program's logic, the object which hosted the action sends a message to the Operating System. This message is in the form of an Event object, which contains certain data about the object which spawned the Event. Any object which hosts an Event Handler Method for that object's Event will be notified of the Event by the Operating System, and the Event Handler method is fired when the Event is "raised."
Of course, this brings up the question: How can an event which occurs in a client-side browser, which is disconnected from the server, be recognized by the server, and handled appropriately by both the server and the browser? And of course, the answer is obvious: An event is a message. The browser sends a "message" to the server with each Request. The Event can be communicated to the server in the Request. And the server can then render the appropriate HTML back to the browser according to the Event Handler, thus having the browser "react" to the event as well.
When you add a server-side event to a Server Control or HTML Control, for example, an "onclick" event to a button, ASP.Net automatically adds a client-side "onclick" event handler to the HTML for the object2. The event handler calls the __doPostBack() method, passing the id of the control which fired the event in the "__EVENTTARGET" field, along with any special "__EVENTARGUMENT" data that may be needed on the server side. Note that the __doPostBack() method submits the form back to the server, creating a Request which contains the event data in the hidden form fields.
When the server-side Page class receives the Request, it sees the data in those hidden form fields, and reacts accordingly, raising a real (server-side) Event, which can then be handled by the Event Handler method you have developed (if any).
ASP.Net Controls
We have been using the word "control" fairly frequently here, and now would be a good time to explain the concept of ASP.Net Controls. In the Common Language Runtime (CLR), all classes of objects which are used in ASP.Net interfaces (the HTML document rendered) are derived from System.Web.UI.Control in some form or fashion. The origin of this term can probably be traced back to Windows Forms. All interface elements in a Windows Form are called Controls. The idea of ASP.Net Controls is basically the same: A Control is a class which has back-end processing, and renders a User Interface. In Windows Forms, the interface and back-end are in the same memory space, part of the same Application. In ASP.Net, Controls have back-end processing, and render an HTML interface in the Page. The main difference is that the HTML interface is separated from the back-end processing by the client-server "gulf".
Even the ASP.Net Page class inherits System.Web.UI.Control, just as a Windows Form inherits from Control. A Page has back-end processing and renders an interface in the browser. Like any other Control, it has a Controls Collection. It has the same sequence of Events that any other Control has, plus a few others derived from System.Web.UI.TemplateControl, which is its immediate Base class.
What seems to confuse people who are new to ASP.Net is that while the conceptual model has changed, the platform has not. We're still dealing with HTTP and HTML here, and the control's interface element is just text streamed to the browser. Part of the problem that people have may stem from the way that these controls appear in Visual Studio.NET, and how they appear in the source code for an ASP.Net page. In Visual Studio.NET's IDE, the HTML for Controls is rendered, making it look like there's actually something there. But there's not. If you view the code for the control in the HTML view, you will notice that there is NO HTML for the Control in the page. This is because the Control renders HTML to the page when the page is executed. One of the Event methods that a Control has is the Render() Method. This method literally writes HTML for the control into the HTML output stream of the Page.
Don't let this confuse you, however. Underneath it all, ASP.Net is simply automating much of what you had to hand-code into your ASP applications. It is still writing HTML to the output stream to the browser. Part of the output stream, however, is certain types of HTML elements, such as the client-side event handlers that call the __doPostBack() function, the ViewState hidden form field, and __doPostBack() JavaScript, which are used to emulate the link between the client and server, enabling client-side events to trigger server-side event handlers.
By creating the idea of a WebForm, all of this is brought together into a programming model which acts much like a Windows Form. A Windows Form handles its own events. A WebForm does this too, by sending event messages with a POST to the server, which then streams back the updated state of the WebForm. This is why a WebForm always posts back to itself.
· Server Controls must have their "EnableViewState" property set to True in order to use the ViewState
· This is true only for Controls which have server-side events, and have their "AutoPostBack" property set to True
Sessions
· InProc - session kept as live objects in web server (aspnet_wp.exe). Use "cookieless" configuration in web.config to "munge" the sessionId onto the URL (solves cookie/domain/path RFC problems too!)
· StateServer - session serialized and stored in memory in a separate process (aspnet_state.exe). State Server can run on another machine
· SQLServer - session serialized and stored in SQL server
Performance
· InProc - Fastest, but the more session data, the more memory is consumed on the web server, and that can affect performance.
· StateServer - When storing data of basic types (e.g. string, integer, etc), in one test environment it's 15% slower than InProc. However, the cost of serialization/deserialization can affect performance if you're storing lots of objects. You have to do performance testing for your own scenario.
· SQLServer - When storing data of basic types (e.g. string, integer, etc), in one test environment it's 25% slower than InProc. Same warning about serialization as in StateServer.
