ASP.NET Application Life Cycle Overview for IIS 5.0 and 6.

0
This topic outlines the life cycle of ASP.NET applications, listing important life-cycle events and describing how code
that you write can fit into the application life cycle. The information in this topic applies to S !." and S #.". $or
information about the ASP.NET application life cycle in S %.", see ASP.NET Application &ife 'ycle (verview for S
%.".
)ithin ASP.NET, several processing steps must occur for an ASP.NET application to be initiali*ed and process
re+uests. Additionally, ASP.NET is only one piece of the )eb server architecture that services re+uests made by
browsers. t is important for you to understand the application life cycle so that you can write code at the
appropriate life cycle stage for the effect you intend.
Application &ife 'ycle in ,eneral
The following table describes the stages of the ASP.NET application life cycle.
Stage Description
-ser re+uests an
application
resource from
the )eb server.
The life cycle of an ASP.NET application starts with a re+uest sent by a browser to the
)eb server .for ASP.NET applications, typically S/. ASP.NET is an SAP e0tension
under the )eb server. )hen a )eb server receives a re+uest, it e0amines the file-
name e0tension of the re+uested file, determines which SAP e0tension should handle
the re+uest, and then passes the re+uest to the appropriate SAP e0tension. ASP.NET
handles file name e0tensions that have been mapped to it, such as .asp0, .asc0, .ash0,
and .asm0.
Note:
f a file name e0tension has not been mapped to ASP.NET, ASP.NET will not receive the
re+uest. This is important to understand for applications that use ASP.NET
authentication. $or e0ample, because .htm files are typically not mapped to ASP.NET,
ASP.NET will not perform authentication or authori*ation chec1s on re+uests for .htm
files. Therefore, even if a file contains only static content, if you want ASP.NET to chec1
authentication, create the file using a file name e0tension mapped to ASP.NET, such
as .asp0.
Note:
f you create a custom handler to service a particular file name e0tension, you must
map the e0tension to ASP.NET in S and also register the handler in your application2s
)eb.config file. $or more information, see 3TTP 3andlers and 3TTP 4odules (verview.
ASP.NET
receives the first
re+uest for the
application.
)hen ASP.NET receives the first re+uest for any resource in an application, a class
named Application4anager creates an application domain. Application domains provide
isolation between applications for global variables and allow each application to be
unloaded separately. )ithin an application domain, an instance of the class named
3ostingEnvironment is created, which provides access to information about the
application such as the name of the folder where the application is stored.
The following diagram illustrates this relationship5
ASP.NET also compiles the top-level items in the application if re+uired, including
application code in the App6'ode folder. $or more information, see 7'ompilation &ife
'ycle7 later in this topic.
ASP.NET core
ob8ects are
created for each
re+uest.
After the application domain has been created and the 3ostingEnvironment ob8ect
instantiated, ASP.NET creates and initiali*es core ob8ects such as 3ttp'onte0t,
3ttp9e+uest, and 3ttp9esponse. The 3ttp'onte0t class contains ob8ects that are
specific to the current application re+uest, such as the 3ttp9e+uest and 3ttp9esponse
ob8ects. The 3ttp9e+uest ob8ect contains information about the current re+uest,
including coo1ies and browser information. The 3ttp9esponse ob8ect contains the
response that is sent to the client, including all rendered output and coo1ies.
An
3ttpApplication
ob8ect is
assigned to the
re+uest
After all core application ob8ects have been initiali*ed, the application is started by
creating an instance of the 3ttpApplication class. f the application has a ,lobal.asa0
file, ASP.NET instead creates an instance of the ,lobal.asa0 class that is derived from
the 3ttpApplication class and uses the derived class to represent the application.
Note:
The first time an ASP.NET page or process is re+uested in an application, a new
instance of 3ttpApplication is created. 3owever, to ma0imi*e performance,
3ttpApplication instances might be reused for multiple re+uests.
)hen an instance of 3ttpApplication is created, any configured modules are also
created. $or instance, if the application is configured to do so, ASP.NET creates a
SessionState4odule module. After all configured modules are created, the
3ttpApplication class2s nit method is called.
The following diagram illustrates this relationship5
The re+uest is
processed by the
3ttpApplication
pipeline.
The following events are e0ecuted by the 3ttpApplication class while the re+uest is
processed. The events are of particular interest to developers who want to e0tend the
3ttpApplication class.
1. :alidate the re+uest, which e0amines the information sent by the browser and
determines whether it contains potentially malicious mar1up. $or more
information, see :alidate9e+uest and Script E0ploits (verview.
2. Perform -9& mapping, if any -9&s have been configured in the
-rl4appingsSection section of the )eb.config file.
3. 9aise the ;egin9e+uest event.
4. 9aise the Authenticate9e+uest event.
5. 9aise the PostAuthenticate9e+uest event.
6. 9aise the Authori*e9e+uest event.
7. 9aise the PostAuthori*e9e+uest event.
8. 9aise the 9esolve9e+uest'ache event.
9. 9aise the Post9esolve9e+uest'ache event.
10. ;ased on the file name e0tension of the re+uested resource .mapped in the
application2s configuration file/, select a class that implements 3ttp3andler to
process the re+uest. f the re+uest is for an ob8ect .page/ derived from the
Page class and the page needs to be compiled, ASP.NET compiles the page
before creating an instance of it.
11. 9aise the Post4ap9e+uest3andler event.
12. 9aise the Ac+uire9e+uestState event.
13. 9aise the PostAc+uire9e+uestState event.
14. 9aise the Pre9e+uest3andlerE0ecute event.
15. 'all the Process9e+uest method .or the asynchronous version
3ttpAsync3andler..55.;eginProcess9e+uest/ of the appropriate 3ttp3andler
class for the re+uest. $or e0ample, if the re+uest is for a page, the current page
instance handles the re+uest.
16. 9aise the Post9e+uest3andlerE0ecute event.
17. 9aise the 9elease9e+uestState event.
18. 9aise the Post9elease9e+uestState event.
19. Perform response filtering if the $ilter property is defined.
20. 9aise the -pdate9e+uest'ache event.
21. 9aise the Post-pdate9e+uest'ache event.
22. 9aise the End9e+uest event.
23. 9aise the PreSend9e+uest3eaders event.
<=. 9aise the PreSend9e+uest'ontent event.
&ife 'ycle Events and the ,lobal.asa0 file
>uring the application life cycle, the application raises events that you can handle and calls particular methods that
you can override. To handle application events or methods, you can create a file named ,lobal.asa0 in the root
directory of your application.
f you create a ,lobal.asa0 file, ASP.NET compiles it into a class derived from the 3ttpApplication class, and then
uses the derived class to represent the application.
An instance of 3ttpApplication processes only one re+uest at a time. This simplifies application event handling
because you do not need to loc1 non-static members in the application class when you access them. This also
allows you to store re+uest-specific data in non-static members of the application class. $or e0ample, you can
define a property in the ,lobal.asa0 file and assign it a re+uest-specific value.
ASP.NET automatically binds application events to handlers in the ,lobal.asa0 file using the naming convention
Application_event, such as Application_BeginRequest. This is similar to the way that ASP.NET page methods
are automatically bound to events, such as the page2s Page_Load event. $or details, see ASP.NET Page &ife 'ycle
(verview.
The Application_Start and Application_End methods are special methods that do not represent 3ttpApplication
events. ASP.NET calls them once for the lifetime of the application domain, not for each 3ttpApplication instance.
The following table lists some of the events and methods that are used during the application life cycle. There are
many more events than those listed, but they are not commonly used.
Event or method Description
Application_Start 'alled when the first resource .such as a page/ in an ASP.NET application is
re+uested. The Application_Start method is called only one time during the life
cycle of an application. ?ou can use this method to perform startup tas1s such as
loading data into the cache and initiali*ing static values.
?ou should set only static data during application start. >o not set any instance data
because it will be available only to the first instance of the 3ttpApplication class that
is created.
Application_event 9aised at the appropriate time in the application life cycle, as listed in the application
life cycle table earlier in this topic.
Application_Error can be raised at any phase in the application life cycle.
Application_EndRequest is the only event that is guaranteed to be raised in every
re+uest, because a re+uest can be short-circuited. $or e0ample, if two modules
handle the Application_BeginRequest event and the first one throws an
e0ception, the Application_BeginRequest event will not be called for the second
module. 3owever, the Application_EndRequest method is always called to allow
the application to clean up resources.
nit 'alled once for every instance of the 3ttpApplication class after all modules have
been created.
>ispose 'alled before the application instance is destroyed. ?ou can use this method to
manually release any unmanaged resources. $or more information, see 'leaning -p
-nmanaged 9esources.
Application_End 'alled once per lifetime of the application before the application is unloaded.
'ompilation &ife 'ycle
)hen the first re+uest is made to an application, ASP.NET compiles application items in a specific order. The first
items to be compiled are referred to as the top-level items. After the first re+uest, the top-level items are
recompiled only if a dependency changes. The following table describes the order in which ASP.NET top-level items
are compiled.
Item Description
App6,lobal9esources The application2s global resources are compiled and a resource assembly
is built. Any assemblies in the application2s ;in folder are lin1ed to the
resource assembly.
App6)eb9esources Pro0y types for )eb services are created and compiled. The resulting
)eb references assembly is lin1ed to the resource assembly if it e0ists.
Profile properties defined in
the )eb.config file
f profile properties are defined in the application2s )eb.config file, an
assembly is generated that contains a profile ob8ect.
App6'ode Source code files are built and one or more assemblies are created. All
code assemblies and the profile assembly are lin1ed to the resources and
)eb references assemblies if any.
,lobal.asa0 The application ob8ect is compiled and lin1ed to all of the previously
generated assemblies.
After the application2s top level items have been compiled, ASP.NET compiles folders, pages, and other items as
needed. The following table describes the order in which ASP.NET folders and items are compiled.
Item Description
App6&ocal9esources f the folder containing the re+uested item contains an
App6&ocal9esources folder, the contents of the local
resources folder are compiled and lin1ed to the global
resources assembly.
ndividual )eb pages ..asp0 files/, user
controls ..asc0 files/, 3TTP handlers ..ash0
files/, and 3TTP modules ..asm0 files/
'ompiled as needed and lin1ed to the local resources
assembly and the top-level assemblies.
Themes, master pages, other source files S1in files for individual themes, master pages, and other
source code files referenced by pages are compiled when
the referencing page is compiled.
'ompiled assemblies are cached on the server and reused on subse+uent re+uests and are preserved across
application restarts as long as the source code is unchanged.
;ecause the application is compiled on the first re+uest, the initial re+uest to an application can ta1e significantly
longer than subse+uent re+uests. ?ou can precompile your application to reduce the time re+uired for the first
re+uest. $or more information, see 3ow to5 Precompile ASP.NET )eb Sites.
Application Restarts
4odifying the source code of your )eb application will cause ASP.NET to recompile source files into assemblies.
)hen you modify the top-level items in your application, all other assemblies in the application that reference the
top-level assemblies are recompiled as well.
n addition, modifying, adding, or deleting certain types of files within the application2s 1nown folders will cause the
application to restart. The following actions will cause an application restart5

