Configuration Files in

ASP .NET

Three Important Configuration Files in ASP .NET are

Web.Config
Machine.Config
Global.asax

Web.Config
Web.config file, as it sounds like is a configuration file for the
Asp .net Web Application

An Asp .net application has one web.config file which keeps the
configurations required for the corresponding application

Web.config file is written in XML with specific tags having

specific meanings
What can be stored in Web.config file?

There are number of important settings that can be stored in

the configuration file. Here are some of the most frequently
used configurations, stored conveniently inside Web.config file
1. Database Connections
2. Session States
3. Error Handling
4. Security

Database Connections
The most important configuration data that can be stored inside
the web.config file is the database connection string
Storing the connection string in the web.config file makes sense,
since any modifications to the database configurations can be
maintained at a single location
As otherwise we'll have to keep it either as a class level variable in
all the associated source files or probably keep it in another class
as a public static variable
<configuration>
<connectionStrings>
<add name=DBPersonString"
ConnectionString="server=localhost; uid=sa; pwd=*****;
database=DBPerson" />
</ connectionStrings >
</configuration>

 As you can see it is really simple to store the connection string in

the web.config file
The connection string is referenced by a name which in this case
is " DBPersonString
The ConnectionString attribute of the configuration file denotes
the information about the database. Here we can see that if has
database name, userid and password
Lets see how we access the connection string from our Asp .net
web application
using System.Configuration;
string connString =
ConfigurationManager.ConnectionStrings[DBPersonString].Conne
ctionString

Session State
A session is defined as the period of time that a unique user
interacts with a Web application. Session state is a collection of
objects, tied to a session are stored on a server
ASP.NET Session State
ASP.NET session state solves problems associated with classic ASP
session state
Process independent. ASP.NET session state is able to run in a
separate process from the ASP.NET host process. If session state
is in a separate process, the ASP.NET process can come and go
while the session state process remains available
Support for server farm configurations. By moving to an outof-process model, ASP.NET also solves the server farm problem.
The new out-of-process model allows all servers in the farm to
share a session state process. You can implement this by
changing the ASP.NET configuration to point to a common server
Cookie independent. Although solutions to the problem of
cookieless state management do exist for classic ASP, they're not
trivial to implement. ASP.NET, on the other hand, reduces the
complexities of cookieless session state to a simple configuration
setting

Session configuration
Session in Asp .net web application is very important. As we know
that HTTP is a stateless protocol and we needs session to keep the
state alive
Below is a sample web.config file used to configure the session
state settings for an ASP.NET application
<configuration>
<sessionstate
mode="inproc
cookieless="false
timeout="20
sqlconnectionstring="data source=127.0.0.1;user id=<user
id>;password=<password>
server="127.0.0.1
port="42424 />
</configuration>

 Mode. The mode setting supports three options: inproc, sqlserver,

and stateserver. As stated earlier, ASP.NET supports two modes: in
process and out of process. There are also two options for out-ofprocess state management: memory based (stateserver), and
SQL Server based (sqlserver). We'll discuss implementing these
options shortly.
Cookieless. The cookieless option for ASP.NET is configured with
this simple Boolean setting.
Timeout. This option controls the length of time a session is
considered valid. The session timeout is a sliding value; on each
request the timeout period is set to the current time plus the
timeout value
Sqlconnectionstring. The sqlconnectionstring identifies the
database connection string that names the database used for
mode sqlserver.
Server. In the out-of-process mode stateserver, it names the
server that is running the required Windows NT service: ASPState.
Port. The port setting, which accompanies the server setting,
identifies the port number that corresponds to the server setting
for mode stateserver

Attribute

Option

mode

Description
Specifies where to store the session state

Off

Disables session state management

InProc

Session state is stored locally in memory of

ASP.NET worker process

StateServer

Session state is stored outside ASP.NET

worker process and is managed by
Windows service. Location of this service is
specified by stateConnectionString attribute

SQLServer

Session state is stored outside ASP.NET

worker process in SQL Server database.
Location of this database is represented by
sqlConnectionString attribute

In-process Mode
In-process mode simply means using ASP.NET session state in a
similar manner to classic ASP session state. That is, session state
is managed in process and if the process is re-cycled, state is lost.
Given the new settings that ASP.NET provides, you might wonder
why you would ever use this mode. The reasoning is quite simple:
performance. The performance of session state, e.g. the time it
takes to read from and write to the session state dictionary, will
be much faster when the memory read to and from is in process,
as cross-process calls add overhead when data is marshaled back
and forth or possibly read from SQL Server.
In-process mode is the default setting for ASP.NET. When this
setting is used, the only other session web. config settings used
are cookieless and timeout.

Out-of-process Mode
State Server
There are two main advantages of using the State Service
First the state service is not running in the same process as the
asp .net application. So even if the asp .net application crashes
the sessions will not be destroyed
Second advantage is sharing the state information across a Web
garden (Multiple processors for the same computer)
Lets see a small example of the Session State Service.
<sessionState
mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:55455
cookieless="false
timeout="20
/>

