Page Lifecycle Quick Reference
For a first request (GET), the order is: PreInit, Init, InitComplete, PreLoad, Load, Control events (rare on first load), LoadComplete, PreRender, PreRenderComplete, SaveStateComplete, Render, Unload. For a postback, the same order applies but with an additional step between InitComplete and PreLoad where posted form values and ViewState are restored, and control-specific postback events (Click, SelectedIndexChanged, RowCommand, etc.) fire after Load and before LoadComplete. Master pages and their content pages run their lifecycle events in an interleaved order — the master page's controls generally initialize before the content page's, which matters when a content page's Page_Load tries to reference a master page control too early.
Cricket analogy: The toss, then the innings, then the interval, then the second innings follows a strict order every match, similar to the strict, well-defined order of PreInit through Unload in the page lifecycle.
First Request (GET):
PreInit -> Init -> InitComplete -> PreLoad -> Load -> LoadComplete
-> PreRender -> PreRenderComplete -> SaveStateComplete -> Render -> Unload
Postback:
PreInit -> Init -> InitComplete -> [ViewState + PostData restored] -> PreLoad
-> Load -> [Control postback events: Click, SelectedIndexChanged...] -> LoadComplete
-> PreRender -> PreRenderComplete -> SaveStateComplete -> Render -> UnloadCommon Controls and Directives Cheat Sheet
Frequently used server controls include GridView (tabular data with built-in paging/sorting/editing), Repeater (fully templated, no built-in chrome), ListView (templated with layout flexibility plus DataPager support), FormView/DetailsView (single-record edit/insert/detail views), and the validation family (RequiredFieldValidator, RegularExpressionValidator, CompareValidator, CustomValidator, ValidationSummary). Key page-level directives are @Page (EnableViewState, ValidateRequest, MasterPageFile, CodeBehind), @Register (to use a custom User Control or third-party control on the page), and @Master for defining a Master Page's own directive block. web.config sections most often touched are <system.web><compilation>, <authentication>, <sessionState>, and <customErrors>, plus <system.web><httpModules>/<httpHandlers> or their <system.webServer> equivalents under IIS7 integrated pipeline mode.
Cricket analogy: A captain's toolkit of field placements — slip, gully, mid-on, deep square leg — each suited to a specific bowling situation mirrors how GridView, Repeater, and ListView each suit a specific display scenario.
<%-- @Page directive cheat sheet --%>
<%@ Page Language="C#" AutoEventWireup="true"
CodeBehind="ProductList.aspx.cs" Inherits="MyApp.ProductList"
MasterPageFile="~/Site.Master"
EnableViewState="true" ValidateRequest="true" %>
<%-- Registering a User Control --%>
<%@ Register TagPrefix="uc" TagName="ProductCard" Src="~/Controls/ProductCard.ascx" %>web.config Sections and Session/State Quick Facts
sessionState mode can be InProc (fast, but lost on app pool recycle and doesn't work across a web farm), StateServer (out-of-process on one machine, survives recycles), SQLServer (persisted in a database, survives recycles and works across a farm, slowest), or Custom (a custom provider). authentication mode is typically Forms for username/password login flows (with a loginUrl and timeout in the forms element) or Windows for intranet apps relying on Active Directory. customErrors mode should be RemoteOnly in production so detailed stack traces are visible to a developer on localhost but hidden from the public internet, which should instead see a friendly error page defined via defaultRedirect.
Cricket analogy: Choosing between playing conditions — a home ground you know intimately versus a neutral venue — is like choosing sessionState modes: InProc is fast and familiar but fragile, SQLServer is slower but reliable across a distributed team.
Leaving customErrors mode set to Off (or omitting it) in a production web.config exposes full stack traces, including file paths and sometimes connection strings in exception messages, to any anonymous internet visitor who triggers an unhandled exception.
Validation Controls Quick Reference
RequiredFieldValidator checks for a non-empty/non-default value; RegularExpressionValidator checks input against a ValidationExpression pattern (e.g. email format); CompareValidator compares two controls' values or a control against a constant, useful for password-confirmation fields; RangeValidator checks a value falls within a MinimumValue/MaximumValue; CustomValidator allows arbitrary server-side (and optionally client-side) validation logic via an OnServerValidate handler; and ValidationSummary aggregates all validators' error messages into one list, commonly placed at the top of a form. Every validator needs a ControlToValidate pointing at the input it checks, and Page.IsValid must be checked in the Click handler before acting on the data, since ASP.NET does not automatically block form processing just because a validator failed.
Cricket analogy: A pre-match pitch inspection checks moisture, grass length, and cracks each with a different tool, similar to how each validator (Required, RegularExpression, Range) checks a different aspect of form input.
- First-request lifecycle: PreInit, Init, InitComplete, PreLoad, Load, LoadComplete, PreRender, PreRenderComplete, SaveStateComplete, Render, Unload.
- Postback adds ViewState/PostData restoration before PreLoad, and control events fire between Load and LoadComplete.
- GridView, Repeater, ListView, FormView, and DetailsView each suit a different data-display scenario.
- sessionState modes: InProc (fast, per-server only), StateServer, SQLServer (farm-safe, persisted), or Custom.
- customErrors should be RemoteOnly in production to hide stack traces from the public internet.
- Every validator needs ControlToValidate, and Page.IsValid must be checked explicitly before processing form data.
- ValidationSummary aggregates all validator error messages into a single list, typically shown at the top of a form.
Practice what you learned
1. In the postback lifecycle, where does ViewState/PostData restoration occur relative to PreLoad?
2. Which sessionState mode does NOT survive an application pool recycle?
3. What is the recommended customErrors setting for a production web.config?
4. What must every validation control (like RequiredFieldValidator) specify to function?
5. Which control is best suited for comparing a 'Confirm Password' field against a 'Password' field?
Was this page helpful?
You May Also Like
Web Forms Best Practices
Practical guidelines for writing maintainable, secure, and performant ASP.NET Web Forms applications, from ViewState discipline to layered code organization.
Common Web Forms Pitfalls
The recurring lifecycle, ViewState, and event-handling mistakes that trip up developers working with classic ASP.NET Web Forms.
Classic ASP.NET Interview Questions
Common interview questions and strong-answer strategies for roles involving classic ASP.NET Web Forms maintenance and migration.
Migrating Web Forms to ASP.NET Core
Strategies, mappings, and pitfalls for moving a classic Web Forms application to modern ASP.NET Core.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics