Visual Studio .NET - Life Cycle

Asked By Abhi Rana

29-Aug-08 07:33 AM

Want to know about the Life cycle of ASP.net page

Read this

29-Aug-08 07:34 AM

ASP.NET 2.0 Page Life Cycle - The lifetime of an ASP.NET page is filled with events. A series of processing steps takes place during this page life cycle. Following tasks are performed:

* Initialization
* Instantiation of controls
* Restoration & Maintainance of State
* Running Event Handlers
* Rendering of data to the browser

The life cycle may be broken down into Stages and Events. The stages reflect the broad spectrum of tasks performed. The following stages take place

1) Page Request - This is the first stage, before the page life cycle starts. Whenever a page is requested, ASP.NET detects whether the page is to be requested, parsed and compiled or whether the page can be cached from the system.
2) Start - In this stage, properties such as Request and Response are set. Its also determined at this stage whether the request is a new request or old, and thus it sets the IsPostBack property in the Start stage of the page life cycle.
3) Page Initialization - Each control of the page is assigned a unique identification ID. If there are themes, they are applied. Note that during the Page Initialization stage, neither postback data is loaded, nor any viewstate data is retrieved.
4) Load - If current request is a postback, then control values are retrieved from their viewstate.
5) Validation - The validate method of the validation controls is invoked. This sets the IsValid property of the validation control.
6) PostBack Event Handling - Event handlers are invoked, in case the request is a postback.
7) Rendering - Viewstate for the page is saved. Then render method for each control is called. A textwriter writes the output of the rendering stage to the output stream of the page's Response property.
8) Unload - This is the last stage in the page life cycle stages. It is invoked when the page is completely rendered. Page properties like Respone and Request are unloaded.

Note that each stage has its own events within it. These events may be used by developers to handle their code. Listed below are page events that are used more frequently.

PreInit - Checks the IsPostBack property. To create or recreate dynamic controls. To set master pages dynamically. Gets and Sets profile propety values.
Init - Raised after all controls are initialized, and skin properties are set.
InitComplete - This event may be used, when we need to be sure that all initialization tasks are complete.
PreLoad - If processing on a control or a page is required before the Load event.
Load - invokes the OnLoad event on the page. The same is done for each child control on the page. May set properties of controls, create database connections.
Control Events - These are the control specific events, such as button clicks, listbox item selects etc.
LoadComplete - To execute tasks that require that the complete page has been loaded.
PreRender - Some methods are called before the PreRenderEvent takes place, like EnsureChildControls, data bound controls that have a dataSourceId set also call the DataBind method.
Each control of the page has a PreRender event. Developers may use the prerender event to make final changes to the controls before it is rendered to the page.
SaveStateComplete - ViewState is saved before this event occurs. However, if any changes to the viewstate of a control is made, then this is the event to be used. It cannot be used to make changes to other properties of a control.
Render - This is a stage, not an event. The page object invokes this stage on each control of the page. This actually means that the ASP.NET server control's HTML markup is sent to the browser.
Unload - This event occurs for each control. It takes care of cleanup activities like wiping the database connectivities.

Life cycle of ASP.net page

29-Aug-08 07:37 AM

Each request for an .aspx page that hits IIS is handed over to HTTP Pipeline. HTTP Pipeline is a chain of managed objects that sequentially process the request and convert it to plain HTML text content. The start point of HTTP Pipeline is the HttpRuntime class. The ASP.NET infrastructure creates each instance of this class per AppDomain hosted within the worker process. HttpRuntime class picks up an HttpApplication object from an internal pool and sets it to work on the request. It finds out what class has to handle the request. The association between the resources and handlers are stored in the configurable file of the application. In web.config and also in machine.config you will find these lines in <httpHandlers> section.

If you run through the following program, it will be much easier to follow

This extension can be associated with HandlerClass or HandlerFactory class. HttpApplication object gets the page object that implements the IHttpHandler Interface. The process of generating the output to the browser is started when the object calls ProcessRequest method.

Page Life Cycle

Once the HTTP page handler class is fully identified, the ASP.NET runtime calls the handler's ProcessRequest to start the process. This implementation begins by calling the method FrameworkInitialize(), which builds the control trees for the page. This is a protected and virtual member of TemplateControl class, class from which page itself derives.

Next the processRequest() makes page transits various phases: initialization, loading of viewstate and postback data, loading of page's user code and execution postback server-side events. Then page enters in render mode, the viewstate is updated and HTML generated is sent to the output console. Finally page is unloaded and request is considered completely served.