Adding, modifying, or deleting assemblies from the application2s ;in folder.

Adding, modifying, or deleting locali*ation resources from the App6,lobal9esources or

App6&ocal9esources folders.

Adding, modifying, or deleting the application2s ,lobal.asa0 file.

Adding, modifying, or deleting source code files in the App6'ode directory.

Adding, modifying, or deleting Profile configuration.

Adding, modifying, or deleting )eb service references in the App6)eb9eferences directory.

Adding, modifying, or deleting the application2s )eb.config file.

)hen an application restart is re+uired, ASP.NET will serve all pending re+uests from the e0isting application
domain and the old assemblies before restarting the application domain and loading the new assemblies.
3TTP 4odules
The ASP.NET application life cycle is e0tensible through 3ttp4odule classes. ASP.NET includes several classes that
implement 3ttp4odule, such as the SessionState4odule class. ?ou can also create your own classes that
implement 3ttp4odule.
f you add modules to your application, the modules themselves can raise events. The application can subscribe to
in these events in the ,lobal.asa0 file by using the convention modulename6eventname. $or e0ample, to handle
the Authenticate event raised by a $ormsAuthentication4odule ob8ect, you can create a handler named
ormsAuthentication_Authenticate.
The SessionState4odule class is enabled by default in ASP.NET. All session events are automatically wired up as
Session_event, such as Session_Start. The Start event is raised each time a new session is created. $or more
information, see ASP.NET Session State (verview.
ASP.NET Application Life Cycle Overview for IIS 7.0
This topic describes the application life cycle for ASP.NET applications that are running in S %." in ntegrated
mode and with the .NET $ramewor1 @." or later. S %." also supports 'lassic mode, which behaves li1e ASP.NET
running in S #.". $or more information, see ASP.NET Application &ife 'ycle (verview for S !." and #.".
The S %." integrated pipeline is a unified re+uest processing pipeline that supports both native-code and
managed-code modules. 4anaged-code modules that implement the 3ttp4odule interface have access to all
events in the re+uest pipeline. $or e0ample, a managed-code module can be used for ASP.NET forms
authentication for both ASP.NET )eb pages ..asp0 files/ and 3T4& pages ..htm or .html files/. This is true even
though 3T4& pages are treated as static resources by S and ASP.NET. $or more information about S
%." ntegrated mode, see ASP.NET ntegration with S%.
This topic contains the following sections5

