Build Your Own ASP.NET 3.5 Website Using C# & VB (33 page)

We hinted earlier that, as an aid for VB users, the default
Web.config
file generated

by Visual Web Developer also contains a number of namespace references:

Dorknozzle\VB\01_web.config
(excerpt)

Licensed to [email protected]

174

Build Your Own ASP.NET 3.5 Web Site Using C# & VB

⋮

We can use classes from these namespaces in our code without needing to reference

them in every file in which they’re used. In any case, even if Visual Web Developer

tries to offer an extra level of assistance for VB developers, users of C# (or any other

language) can use these techniques as well, and add the namespace references to

Web.config
.

You’ll learn more about working with
Web.config
as you progress through this book,

so if you wish, you can skip the rest of these details for now, and come back to them

later as you need them.

The
Web.config
file’s root element is always configuration, and it can contain three

different types of elements:

configuration section groups

As ASP.NET and the .NET Framework are so configurable, the configuration

files could easily become jumbled if we didn’t have a way to break them into

groups of related settings. A number of predefined section grouping tags let you

do just that. For example, settings specific to ASP.NET must be placed inside

a system.web section grouping element, while settings that are relevant to .NET’s

networking classes belong inside a system.net element.

General settings, like the appSettings element we saw above, stand on their

own, outside the section grouping tags. In this book, though, our configuration

files will also contain a number of ASP.NET-specific settings, which live inside

the system.web element.

Licensed to [email protected]

Building Web Applications

175

configuration sections

These are the actual setting tags in our configuration file. Since a single element

can contain a number of settings (for example, the appSettings element we

saw earlier could contain a number of different strings for use by the application),

Microsoft calls each of these tags a
configuration section
. ASP.NET provides a

wide range of built-in configuration sections to control the various aspects of

your web applications.

The following list outlines some of the commonly used ASP.NET configuration

sections, all of which must appear within the system.web section grouping

element:

authentication

outlines configuration settings for user authentication, and is covered in

detail in
Chapter 13

authorization

specifies users and roles, and controls their access to particular files within

an application; discussed more in
Chapter 13

compilation

contains settings that are related to page compilation, and lets you specify

the default language that’s used to compile pages

customErrors

used to customize the way errors display

globalization

used to customize character encoding for requests and responses

pages

handles the configuration options for specific ASP.NET pages; allows you

to disable session state, buffering, and view state, for example

sessionState

contains configuration information for modifying session state (that is,

variables associated with a particular user’s visit to your site)

trace

contains information related to page and application tracing

Licensed to [email protected]

176

Build Your Own ASP.NET 3.5 Web Site Using C# & VB

configuration section handler declarations

ASP.NET’s configuration file system is so flexible that it allows you to define

your own configuration sections. For most purposes, the built-in configuration

sections will do nicely, but if we want to include some custom configuration

sections, we need to tell ASP.NET how to handle them. To do so, we declare a

configuration section handler for each custom configuration section we want

to create. This is fairly advanced stuff, so we won’t worry about it in this book.

Global.asax

Global.asax
is another special file that can be added to the root of an application. It defines subroutines that are executed in response to application-wide events. For

instance, Application_Start is executed the first time the application runs (or just

after we restart the server). This makes this method the perfect place to execute any

initialization code that needs to run when the application loads for the first time.

Another useful method is Application_Error, which is called whenever an unhandled error occurs within a page. The following is a list of the handlers that you’ll use most often within the Global.asax file:

Application_Start

called immediately after the application is created; this event occurs once only

Application_End

called immediately before the end of all application instances

Application_Error

called by an unhandled error in the application

Application_BeginRequest

called by every request to the server

Application_EndRequest

called at the end of every request to the server

Application_PreSendRequestHeaders

called before headers are sent to the browser

Application_PreSendRequestContent

called before content is sent to the browser

Licensed to [email protected]

Building Web Applications

177

Application_AuthenticateRequest

called before authenticating a user

Application_AuthorizeRequest

called before authorizing a user

The
Global.asax
file is created in the same way as the
Web.config
file—just select
File

>
New File…
, then choose the
Global Application Class
template, as depicted in
Fig-

ure 5.17
.

Figure 5.17. Creating
Global.asax

Clicking
Add
will create in the root of your project a new file named
Global.asax
, which contains empty stubs for a number of event handlers, and comments that

explain their roles. A typical event handler in a
Global.asax
file looks something like this:

Visual Basic

Sub Application_
EventName
(ByVal sender As Object,

➥ ByVal e As EventArgs)

⋮
code triggered by this event…

End Sub

Licensed to [email protected]

178

Build Your Own ASP.NET 3.5 Web Site Using C# & VB

C#

void Application_
EventName
(Object sender, EventArgs e)

{`

⋮
code triggered by this event…

}

Be Careful when Changing Global.asax

Be cautious when you add and modify code within the
Global.asax
file. Any additions or modifications you make within this file will cause the application to restart, so you’ll lose any data stored in application state.
Using Application State

You can store the variables and objects you want to use throughout an entire application in a special object called Application. The data stored in this object is called
application state
. The Application object also provides you with methods that allow

you to share application state data between all the pages in a given ASP.NET application very easily. Application state is closely related to another concept:
session state
. The key difference between the two is that session state stores variables and objects for one particular user for the duration of that user’s current visit, whereas application state stores objects and variables that are shared between all users of an application at

the same time. Thus, application state is ideal for storing data that’s used by all

users of the same application.

In ASP.NET, session and application state are both implemented as
collections
, or

sets of name-value pairs. You can set the value of an application variable named

SiteName like this:

Visual Basic

Application("SiteName") = "Dorknozzle Intranet Application"

C#

Application["SiteName"] = "Dorknozzle Intranet Application";

Licensed to [email protected]

Building Web Applications

179

With SiteName set, any pages in the application can read this string:

Visual Basic

Dim appName As String = Application("SiteName")

C#

string appName = (string)Application["SiteName"];

You might have noticed the term (string) in the C# code example above. This is

an example of the task of casting a variable to a specific type.
Casting
is the act of ensuring that a value is converted to a specific data type so that it can be stored in

a variable of a matching data type. In the above example the value stored in Application["SiteName"] is actually one of type object and must be cast to a string in order to be able to be stored in a string variable. We don’t have to worry about

such issues in the VB code example above, because the data type conversion takes

place automatically.

We can remove an object from application state using the Remove method, like so:

Visual Basic

Application.Remove("SiteName")

C#

Application.Remove("SiteName");

If you find you have multiple objects and application variables lingering in application state, you can remove them all at once using the RemoveAll method:
Visual Basic

Application.RemoveAll()