Stages and corresponding events in the life cycle of the ASP.NET page cycle:

Stage	Events/Method
Page Initialization	Page_Init
View State Loading	LoadViewState
Postback data processing	LoadPostData
Page Loading	Page_Load
PostBack Change Notification	RaisePostDataChangedEvent
PostBack Event Handling	RaisePostBackEvent
Page Pre Rendering Phase	Page_PreRender
View State Saving	SaveViewState
Page Rendering	Page_Render
Page Unloading	Page_UnLoad

Some of the events listed above are not visible at the page level. It will be visible if you happen to write server controls and write a class that is derived from page.

For more details go thr this link;

http://msdn.microsoft.com/en-us/library/ms178472.aspx

Best Luck!!!!!!!!!!!!!!
Sujit.

Life-cycle Events

29-Aug-08 07:37 AM

Life-cycle Events

Within each stage of the life cycle of a page, the page raises events that you can handle to run your own code. For control events, you bind the event handler to the event, either declaratively using attributes such as onclick, or in code.

Pages also support automatic event wire-up, meaning that ASP.NET looks for methods with particular names and automatically runs those methods when certain events are raised. If the AutoEventWireup attribute of the http://msdn.microsoft.com/en-us/library/ydy4x04a.aspx directive is set to true (or if it is not defined, since by default it is true), page events are automatically bound to methods that use the naming convention of Page_event, such as Page_Load and Page_Init. For more information on automatic event wire-up, see http://msdn.microsoft.com/en-us/library/y3bwdsh3.aspx.

The following table lists the page life-cycle events that you will use most frequently. There are more events than those listed; however, they are not used for most page processing scenarios. Instead, they are primarily used by server controls on the ASP.NET Web page to initialize and render themselves. If you want to write your own ASP.NET server controls, you need to understand more about these stages. For information about creating custom controls, see http://msdn.microsoft.com/en-us/library/zt27tfhy.aspx.

Page Event

Typical Use

http://msdn.microsoft.com/en-us/library/system.web.ui.page.preinit.aspx

Use this event for the following:

Check the http://msdn.microsoft.com/en-us/library/system.web.ui.page.ispostback.aspx property to determine whether this is the first time the page is being processed.
Create or re-create dynamic controls.
Set a master page dynamically.
Set the http://msdn.microsoft.com/en-us/library/system.web.ui.page.theme.aspx property dynamically.

Read or set profile property values.

Note:
If the request is a postback, the values of the controls have not yet been restored from view state. If you set a control property at this stage, its value might be overwritten in the next event.

http://msdn.microsoft.com/en-us/library/system.web.ui.control.init.aspx

Raised after all controls have been initialized and any skin settings have been applied. Use this event to read or initialize control properties.

http://msdn.microsoft.com/en-us/library/system.web.ui.page.initcomplete.aspx

Raised by the http://msdn.microsoft.com/en-us/library/system.web.ui.page.aspx object. Use this event for processing tasks that require all initialization be complete.

http://msdn.microsoft.com/en-us/library/system.web.ui.page.preload.aspx

Use this event if you need to perform processing on your page or control before the http://msdn.microsoft.com/en-us/library/system.web.ui.control.load.aspx event.

Before the http://msdn.microsoft.com/en-us/library/system.web.ui.page.aspx instance raises this event, it loads view state for itself and all controls, and then processes any postback data included with the http://msdn.microsoft.com/en-us/library/system.web.ui.page.request.aspx instance.

http://msdn.microsoft.com/en-us/library/system.web.ui.control.load.aspx

The http://msdn.microsoft.com/en-us/library/system.web.ui.page.aspx calls the http://msdn.microsoft.com/en-us/library/system.web.ui.control.onload.aspx event method on the http://msdn.microsoft.com/en-us/library/system.web.ui.page.aspx, then recursively does the same for each child control, which does the same for each of its child controls until the page and all controls are loaded.

Use the http://msdn.microsoft.com/en-us/library/system.web.ui.control.onload.aspx event method to set properties in controls and establish database connections.

Control events

Use these events to handle specific control events, such as a http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.button.aspx control's http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.button.click.aspx event or a http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.textbox.aspx control's http://msdn.microsoft.com/en-us/library/system.web.ui.mobilecontrols.textbox.textchanged.aspx event.