Architectural (verview

&ife 'ycle Stages

-sing the ,lobal.asa0 $ile

4anaged-code 4odules in S %."

Architectural (verview
A re+uest in S %." ntegrated mode passes through stages that are li1e the stages of re+uests for ASP.NET
resources in S #.". 3owever, in S %.", these stages include several additional application events, such as the
4ap9e+uest3andler, &og9e+uest, and Post&og9e+uest events.
The main difference in processing stages between S %." and S #." is in how ASP.NET is integrated with the S
server. n S #.", there are two re+uest processing pipelines. (ne pipeline is for native-code SAP filters and
e0tension components. The other pipeline is for managed-code application components such as ASP.NET. n S
%.", the ASP.NET runtime is integrated with the )eb server so that there is one unified re+uest processing pipeline
for all re+uests. $or ASP.NET developers, the benefits of the integrated pipeline are as follows5

The integrated pipeline raises all the events that are e0posed by the 3ttpApplication ob8ect, which enables
e0isting ASP.NET 3TTP modules to wor1 in S %." ntegrated mode.

;oth native-code and managed-code modules can be configured at the )eb server, )eb site, or )eb
application level. This includes the built-in ASP.NET managed-code modules for session state, forms
authentication, profiles, and role management. $urthermore, managed-code modules can be enabled or
disabled for all re+uests, regardless of whether the re+uest is for an ASP.NET resource li1e an .asp0 file.

4anaged-code modules can be invo1ed at any stage in the pipeline. This includes before any server
processing occurs for the re+uest, after all server processing has occurred, or anywhere in between.

?ou can register and enable or disable modules through an applicationAs )eb.config file.
The following illustration shows the configuration of an application2s re+uest pipeline. The e0ample includes the
following5

The Anon!mous native-code module and the orms managed-code module .which corresponds to
$ormsAuthentication4odule/. These modules are configured, and they are invo1ed during the
Authentication stage of the re+uest.

The Basic native-code module and the "indo#s managed-code module .which corresponds to
)indowsAuthentication4odule/. They are shown, but they are not configured for the application.

The E$ecute handler stage, where the handler .a module scoped to a -9&/ is invo1ed to construct the
response. $or .asp0 files, the Page3andler$actory handler is used to respond to the re+uest. $or static
files, the native-code Staticile%odule module responds to the re+uest.

The &race native-code module. This is shown, but it is not configured for the application.