SQL Server
To use Sql Server for storing session state you need to do the
following:
Run the InstallSqlState.sql script on the Microsoft SQL Server
where you intend to store the session.
You web.config settings will look something like this:
<sessionState mode = "SqlServer"
sqlConnectionString="data source="SERVERNAME; uid=sa;
password=****''
cookiesless="false
timeout="20
/>
SQL Server lets you share session state among the processors in
a Web garden or the servers in a Web farm. Apart from that you
also get additional space to store the session. And after that you
can take various actions on the session stored
The downside is SQL Server is slow as compared to storing
session in the state in process. And also SQL Server cost too
much for a small company

Error Handling
When errors occur in an ASP.NET application, they either get
handled or propagates unhandled to higher scopes
When an unhandled exception propagates, the user may be
redirected to an error page using different ASP.NET configuration
settings
There are two different scopes where we could specify which page
the user should be redirected to, when errors go unhandled:
Page level (applies to errors that happen within a single page)
Application level (applies to errors that happen anywhere in the
application)
Page Level
Use the errorPage attribute in the webform
<%@ Page language="c#" Codebehind="WebForm1.aspx.cs"
AutoEventWireup="false" Inherits="WebTest.WebForm1"
errorPage="/ErrorPages/PageError.html"%>

Application Level
Use the customErrors section in web.config
<customErrors mode="On defaultRedirect="/ErrorPages/AppError.html">
<error statusCode="404" redirect="/WebTest/ErrorPages/404.html" />
</customErrors>
The mode attribute specifies whether to show user-defined custom error
pages or ASP.NET error pages. Three values are supported for this
attribute:
RemoteOnly - Custom error pages are shown for all remote users.
ASP.NET error pages with rich error information are displayed only for
local users
On - Custom error pages are always shown, unless one is not specified.
When a custom error page is not defined, an ASP.NET error page will be
displayed which describes how to enable remote viewing of errors
Off - Custom error pages are not shown. Instead, ASP.NET error pages
will be displayed always, which will have rich error information

Machine.Config
As web.config file is used to configure one asp .net web
application, same way Machine.config file is used to configure the
application according to a particular machine
That is, configuration done in machine.config file is affected on
any application that runs on a particular machine
Usually, this file is not altered and only web.config is used which
configuring applications
It is present in the location
C:\WINDOWS\Microsoft.NET\Framework\<versionNumber>\CONF
IG

Global.asax
The Global.asax file, sometimes called the ASP.NET application
file, provides a way to respond to application or module level
events in one central location. You can use this file to implement
application security, as well as other tasks
Global.asax is a file that resides in the root directory of your
application
It is inaccessible over the web but is used by the ASP.NET
application if it is there
It is a collection of event handlers that you can use to change and
set settings in your site
The events can come from one of two places - The
HTTPApplication object and any HTTPModule object that is
specified in web.confg or machine.config. We will be covering both
here

Exposed Events
Application_Init: Fired when an application initializes or is first
called. It's invoked for all HttpApplication object instances.
Application_Disposed: Fired just before an application is destroyed.
This is the ideal location for cleaning up previously used resources.
Application_Error: Fired when an unhandled exception is
encountered within the application.
Application_Start: Fired when the first instance of the
HttpApplication class is created. It allows you to create objects that
are accessible by all HttpApplication instances.
Application_End: Fired when the last instance of an HttpApplication
class is destroyed. It's fired only once during an application's
lifetime.
Application_BeginRequest: Fired when an application request is
received. It's the first event fired for a request, which is often a
page request (URL) that a user enters.
Application_EndRequest: The last event fired for an application
request.
Application_PreRequestHandlerExecute: Fired before the ASP.NET
page framework begins executing an event handler like a page or
Web service.

Exposed Events
Application_PostRequestHandlerExecute: Fired when the ASP.NET
page framework is finished executing an event handler.
Applcation_PreSendRequestHeaders: Fired before the ASP.NET
page framework sends HTTP headers to a requesting client
(browser).
Application_PreSendContent: Fired before the ASP.NET page
framework sends content to a requesting client (browser).
Application_AcquireRequestState: Fired when the ASP.NET page
framework gets the current state (Session state) related to the
current request.
Application_ReleaseRequestState: Fired when the ASP.NET page
framework completes execution of all event handlers. This results
in all state modules to save their current state data.
Application_ResolveRequestCache: Fired when the ASP.NET page
framework completes an authorization request. It allows caching
modules to serve the request from the cache, thus bypassing
handler execution.

Exposed Events
Application_UpdateRequestCache: Fired when the ASP.NET page
framework completes handler execution to allow caching modules
to store responses to be used to handle subsequent requests.
Application_AuthenticateRequest: Fired when the security module
has established the current user's identity as valid. At this point,
the user's credentials have been validated.
Application_AuthorizeRequest: Fired when the security module has
verified that a user can access resources.
Session_Start: Fired when a new user visits the application Web
site.
Session_End: Fired when a user's session times out, ends, or they
leave the application Web site.

THANK YOU