Note:
In a postback request, if the page contains validator controls, check the http://msdn.microsoft.com/en-us/library/system.web.ui.page.isvalid.aspx property of the http://msdn.microsoft.com/en-us/library/system.web.ui.page.aspx and of individual validation controls before performing any processing.

http://msdn.microsoft.com/en-us/library/system.web.ui.page.loadcomplete.aspx

Use this event for tasks that require that all other controls on the page be loaded.

http://msdn.microsoft.com/en-us/library/system.web.ui.control.prerender.aspx

Before this event occurs:

The http://msdn.microsoft.com/en-us/library/system.web.ui.page.aspx object calls http://msdn.microsoft.com/en-us/library/system.web.ui.control.ensurechildcontrols.aspx for each control and for the page.
Each data bound control whose http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.databoundcontrol.datasourceid.aspx property is set calls its http://msdn.microsoft.com/en-us/library/system.web.ui.control.databind.aspx method. For more information, see http://msdn.microsoft.com/en-us/library/ms178472.aspx#databindingevents later in this topic.

The http://msdn.microsoft.com/en-us/library/system.web.ui.control.prerender.aspx event occurs for each control on the page. Use the event to make final changes to the contents of the page or its controls.

http://msdn.microsoft.com/en-us/library/system.web.ui.page.savestatecomplete.aspx

Before this event occurs, http://msdn.microsoft.com/en-us/library/system.web.ui.control.viewstate.aspx has been saved for the page and for all controls. Any changes to the page or controls at this point will be ignored.

Use this event perform tasks that require view state to be saved, but that do not make any changes to controls.

http://msdn.microsoft.com/en-us/library/system.web.ui.control.render.aspx

This is not an event; instead, at this stage of processing, the http://msdn.microsoft.com/en-us/library/system.web.ui.page.aspx object calls this method on each control. All ASP.NET Web server controls have a http://msdn.microsoft.com/en-us/library/system.web.ui.control.render.aspx method that writes out the control's markup that is sent to the browser.

If you create a custom control, you typically override this method to output the control's markup. However, if your custom control incorporates only standard ASP.NET Web server controls and no custom markup, you do not need to override the http://msdn.microsoft.com/en-us/library/system.web.ui.control.render.aspx method. For more information, see http://msdn.microsoft.com/en-us/library/zt27tfhy.aspx.

A user control (an .ascx file) automatically incorporates rendering, so you do not need to explicitly render the control in code.

http://msdn.microsoft.com/en-us/library/system.web.ui.control.unload.aspx

This event occurs for each control and then for the page. In controls, use this event to do final cleanup for specific controls, such as closing control-specific database connections.

For the page itself, use this event to do final cleanup work, such as closing open files and database connections, or finishing up logging or other request-specific tasks.

Note:
During the unload stage, the page and its controls have been rendered, so you cannot make further changes to the response stream. If you attempt to call a method such as the Response.Write method, the page will throw an exception

Refer this microsoft link to know it details :

http://msdn.microsoft.com/en-us/library/ms178473.aspx

Overview

29-Aug-08 07:41 AM

Introduction

When a page request is sent to the Web server, whether through a submission or location change, the page is run through a series of events during its creation and disposal. When we try to build ASP.NET pages and this execution cycle is not taken into account, we can cause a lot of headaches for ourselves. However, when used and manipulated correctly, a page's execution cycle can be an effective and powerful tool. Many developers are realizing that understanding what happens and when it happens is crucial to effectively writing ASP.NET pages or user controls. So let's examine in detail the ten events of an ASP.NET page, from creation to disposal. We will also see how to tap into these events to implant our own custom code.

I'll set the stage with a simple submission form written in ASP.NET with C#. The page is loaded for the first time and has several server-side Web controls on it. When the Web server receives a request for the page, it will process our Web controls and we will eventually get rendered HTML. The first step in processing our page is object initialization.

http://www.15seconds.com/files/020103.zip
http://aspnet.15seconds.com/020103/test.aspx

1. Object Initialization

A page's controls (and the page itself) are first initialized in their raw form. By declaring your objects within the constructor of your C# code-behind file (see Figure 1), the page knows what types of objects and how many to create. Once you have declared your objects within your constructor, you may then access them from any sub class, method, event, or property. However, if any of your objects are controls specified within your ASPX file, at this point the controls have no attributes or properties. It is dangerous to access them through code, as there is no guarantee of what order the control instances will be created (if they are created at all). The initialization event can be overridden using the OnInit method.

Figure 1 - Controls are initialized based on their declaration.

2. Load Viewstate Data