The 'ustom module managed-code class. t is invo1ed during the Log request stage.
$or information about 1nown compatibility issues with ASP.NET applications that are being migrated from earlier
versions of S to S %.", see the 7Bnown >ifferences ;etween ntegrated 4ode and 'lassic 4ode7 section of
-pgrading ASP.NET Applications to S %."5 >ifferences between S %." ntegrated 4ode and 'lassic mode.
&ife 'ycle Stages
The following table lists the stages of the ASP.NET application life cycle with ntegrated mode in S %.".
Stage Description
A re+uest is made
for an application
resource.
The life cycle of an ASP.NET application starts with a re+uest sent by a browser to
the )eb server.
n 'lassic mode in S %." and in S #.", the ASP.NET re+uest pipeline is separate
from the )eb server pipeline. 4odules apply only to re+uests that are routed to the
ASP.NET SAP e0tension. f the file-name e0tension of the re+uested resource
type is not e0plicitly mapped to ASP.NET, ASP.NET functionality is not invo1ed for
the re+uest because the re+uest is not processed by the ASP.NET runtime.
n integrated mode in S %.", a unified pipeline handles all re+uests. )hen the
integrated pipeline receives a re+uest, the re+uest passes through stages that are
common to all re+uests. These stages are represented by the 9e+uestNotification
enumeration. All re+uests can be configured to ta1e advantage of ASP.NET
functionality, because that functionality is encapsulated in managed-code modules
that have access to the re+uest pipeline. $or e0ample, even though the .htm file-
name e0tension is not e0plicitly mapped to ASP.NET, a re+uest for an 3T4& page
still invo1es ASP.NET modules. This enables you to ta1e advantage of ASP.NET
authentication and authori*ation for all resources.
The unified pipeline
receives the first
re+uest for the
application.
)hen the unified pipeline receives the first re+uest for any resource in an
application, an instance of the Application4anager class is created, which is the
application domain that the re+uest is processed in. Application domains provide
isolation between applications for global variables and enable each application to be
unloaded separately. n the application domain, an instance of the
3ostingEnvironment class is created, which provides access to information about
the application, such as the name of the folder where the application is stored.
>uring the first re+uest, top-level items in the application are compiled if re+uired,
which includes application code in the App6'ode folder. ?ou can include custom
modules and handlers in the App6'ode folder as described in 4anaged-code
4odules in S %." later in this topic.
9esponse ob8ects
are created for each
re+uest.
After the application domain has been created and the 3ostingEnvironment ob8ect
has been instantiated, application ob8ects such as 3ttp'onte0t, 3ttp9e+uest, and
3ttp9esponse are created and initiali*ed. The 3ttp'onte0t class contains ob8ects
that are specific to the current application re+uest, such as the 3ttp9e+uest and
3ttp9esponse ob8ects. The 3ttp9e+uest ob8ect contains information about the
current re+uest, which includes coo1ies and browser information. The 3ttp9esponse
ob8ect contains the response that is sent to the client, which includes all the
rendered output and coo1ies.
The following are some 1ey differences between S #." and S %." running in
ntegrated mode and with the .NET $ramewor1 @." or later5
The SubStatus'ode property of the 3ttp9esponse ob8ect is available for
setting codes that are useful for failed-re+uest tracing. $or more information,
see Troubleshooting $ailed 9e+uests -sing $ailed 9e+uest Tracing in S %.".
The 3eaders property of the 3ttp9esponse ob8ect provides access to
response headers for the response.
Two properties of the 3ttp'onte0t ob8ect, sPostNotification and
'urrentNotification, are used when one event handler handles several
3ttpApplication events.
The 3eaders and Server:ariables property of the 3ttp9e+uest ob8ect are
write-enabled.
An 3ttpApplication
ob8ect is assigned to
the re+uest
After all application ob8ects have been initiali*ed, the application is started by
creating an instance of the 3ttpApplication class. f the application has a
,lobal.asa0 file, ASP.NET instead creates an instance of the ,lobal.asa0 class that is
derived from the 3ttpApplication class. t then uses the derived class to represent
the application.
Note:
The first time that an ASP.NET page or process is re+uested in an application, a new
instance of the 3ttpApplication class is created. 3owever, to ma0imi*e performance,
3ttpApplication instances might be reused for multiple re+uests.
)hich ASP.NET modules are loaded .such as the SessionState4odule/ depends on
the managed-code modules that the application inherits from a parent application.
t also depends on which modules are configured in the configuration section of the
application2s )eb.config file. 4odules are added or removed in the application2s
)eb.config modules element in the s!stem(#e)Server section. $or more
information, see 3ow to5 'onfigure the Csystem.webServerD Section for S %.".
The re+uest is
processed by the
3ttpApplication
pipeline.
The following tas1s are performed by the 3ttpApplication class while the re+uest is
being processed. The events are useful for page developers who want to run code
when 1ey re+uest pipeline events are raised. They are also useful if you are
developing a custom module and you want the module to be invo1ed for all
re+uests to the pipeline. 'ustom modules implement the 3ttp4odule interface. n
ntegrated mode in S %.", you must register event handlers in a module2s nit
method.
1. :alidate the re+uest, which e0amines the information sent by the browser
and determines whether it contains potentially malicious mar1up. $or more
information, see :alidate9e+uest and Script E0ploits (verview.
2. Perform -9& mapping, if any -9&s have been configured in the
-rl4appingsSection section of the )eb.config file.
3. 9aise the ;egin9e+uest event.
4. 9aise the Authenticate9e+uest event.
5. 9aise the PostAuthenticate9e+uest event.
6. 9aise the Authori*e9e+uest event.
7. 9aise the PostAuthori*e9e+uest event.
8. 9aise the 9esolve9e+uest'ache event.
9. 9aise the Post9esolve9e+uest'ache event.
10. 9aise the 4ap9e+uest3andler event. An appropriate handler is selected
based on the file-name e0tension of the re+uested resource. The handler
can be a native-code module such as the S %." Staticile%odule or a
managed-code module such as the Page3andler$actory class .which
handles .asp0 files/.
11. 9aise the Post4ap9e+uest3andler event.
12. 9aise the Ac+uire9e+uestState event.
13. 9aise the PostAc+uire9e+uestState event.
14. 9aise the Pre9e+uest3andlerE0ecute event.
15. 'all the Process9e+uest method .or the asynchronous version
3ttpAsync3andler..55.;eginProcess9e+uest/ of the appropriate
3ttp3andler class for the re+uest. $or e0ample, if the re+uest is for a
page, the current page instance handles the re+uest.
16. 9aise the Post9e+uest3andlerE0ecute event.
17. 9aise the 9elease9e+uestState event.
18. 9aise the Post9elease9e+uestState event.
19. Perform response filtering if the $ilter property is defined.
20. 9aise the -pdate9e+uest'ache event.
21. 9aise the Post-pdate9e+uest'ache event.
22. 9aise the &og9e+uest event.
23. 9aise the Post&og9e+uest event.
24. 9aise the End9e+uest event.
25. 9aise the PreSend9e+uest3eaders event.
<#. 9aise the PreSend9e+uest'ontent event.
Note:
The 4ap9e+uest3andler, &og9e+uest, and Post&og9e+uest events are
supported only if the application is running in ntegrated mode in S %."
and with the .NET $ramewor1 @." or later.
-sing the ,lobal.asa0 $ile
The ,lobal.asa0 file is used in ntegrated mode in S %." much as it is used in ASP.NET in S #.". $or more
information, see the 7&ife 'ycle Events and ,lobal.asa0 $ile7 section in ASP.NET Application &ife 'ycle (verview for
S !." and #.".
(ne difference is that you can add handlers for the 4ap9e+uest3andler, &og9e+uest, and Post&og9e+uest events.
These events are supported for applications that run in ntegrated mode in S %." and with the .NET $ramewor1
@." or later.
?ou can provide application event handlers in the ,lobal.asa0 file to add code that e0ecutes for all re+uests that
are handled by ASP.NET, such as re+uests for .asp0 and .a0d pages. 3owever, handler code in the ,lobal.asa0 file
is not called for re+uests for non-ASP.NET resources, such as static files. To run managed code that runs for all
resources, create a custom module that implements the 3ttp4odule interface. The custom module will run for all
re+uests to resources in the application, even if the resource handler is not an ASP.NET handler.
4anaged-code 4odules in S %."
The ASP.NET managed-code modules that can be configured and loaded in S %." include the following5

$ormsAuthentication4odule

Profile4odule

9ole4anager4odule

SessionState4odule
To configure S %." managed-code modules you can use one of the following methods5

-se S 4anager. $or more information, see 3ow to5 (pen S 4anager.

-se the S %." command-line tool .Appcmd.e0e/. $or more information, see S %." 'ommand-&ine Tool.

Edit the S %." E4&-based configuration store. $or more information, see S %."5 S %." 'onfiguration
Store.
)hen an ASP.NET managed-code module such as the $ormsAuthentication4odule module is configured to load in
S %.", it has access to all events in the re+uest pipeline. This means that all re+uests pass through the managed-
code module. $or the $ormsAuthentication4odule class, it means that static content can be protected by using
forms authentication, even though the content is not handled by an ASP.NET handler.
Developing 'ustom %anaged*code %odules
The ASP.NET application life cycle can be e0tended with modules that implement the 3ttp4odule interface.
4odules that implement the 3ttp4odule interface are managed-code modules. The integrated pipeline of ASP.NET
and S %." is also e0tensible through native-code modules, which are not discussed in this topic. $or more
information about native-code modules and about how to configure modules generally, see S 4odule (verview.
?ou can define a managed-code module as a class file in the application2s App6'ode folder. ?ou can also create the
module as a class library pro8ect, compile it, and add it to application2s ;in folder. After you have created the
custom module, you must register it with S %.". ?ou can use one of the methods described for managing S %."
managed-code modules. $or e0ample, you can edit an application2s )eb.config file to register the managed-code
module for 8ust that application. $or an e0ample of registering a module, see )al1through5 'reating and
9egistering a 'ustom 3TTP 4odule.
f a module is defined an application2s App6'ode or ;in folder and it is registered in the application2s )eb.config
file, the module is invo1ed only for that application. To register the module in the applicationAs )eb.config file, you
wor1 with the modules element in the s!stem(#e)Server section. $or more information, see 3ow to5 'onfigure
the Csystem.webServerD Section for S %.". 'hanges made by using S 4anager or the Appcmd.e0e tool will
ma1e changes to the application2s )eb.config file.
4anaged-code modules can also be registered in the modules element of the S %." configuration store .the
Application3ost.config file/. 4odules registered in the Application3ost.config file have global scope because they
are registered for all )eb applications hosted by S %.". Similarly, native-code modules that are defined in the
glo)al%odules element of the Application3ost.config file have global scope. f a global module is not needed for a
)eb application, you can disable it.
E$ample
The following e0ample shows a custom module that handles the &og9e+uest and Post&og9e+uest events. Event
handlers are registered in the nit method of the module.
:isual ;asic
'opy 'ode
Imports System
Imports System.Data
Imports System.Web
Imports System.Web.Security
Imports System.Web.UI
Imports Microsoft.VisualBasic
' Module that demonstrates one event handler for several events.
Namespace Samples
ublic !lass Module"#ample
Implements I$ttpModule
ublic Sub Ne%&'
' !onstructor
"nd Sub
ublic Sub Init&ByVal app (s $ttp(pplication' Implements
I$ttpModule.Init
(dd$andler app.)o*+e,uest- (ddress.f Me.(pp/$andler
(dd$andler app.ost)o*+e,uest- (ddress.f Me.(pp/$andler
"nd Sub
ublic Sub Dispose&' Implements I$ttpModule.Dispose
"nd Sub
' .ne for both the )o*+e,uest and ost)o*+e,uest events.
ublic Sub (pp/$andler&ByVal source (s .b0ect- ByVal e (s "vent(r*s'
Dim app (s $ttp(pplication 1 !2ype&source- $ttp(pplication'
Dim conte#t (s $ttp!onte#t 1 app.!onte#t
If &conte#t.!urrentNotification 1 +e,uestNotification.)o*+e,uest'
2hen
If Not &conte#t.IsostNotification' 2hen
' ut code here that is invo3ed %hen the )o*+e,uest event
is raised.
"lse
' ost)o*+e,uest
' ut code here that runs after the )o*+e,uest event
completes.
"nd If
"nd If
"nd Sub
"nd !lass
"nd Namespace
'F
'opy 'ode
usin* System4
usin* System.Data4
usin* System.Web4
usin* System.Web.Security4
usin* System.Web.UI4
55 Module that demonstrates one event handler for several events.
namespace Samples
6
public class Module"#ample 7 I$ttpModule
6
public Module"#ample&'
6
55 !onstructor
8
public void Init&$ttp(pplication app'
6
app.)o*+e,uest 91 ne% "vent$andler&(pp/$andler'4
app.ost)o*+e,uest 91 ne% "vent$andler&(pp/$andler'4
8
public void Dispose&'
6
8
55 .ne handler for both the )o*+e,uest and the ost)o*+e,uest events.
public void (pp/$andler&ob0ect source- "vent(r*s e'
6
$ttp(pplication app 1 &$ttp(pplication'source4
$ttp!onte#t conte#t 1 app.!onte#t4
if &conte#t.!urrentNotification 11 +e,uestNotification.)o*+e,uest'
6
if &:conte#t.IsostNotification'
6
55 ut code here that is invo3ed %hen the )o*+e,uest
event is raised.
8
else
6
55 ost)o*+e,uest
55 ut code here that runs after the )o*+e,uest event
completes.
8
8
8
8
8
The following e0ample shows how to register the module in the applicationAs )eb.config file. Add the
s!stem(#e)Server configuration section inside the configuration section.
;system.%ebServer<
;modules<
;add name1=Module"#ample= type1=Samples.Module"#ample=5<
;5modules<
;5system.%ebServer<
$or an additional e0ample that shows how to create and register a custom module, see )al1through5 'reating and
9egistering a 'ustom 3TTP 4odule.
ASP.NET Pae Life Cycle Overview !.Net ".0#
)hen an ASP.NET page runs, the page goes through a life cycle in which it performs a series of processing steps.
These include initiali*ation, instantiating controls, restoring and maintaining state, running event handler code, and
rendering. t is important for you to understand the page life cycle so that you can write code at the appropriate
life-cycle stage for the effect you intend. Additionally, if you develop custom controls, you must be familiar with the
page life cycle in order to correctly initiali*e controls, populate control properties with view-state data, and run any
control behavior code. .The life cycle of a control is based on the page life cycle, but the page raises more events
for a control than are available for an ASP.NET page alone./
+eneral Page Li,e*c!cle Stages
n general terms, the page goes through the stages outlined in the following table. n addition to the page life-cycle
stages, there are application stages that occur before and after a re+uest but are not specific to a page. $or more
information, see ASP.NET Application &ife 'ycle (verview.
Stage Description
Page re+uest The page re+uest occurs before the page life cycle begins. )hen the page is re+uested
by a user, ASP.NET determines whether the page needs to be parsed and compiled
.therefore beginning the life of a page/, or whether a cached version of the page can be
sent in response without running the page.
Start n the start step, page properties such as 9e+uest and 9esponse are set. At this stage,
the page also determines whether the re+uest is a postbac1 or a new re+uest and sets
the sPost;ac1 property. Additionally, during the start step, the page2s -'ulture
property is set.
Page >uring page initiali*ation, controls on the page are available and each control2s -ni+ue>
initiali*ation property is set. Any themes are also applied to the page. f the current re+uest is a
postbac1, the postbac1 data has not yet been loaded and control property values have
not been restored to the values from view state.
&oad >uring load, if the current re+uest is a postbac1, control properties are loaded with
information recovered from view state and control state.
:alidation >uring validation, the :alidate method of all validator controls is called, which sets the
s:alid property of individual validator controls and of the page.
Postbac1 event
handling
f the re+uest is a postbac1, any event handlers are called.
9endering ;efore rendering, view state is saved for the page and all controls. >uring the rendering
phase, the page calls the 9ender method for each control, providing a te0t writer that
writes its output to the (utputStream of the page2s Response property.
-nload -nload is called after the page has been fully rendered, sent to the client, and is ready to
be discarded. At this point, page properties such as Response and Request are
unloaded and any cleanup is performed.
Li,e*c!cle Events
)ithin each stage of the life cycle of a page, the page raises events that you can handle to run your own code. $or
control events, you bind the event handler to the event, either declaratively using attributes such as onclic-, or in
code.
Pages also support automatic event wire-up, meaning that ASP.NET loo1s for methods with particular names and
automatically runs those methods when certain events are raised. f the AutoEvent"ireup attribute of the
G Page 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. $or more
information on automatic event wire-up, see ASP.NET )eb Server 'ontrol Event 4odel.
The following table lists the page life-cycle events that you will use most fre+uently. There are more events than
those listedH however, they are not used for most page processing scenarios. nstead, they are primarily used by
server controls on the ASP.NET )eb page to initiali*e and render themselves. f you want to write your own
ASP.NET server controls, you need to understand more about these stages. $or information about creating custom
controls, see >eveloping 'ustom ASP.NET Server 'ontrols.
Page Event &!pical .se
Prenit -se this event for the following5
'hec1 the IsPostBac- property to determine whether this is the first time
the page is being processed.
'reate or re-create dynamic controls.
Set a master page dynamically.
Set the Theme property dynamically.
9ead or set profile property values.
Note
f the re+uest is a postbac1, the values of the controls have not yet been
restored from view state. f you set a control property at this stage, its value
might be overwritten in the ne0t event.

nit 9aised after all controls have been initiali*ed and any s1in settings have been
applied. -se this event to read or initiali*e control properties.
nit'omplete 9aised by the Page ob8ect. -se this event for processing tas1s that re+uire all
initiali*ation be complete.
Pre&oad -se this event if you need to perform processing on your page or control before the
&oad event.
After the Page raises this event, it loads view state for itself and all controls, and
then processes any postbac1 data included with the Request instance.
Load The Page calls the (n&oad event method on the Page, 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.
-se the /nLoad event method to set properties in controls and establish database
connections.
'ontrol events -se these events to handle specific control events, such as a ;utton control2s 'lic1
event or a Te0t;o0 control2s Te0t'hanged event.
Note
n a postbac1 re+uest, if the page contains validator controls, chec1 the
s:alid property of the Page and of individual validation controls before
performing any processing.
&oad'omplete -se this event for tas1s that re+uire that all other controls on the page be loaded.
Pre9ender ;efore this event occurs5
The Page ob8ect calls Ensure'hild'ontrols for each control and for the
page.
Each data bound control whose >ataSource> property is set calls its
>ata;ind method. $or more information, see >ata ;inding Events for >ata-
;ound 'ontrols below.
The PreRender event occurs for each control on the page. -se the event to ma1e
final changes to the contents of the page or its controls.
SaveState'omplete ;efore this event occurs, :iewState has been saved for the page and for all controls.
Any changes to the page or controls at this point will be ignored.
-se this event perform tas1s that re+uire view state to be saved, but that do not
ma1e any changes to controls.
Render This is not an eventH instead, at this stage of processing, the Page ob8ect calls this
method on each control. All ASP.NET )eb server controls have a Render method
that writes out the control2s mar1up that is sent to the browser.
f you create a custom control, you typically override this method to output the
control2s mar1up. 3owever, if your custom control incorporates only standard
ASP.NET )eb server controls and no custom mar1up, you do not need to override
the Render method. $or more information, see >eveloping 'ustom ASP.NET Server
'ontrols.
A user control .an .asc0 file/ automatically incorporates rendering, so you do not
need to e0plicitly render the control in code.
-nload This event occurs for each control and then for the page. n controls, use this event
to do final cleanup for specific controls, such as closing control-specific database
connections.
$or the page itself, use this event to do final cleanup wor1, such as closing open files
and database connections, or finishing up logging or other re+uest-specific tas1s.
Note
>uring the unload stage, the page and its controls have been rendered, so
you cannot ma1e further changes to the response stream. f you attempt to
call a method such as the Response("rite method, the page will throw an
e0ception.
Additional Page Li,e '!cle 'onsiderations
ndividual ASP.NET server controls have their own life cycle that is similar to the page life cycle. $or e0ample, a
control2s Init and Load events occur during the corresponding page events.
Although both Init and Load recursively occur on each control, they happen in reverse order. The Init event .and
also the .nload event/ for each child control occur before the corresponding event is raised for its container
.bottom-up/. 3owever the Load event for a container occurs before the Load events for its child controls .top-
down/.
?ou can customi*e the appearance or content of a control by handling the events for the control, such as the 'lic-
event for the Button control and the Selectednde0'hanged event for the &ist;o0 control. -nder some
circumstances, you might also handle a control2s >ata;inding or >ata;ound events. $or more information, see the
class reference topics for individual controls and >eveloping 'ustom ASP.NET Server 'ontrols.
)hen inheriting a class from the Page class, in addition to handling events raised by the page, you can override
methods from the page2s base class. $or e0ample, you can override the page2s nitiali*e'ulture method to
dynamically set culture information. Note that when creating an event handler using the Page_event synta0, the
base implementation is implicitly called and therefore you do not need to call it in your method. $or e0ample, the
base page class2s /nLoad method is always called, whether you create a Page_Load method or not. 3owever, if
you override the page /nLoad method with the override 1eyword ./verrides in :isual ;asic/, you must e0plicitly
call the base method. $or e0ample, if you override the /nLoad method on the page, you must call )ase(Load
.%!Base(Load in :isual ;asic/ in order for the base implementation to be run.
'atch*up Events ,or Added 'ontrols
f controls are created dynamically at run time or are authored declaratively within templates of data-bound
controls, their events are initially not synchroni*ed with those of other controls on the page. $or e0ample, for a
control that is added at run time, the Init and Load events might occur much later in the page life cycle than the
same events for controls created declaratively. Therefore, from the time that they are instantiated, dynamically
added controls and controls in templates raise their events one after the other until they have caught up to the
event during which it was added to the 'ontrols collection.
n general, you do not need to be concerned about this unless you have nested data-bound controls. f a child
control has been data bound, but its container control has not yet been data bound, the data in the child control
and the data in its container control can be out of sync. This is true particularly if the data in the child control
performs processing based on a data-bound value in the container control.
$or e0ample, suppose you have a ,rid:iew that displays a company record in each row along with a list of the
company officers in a ListBo$ control. To fill the list of officers, you would bind the ListBo$ control to a data
source control .such as S+l>ataSource/ that retrieves the company officer data using the 'ompany> in a +uery.
f the ListBo$ control2s data-binding properties, such as >ataSource> and >ata4ember, are set declaratively, the
ListBo$ control will try to bind to its data source during the containing row2s DataBinding event. 3owever, the
'ompany> field of the row does not contain a value until the +rid0ie# control2s 9ow>ata;ound event occurs. n
this case, the child control .the ListBo$ control/ is bound before the containing control .the +rid0ie# control/ is
bound, so their data-binding stages are out of sync.
To avoid this condition, put the data source control for the ListBo$ control in the same template item as the
ListBo$ control itself, and do not set the data binding properties of the ListBo$ declaratively. nstead, set them
programmatically at run time during the Ro#DataBound event, so that the ListBo$ control does not bind to its
data until the 'ompany> information is available.
$or more information, see ;inding to >ata -sing a >ata Source 'ontrol.
Data Binding Events ,or Data*Bound 'ontrols
To help you understand the relationship between the page life cycle and data binding events, the following table
lists data-related events in data-bound controls such as the +rid0ie#, >etails:iew, and $orm:iew controls.
'ontrol Event &!pical .se
DataBinding This event is raised by data-bound controls before the
PreRender event of the containing control .or of the Page
ob8ect/ and mar1s the beginning of binding the control to the
data.
-se this event to manually open database connections, if
re+uired. .The data source controls often ma1e this
unnecessary./
9ow'reated .+rid0ie# only/ or
tem'reated .>ata&ist, Details0ie#,
Site4apPath, >ata,rid, orm0ie#, and
9epeater controls/
-se this event to manipulate content that is not dependent on
data binding. $or e0ample, at run time, you might
programmatically add formatting to a header or footer row in a
+rid0ie# control.
Ro#DataBound .+rid0ie# only/ or
tem>ata;ound .DataList,
Site%apPath, Data+rid, and Repeater
controls/
)hen this event occurs, data is available in the row or item, so
you can format data or set the $ilterE0pression property on
child data source controls for displaying related data within the
row or item.
DataBound This event mar1s the end of data-binding operations in a data-
bound control. n a +rid0ie# control, data binding is complete
for all rows and any child controls.
-se this event to format data bound content or to initiate data
binding in other controls that depend on values from the
current control2s content. .$or details, see 7'atch-up Events for
Added 'ontrols7 earlier in this topic./
Login 'ontrol Events
The &ogin control can use settings in the )eb.config file to manage membership authentication automatically.
3owever, if your application re+uires you to customi*e how the control wor1s, or if you want to understand how
Login control events relate to the page life cycle, you can use the events listed in the following table.
'ontrol
Event &!pical .se
&oggingn This event is raised during a postbac1, after the page2s Load'omplete event has
occurred. t mar1s the beginning of the login process.
-se this event for tas1s that must occur prior to beginning the authentication process.
Authenticate This event is raised after the LoggingIn event.
-se this event to override or enhance the default authentication behavior of a Login
control.
&oggedn This event is raised after the user name and password have been authenticated.
-se this event to redirect to another page or to dynamically set the te0t in the control.
This event does not occur if there is an error or if authentication fails.
&oginError This event is raised if authentication was not successful.
-se this event to set te0t in the control that e0plains the problem or to direct the user to a
different page.
ASP.NET Pae Life Cycle Overview !.Net $.5#
)hen an ASP.NET page runs, the page goes through a life cycle in which it performs a series of processing steps.
These include initiali*ation, instantiating controls, restoring and maintaining state, running event handler code, and
rendering. t is important for you to understand the page life cycle so that you can write code at the appropriate
life-cycle stage for the effect you intend. Additionally, if you develop custom controls, you must be familiar with the
page life cycle in order to correctly initiali*e controls, populate control properties with view-state data, and run any
control behavior code. .The life cycle of a control is based on the page life cycle, but the page raises more events
for a control than are available for an ASP.NET page alone./
General Page Life-cycle Stages
n general terms, the page goes through the stages outlined in the following table. n addition to the page life-cycle
stages, there are application stages that occur before and after a re+uest but are not specific to a page. $or more
information, see ASP.NET Application &ife 'ycle (verview for S %.".
Stage Description
Page re+uest The page re+uest occurs before the page life cycle begins. )hen the page is re+uested
by a user, ASP.NET determines whether the page needs to be parsed and compiled
.therefore beginning the life of a page/, or whether a cached version of the page can be
sent in response without running the page.
Start n the start step, page properties such as 9e+uest and 9esponse are set. At this stage,
the page also determines whether the re+uest is a postbac1 or a new re+uest and sets
the sPost;ac1 property. Additionally, during the start step, the page2s -'ulture
property is set.
Page
initiali*ation
>uring page initiali*ation, controls on the page are available and each control2s -ni+ue>
property is set. Any themes are also applied to the page. f the current re+uest is a
postbac1, the postbac1 data has not yet been loaded and control property values have
not been restored to the values from view state.
&oad >uring load, if the current re+uest is a postbac1, control properties are loaded with
information recovered from view state and control state.
:alidation >uring validation, the :alidate method of all validator controls is called, which sets the
s:alid property of individual validator controls and of the page.
Postbac1 event
handling
f the re+uest is a postbac1, any event handlers are called.
9endering ;efore rendering, view state is saved for the page and all controls. >uring the rendering
phase, the page calls the 9ender method for each control, providing a te0t writer that
writes its output to the (utputStream of the page2s 9esponse property.
-nload -nload is called after the page has been fully rendered, sent to the client, and is ready to
be discarded. At this point, page properties such as 9esponse and 9e+uest are unloaded
and any cleanup is performed.
&ife-cycle Events
)ithin each stage of the life cycle of a page, the page raises events that you can handle to run your own code. $or
control events, you bind the event handler to the event, either declaratively using attributes such as onclic-, or in
code.
Pages also support automatic event wire-up, meaning that ASP.NET loo1s for methods with particular names and
automatically runs those methods when certain events are raised. f the AutoEvent"ireup attribute of the
G Page 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. $or more
information on automatic event wire-up, see ASP.NET )eb Server 'ontrol Event 4odel.
The following table lists the page life-cycle events that you will use most fre+uently. There are more events than
those listedH however, they are not used for most page processing scenarios. nstead, they are primarily used by
server controls on the ASP.NET )eb page to initiali*e and render themselves. f you want to write your own
ASP.NET server controls, you need to understand more about these stages. $or information about creating custom
controls, see >eveloping 'ustom ASP.NET Server 'ontrols.
Page Event &!pical .se
Prenit -se this event for the following5
'hec1 the sPost;ac1 property to determine whether this is the first time
the page is being processed.
'reate or re-create dynamic controls.
Set a master page dynamically.
Set the Theme property dynamically.
9ead or set profile property values.
Note:
f the re+uest is a postbac1, the values of the controls have not yet been
restored from view state. f you set a control property at this stage, its value
might be overwritten in the ne0t event.
nit 9aised after all controls have been initiali*ed and any s1in settings have been
applied. -se this event to read or initiali*e control properties.
nit'omplete 9aised by the Page ob8ect. -se this event for processing tas1s that re+uire all
initiali*ation be complete.
Pre&oad -se this event if you need to perform processing on your page or control before the
&oad event.
;efore the Page instance raises this event, it loads view state for itself and all
controls, and then processes any postbac1 data included with the 9e+uest instance.
&oad The Page calls the (n&oad event method on the Page, 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.
-se the (n&oad event method to set properties in controls and establish database
connections.
'ontrol events -se these events to handle specific control events, such as a ;utton control2s 'lic1
event or a Te0t;o0 control2s Te0t'hanged event.
Note:
n a postbac1 re+uest, if the page contains validator controls, chec1 the s:alid
property of the Page and of individual validation controls before performing any
processing.
&oad'omplete -se this event for tas1s that re+uire that all other controls on the page be loaded.
Pre9ender ;efore this event occurs5
The Page ob8ect calls Ensure'hild'ontrols for each control and for the
page.
Each data bound control whose >ataSource> property is set calls its
>ata;ind method. $or more information, see >ata ;inding Events for >ata-
;ound 'ontrols later in this topic.
The Pre9ender event occurs for each control on the page. -se the event to ma1e
final changes to the contents of the page or its controls.
SaveState'omplete ;efore this event occurs, :iewState has been saved for the page and for all controls.
Any changes to the page or controls at this point will be ignored.
-se this event perform tas1s that re+uire view state to be saved, but that do not
ma1e any changes to controls.
9ender This is not an eventH instead, at this stage of processing, the Page ob8ect calls this
method on each control. All ASP.NET )eb server controls have a 9ender method
that writes out the control2s mar1up that is sent to the browser.
f you create a custom control, you typically override this method to output the
control2s mar1up. 3owever, if your custom control incorporates only standard
ASP.NET )eb server controls and no custom mar1up, you do not need to override
the 9ender method. $or more information, see >eveloping 'ustom ASP.NET Server
'ontrols.
A user control .an .asc0 file/ automatically incorporates rendering, so you do not
need to e0plicitly render the control in code.
-nload This event occurs for each control and then for the page. n controls, use this event
to do final cleanup for specific controls, such as closing control-specific database
connections.
$or the page itself, use this event to do final cleanup wor1, such as closing open files
and database connections, or finishing up logging or other re+uest-specific tas1s.
Note:
>uring the unload stage, the page and its controls have been rendered, so you
cannot ma1e further changes to the response stream. f you attempt to call a
method such as the Response("rite method, the page will throw an e0ception.
Additional Page Life Cycle Considerations
ndividual ASP.NET server controls have their own life cycle that is similar to the page life cycle. $or e0ample, a
control2s nit and &oad events occur during the corresponding page events.
Although both nit and &oad recursively occur on each control, they happen in reverse order. The nit event .and
also the -nload event/ for each child control occur before the corresponding event is raised for its container
.bottom-up/. 3owever the &oad event for a container occurs before the &oad events for its child controls .top-
down/.
?ou can customi*e the appearance or content of a control by handling the events for the control, such as the 'lic1
event for the ;utton control and the Selectednde0'hanged event for the &ist;o0 control. -nder some
circumstances, you might also handle a control2s >ata;inding or >ata;ound events. $or more information, see the
class reference topics for individual controls and >eveloping 'ustom ASP.NET Server 'ontrols.
)hen inheriting a class from the Page class, in addition to handling events raised by the page, you can override
methods from the page2s base class. $or e0ample, you can override the page2s nitiali*e'ulture method to
dynamically set culture information. Note that when creating an event handler using the Page_event synta0, the
base implementation is implicitly called and therefore you do not need to call it in your method. $or e0ample, the
base page class2s (n&oad method is always called, whether you create a Page_Load method or not. 3owever, if
you override the page (n&oad method with the override 1eyword ./verrides in :isual ;asic/, you must e0plicitly
call the base method. $or e0ample, if you override the (n&oad method on the page, you must call )ase(Load
.%!Base(Load in :isual ;asic/ in order for the base implementation to be run.
'atch*up Events ,or Added 'ontrols
f controls are created dynamically at run time or are authored declaratively within templates of data-bound
controls, their events are initially not synchroni*ed with those of other controls on the page. $or e0ample, for a
control that is added at run time, the nit and &oad events might occur much later in the page life cycle than the
same events for controls created declaratively. Therefore, from the time that they are instantiated, dynamically
added controls and controls in templates raise their events one after the other until they have caught up to the
event during which it was added to the 'ontrols collection.
n general, you do not need to be concerned about this unless you have nested data-bound controls. f a child
control has been data bound, but its container control has not yet been data bound, the data in the child control
and the data in its container control can be out of sync. This is true particularly if the data in the child control
performs processing based on a data-bound value in the container control.
$or e0ample, suppose you have a ,rid:iew that displays a company record in each row along with a list of the
company officers in a &ist;o0 control. To fill the list of officers, you would bind the &ist;o0 control to a data source
control .such as S+l>ataSource/ that retrieves the company officer data using the 'ompany> in a +uery.
f the &ist;o0 control2s data-binding properties, such as >ataSource> and >ata4ember, are set declaratively, the
&ist;o0 control will try to bind to its data source during the containing row2s >ata;inding event. 3owever, the
'ompany> field of the row does not contain a value until the ,rid:iew control2s 9ow>ata;ound event occurs. n
this case, the child control .the &ist;o0 control/ is bound before the containing control .the ,rid:iew control/ is
bound, so their data-binding stages are out of sync.
To avoid this condition, put the data source control for the &ist;o0 control in the same template item as the &ist;o0
control itself, and do not set the data binding properties of the &ist;o0 declaratively. nstead, set them
programmatically at run time during the 9ow>ata;ound event, so that the &ist;o0 control does not bind to its data
until the 'ompany> information is available.
$or more information, see ;inding to >ata -sing a >ata Source 'ontrol.
>ata ;inding Events for >ata-;ound 'ontrols
To help you understand the relationship between the page life cycle and data binding events, the following table
lists data-related events in data-bound controls such as the ,rid:iew, >etails:iew, and $orm:iew controls.
'ontrol Event &!pical .se
>ata;inding This event is raised by data-bound controls before the
Pre9ender event of the containing control .or of the Page
ob8ect/ and mar1s the beginning of binding the control to the
data.
-se this event to manually open database connections, if
re+uired. .The data source controls often ma1e this
unnecessary./
9ow'reated .,rid:iew only/ or
tem'reated .>ata&ist, >etails:iew,
Site4apPath, >ata,rid, $orm:iew,
9epeater, and &ist:iew controls/
-se this event to manipulate content that is not dependent on
data binding. $or e0ample, at run time, you might
programmatically add formatting to a header or footer row in a
,rid:iew control.
9ow>ata;ound .,rid:iew only/ or
tem>ata;ound .>ata&ist, Site4apPath,
>ata,rid, 9epeater, and &ist:iew
controls/
)hen this event occurs, data is available in the row or item, so
you can format data or set the $ilterE0pression property on
child data source controls for displaying related data within the
row or item.
>ata;ound This event mar1s the end of data-binding operations in a data-
bound control. n a ,rid:iew control, data binding is complete
for all rows and any child controls.
-se this event to format data bound content or to initiate data
binding in other controls that depend on values from the
current control2s content. .$or details, see 7'atch-up Events
for Added 'ontrols7 earlier in this topic./
Login Control Events
The &ogin control can use settings in the )eb.config file to manage membership authentication automatically.
3owever, if your application re+uires you to customi*e how the control wor1s, or if you want to understand how
&ogin control events relate to the page life cycle, you can use the events listed in the following table.
'ontrol
Event &!pical .se
&oggingn This event is raised during a postbac1, after the page2s &oad'omplete event has occurred.
t mar1s the beginning of the login process.
-se this event for tas1s that must occur prior to beginning the authentication process.
Authenticate This event is raised after the &oggingn event.
-se this event to override or enhance the default authentication behavior of a &ogin
control.
&oggedn This event is raised after the user name and password have been authenticated.
-se this event to redirect to another page or to dynamically set the te0t in the control.
This event does not occur if there is an error or if authentication fails.
&oginError This event is raised if authentication was not successful.
-se this event to set te0t in the control that e0plains the problem or to direct the user to a
different page.