Internet Information Server (IIS) Objects
IIS supplies many objects that can be used by hosting platforms such as ASP
and ASP.NET. These objects aren't new in ASP.NET梩hey're the same objects
(with a few new properties) that you might have used in an ASP application.
You can use these objects to return information about your application and
your IIS server. ASP.NET makes all these objects available to you from the
code in your Web Form's code-behind file.
The Response Object
The Response object allows you to place information into the HTML stream
prior to sending a complete HTML page back to the client. For example, you
could include code such as this to insert text directly into the rendered
output:
Response.Write("An invalid password was entered")
The Request Object
The Request object allows you to receive information from the user.
Requests can be input fields on an HTML page or values passed on the URL.
The following code retrieves the value from a text box on the requesting
page:
strLastName = Request("txtLastName").ToString()
The Request object can also retrieve information from a URL. For example,
given the URL
http://www.yoursite.com/YourPage.aspx?Keyname=John
as entered from the browser, you could retrieve the Keyname parameter using
code like this:
Request.QueryString("KeyName")
The Session Object
IIS creates a Session object globally, once for each user's session. Using
this object, you can retrieve and set properties such as Session.TimeOut
and Session.SessionID. The TimeOut property indicates how long to wait for
a user to respond to a page before IIS kills the session. The SessionID
property is a unique long integer value that corresponds to this specific
session. The Session object also provides a dictionary-type collection of
name/value pairs. You can also add and retrieve your own variables within
this object. The following code takes a value from the Request object and
stores it as a Session variable for later reuse:
Session("LoginID") = Request("txtLoginID")
If you run this same line of code again, it will replace the contents in
the LoginID session variable with the updated contents of the txtLoginID
value. The Session object and all its contents are destroyed when a user
leaves a site or when the session times out.
TIP
You may have discovered that using Session and Application objects梐nd
their associated dictionaries of values梬asn't a good idea in ASP because
of scalability issues and because of the need to save data as cookies on
the user's computer. These issues have been handled in ASP.NET, and you'll
learn more about state management in Chapter 23.
The Application Object
IIS supplies another global object, Application. IIS creates this object
the first time a user comes to a Web site. You might use the Application
object to store a database connection string. Because the connection
information doesn't need to change from user to user, the Application
object is a perfect place to store this type of information. For example,
the following code stores a connection string so that it can be accessed at
any time within your site's processing:
Application("ConnectString") = _
"Provider=sqloledb;Initial Catalog=Employees;" & _
"Data Source=DataServer"
The Server Object
The Server object has some properties that relate to information in the IIS
server. You might call the MapPath method if you need to return a hyperlink
to a file on the server in a virtual directory. Here's an example:
strPath = Server.MapPath("EmpMaint")
The preceding code might return the following for a specific Web site:
d:\inetpub\wwwroot\EmpWeb\EmpMaint
The global.asax File
The global.asax file is similar to the global.asa file in ASP, although
there are more events available in ASP.NET. Also, just as ASP.NET compiles
the code in every page regardless of which language you use to create the
code-behind file (as opposed to interpreting the code, as in ASP), the code
in global.asax is fully compiled as well. ASP.NET allows you to handle a
sequence of site-wide events using code in your global.asax file. Table 6.5
lists the event procedures available to you within the global.asax file.
Table 6.5. Event Procedures Available Within global.asax Event Procedure
Description
Application_Start Raised when the first user hits your Web site.
Application_End Raised when the last user in the site's session times
out.
Application_Error Raised when an unhandled error occurs in the
application.
Session_Start Raised when any new user hits your Web site.
Session_End Raised when a user's session times out or ends.
Application_AcquireRequestState Raised when ASP.NET acquires the current
state (for example, session state) associated with the current request.
Application_AuthenticateRequest Raised when a security module establishes
the identity of the user.
Application_AuthorizeRequest Raised when a security module verifies user
authorization.
Application_BeginRequest Raised when ASP.NET starts to process the
request, before other per-request events.
Application_Disposed Raised when ASP.NET completes the chain of execution
when responding to a request.
Application_EndRequest Raised as the last event during the processing of
the request, after other prerequest events.
Application_PostRequestHandlerExecute Raised right after the ASP.NET
handler (such as a page or XML Web Service) finishes execution.
Application_PreRequestHandlerExecute Raised just before ASP.NET begins
executing a handler (such as a page or XML Web Service).
Application_PreSendRequestContent Raised just before ASP.NET sends content
to the client.
Application_PreSendRequestHeaders Raised just before ASP.NET sends HTTP
headers to the client.
Application_ReleaseRequestState Raised after ASP.NET finishes executing
all request handlers. This event causes state modules to save the current
state data.
Application_ResolveRequestCache Raised after ASP.NET completes an
authorization event to let the caching modules serve requests from the
cache, bypassing execution of the handler (the page or Web Service, for
example).
Application_UpdateRequestCache Raised after ASP.NET finishes executing a
handler in order to let caching modules store responses that will be used
to serve subsequent requests from the cache.