After the Init event, controls can be referenced using their IDs only (no DOM is established yet for relative references). At LoadViewState event, the initialized controls receive their first properties: viewstate information that was persisted back to the server on the last submission. The page viewstate is managed by ASP.NET and is used to persist information over a page roundtrip to the server. Viewstate information is saved as a string of name/value pairs and contains information such as control text or value. The viewstate is held in the value property of a hidden <input> control that is passed from page request to page request. As you can see, this is a giant leap forward from the old ASP 3.0 techniques of maintaining state. This event can be overridden using the LoadViewState method and is commonly used to customize the data received by the control at the time it is populated. Figure 2 shows an example of overriding and setting viewstate at the LoadViewState event.

Figure 2 - When LoadViewState is fired, controls are populated with the appropriate viewstate data.

3. LoadPostData Processes Postback Data

During this phase of the page creation, form data that was posted to the server (termed postback data in ASP.NET) is processed against each control that requires it. When a page submits a form, the framework will implement the IPostBackDataHandler interface on each control that submitted data. The page then fires the LoadPostData event and parses through the page to find each control that implements this interface and updates the control state with the correct postback data. ASP.NET updates the correct control by matching the control's unique ID with the name/value pair in the NameValueCollection. This is one reason that ASP.NET requires unique IDs for each control on any given page. Extra steps are taken by the framework to ensure each ID is unique in situations, such as several custom user controls existing on a single page. After the LoadPostData event triggers, the RaisePostDataChanged event is free to execute (see below).

4. Object Load

Objects take true form during the Load event. All object are first arranged in the page DOM (called the Control Tree in ASP.NET) and can be referenced easily through code or relative position (crawling the DOM). Objects are then free to retrieve the client-side properties set in the HTML, such as width, value, or visibility. During Load, coded logic, such as arithmetic, setting control properties programmatically, and using the StringBuilder to assemble a string for output, is also executed. This stage is where the majority of work happens. The Load event can be overridden by calling OnLoad as shown in Figure 3.

Figure 3 - The OnLoad event is an ideal location to place logic.

5. Raise PostBack Change Events

As stated earlier, this occurs after all controls that implement the IPostBackDataHandler interface have been updated with the correct postback data. During this operation, each control is flagged with a Boolean on whether its data was actually changed or remains the same since the previous submit. ASP.NET then sweeps through the page looking for flags indicating that any object's data has been updated and fires RaisePostDataChanged. The RaisePostDataChanged event does not fire until all controls are updated and after the Load event has occurred. This ensures data in another control is not manually altered during the RaisePostDataChanged event before it is updated with postback data.

6. Process Client-Side PostBack Event

After the server-side events fire on data that was changed due to postback updates, the object which caused the postback is handled at the RaisePostBackEvent event. The offending object is usually a control that posted the page back to the server due to a state change (with autopostback enabled) or a form submit button that was clicked. There is often code that will execute in this event, as this is an ideal location to handle event-driven logic. The RaisePostBackEvent event fires last in the series of postback events due to the accuracy of the data that is rendered to the browser.

Controls that are changed during postback should not be updated after the executing function is called due to the consistency factor. That is, data that is changed by an anticipated event should always be reflected in the resulting page. The RaisePostBackEvent can be trapped by catching RaisePostBackEvent, as in Figure 4.

Figure 4 - The RaisePostDataChanged and RaisePostBackEvent events are defined by the IPostBackDataHandler interface.

7. Prerender the Objects

The point at which the objects are prerendered is the last time changes to the objects can be saved or persisted to viewstate. This makes the PreRender step a good place to make final modifications, such as changing properties of controls or changing Control Tree structure, without having to worry about ASP.NET making changes to objects based off of database calls or viewstate updates. After the PreRender phase those changes to objects are locked in and can no longer be saved to the page viewstate. The PreRender step can be overridden using OnPreRender

8. ViewState Saved

The viewstate is saved after all changes to the page objects have occurred. Object state data is persisted in the hidden <input> object and this is also where object state data is prepared to be rendered to HTML. At the SaveViewState event, values can be saved to the ViewState object, but changes to page controls are not. You can override this step by using SaveViewState, as shown in Figure 5.

Figure 5 - Values are set for controls in OnPreRender. During the SaveViewState event, values are set for the ViewState object.

9. Render To HTML

