Classic ASP.NET 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.

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.

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.

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.