The Render event commences the building of the page by assembling the HTML for output to the browser. During the Render event, the page calls on the objects to render themselves into HTML. The page then collects the HTML for delivery. When the Render event is overridden, the developer can write custom HTML to the browser that nullifies all the HTML the page has created thus far. The Render method takes an HtmlTextWriter object as a parameter and uses that to output HTML to be streamed to the browser. Changes can still be made at this point, but they are reflected to the client only. The Render event can be overridden, as shown in Figure 6 (below).

10. Disposal

After the page's HTML is rendered, the objects are disposed of. During the Dispose event, you should destroy any objects or references you have created in building the page. At this point, all processing has occurred and it is safe to dispose of any remaining objects, including the Page object. You can override Dispose, as shown in Figure 6.

Figure 6 - The Render event will output custom HTML to the browser through the HtmlTextWriter object.

Conclusion

Each time we request an ASP.NET page, we run through the same process from initialization to disposal. By understanding the inner workings of the ASP.NET page process, writing and debugging our code will be much easier and effective (not to mention less frustrating).

Link: http://www.15seconds.com/issue/020102.htm

http://msdn.microsoft.com/en-us/library/ms178472.aspx

reply

29-Aug-08 07:48 AM

A page in an ASP.NET application consists of several server controls. These are the fundamental building blocks of an ASP.NET application. The Life cycle of an ASP.NET page, depends on whether the page is requested for the first time or it is a postback. Postback is a process by which a page can request for itself.
The processing sequence in which a page is processed during a postback event is:

Initializing: During this phase, the server creates an instance of the server control

Loading view state: During this phase, the view state of the control posted by the client is reloaded into the new instance of the control.

Loading: During this phase, the instance of the control is loaded onto the page object in which it is defined.

Loading the postback data: During this phase, the server searches any data corresponding to the control that is loaded in the data posted by the client.

PreRendering: During this phase, the control is updated with the changes made to it. This prepares the control for rendering.

Saving state: During this phase, the change in the state of control between the current request and the previous request of the page is saved. For each change, the corresponding event is raised. For example, if the text of a textbox is changed, the new text is saved and a text_change event is raised.

Rendering: During this phase, the server creates the corresponding HTML tag for the control.

Disposing: During this phase, all cleanup tasks, such as closing files and database connections opened by the control are performed.

Unloading: During this phase, all cleanup tasks, such as destroying the instances of server control are performed. This is the final event in the life cycle of a server control

The events associated with the relevant page cycle phases are:

Page Initialization: Page_Init
View State Loading:LoadViewState
Postback data processing: LoadPostData
Page Loading: Page_Load
PostBack Change Notification: RaisePostDataChangedEvent
PostBack Event Handling: RaisePostBackEvent
Page Pre Rendering Phase: Page_PreRender
View State Saving: SaveViewState
Page Rendering: Page_Render
Page Unloading: Page_UnLoad

Go through this link:

http://msdn.microsoft.com/en-us/library/ms178472.aspx
http://www.beansoftware.com/ASP.NET-Tutorials/Page-Life-Cycle.aspx

Visual Studio .net .NET Framework

Visual Studio .net .NET Framework Hi NG, ich habe vor lÃ¤ngerer Zeit mit Visual Studio .Net 2003 gearbeitet und Ã¼berlege momentan auf einen neueren Stand upzudaten. Ein Visual Studio .Net 2008 scheint es nicht zu geben. Habe zumindest mit googeln nichts gefunden. Was

Wise for Visual Studio.NET

Wise for Visual Studio.NET Wise for Visual Studio.NET By Peter A. Bromberg, Ph.D. To "Print This Page" Link Peter Bromberg Wise for Visual Studio .NET is a total and complete installation development system for creating and editing Windows® Installer

Visual Studio versioning . . . . how to tell? .NET Framework

Visual Studio versioning . . . . how to tell? .NET Framework To my knowledge, Visual studio 6 was released in 1998, then Visual Studio .NET 2002 is VS 7, then Visual Studio .NET 2003 is VS 7.1, then Visual

visual studio.net 2003 and Access 2007 database .NET Framework

visual studio.net 2003 and Access 2007 database .NET Framework Hi I am currently using Visual Studio.Net 2003 running on Windows Server 2000 operating system. I have used Visual Studio.net 2003 connecting to Access 2002 databases in the pass with great success. Now

Is Visual Studio self-hosting ? .NET Framework

Is Visual Studio self-hosting ? .NET Framework Does Microsoft use Visual Studio IDE, Visual Studio Debugger, Visual Studio Linker and Visual Studio compiler for developing Visual Studio ? Or is Visual Studio not