ASP.

NET
Applications

 An ASP.NET application is a
combination of files, pages, handlers,
modules, and executable code that
can be invoked from a virtual
directory on a web server.
take a closer look at how an ASP.NET
application is configured and
deployed.
learn how to use components and
HTTP handlers with an ASP.NET
application.

The Application Domain

All the web pages in a single web
application share the same in-memory
resources, such as global application
data, per-user session data, and
cached data. This information isnt
directly accessible to other ASP.NET or
ASP applications.
All the web pages in a single web
application share the same core
configuration settings.

 All web applications raise global

application events at various stages
(when the application domain is first
created, when its destroyed, and so
on). You can attach event handlers
that react to these global application
events using code in the global.asax
file in your applications virtual
directory.

ASP.NET applications can include all of

the following ingredients:
virtual directory can hold a great deal
of additional resources that ASP.NET
web applications will use, including
stylesheets, images, XML files, and
so on.

 We can extend the ASP.NET model by

developing specialized components
known as HTTP handlers and HTTP
modules, which can plug into your
application and take part in the
processing of ASP.NET web requests.

Application Lifetime
ASP.NET uses a lazy initialization
technique for creating application
domains. This means that the
application domain for a web
application is created the first time a
request is received for a page in that
application.
ASP.NET automatically recycles
application domains when you
change the application.

Application Updates
ASP.NET performs the same
transition to a new application
domain that it performs when you
modify the web.config configuration
file.
However, its important to
understand the architecture that
makes it possible.
The CLR always locks assembly files
when it executes them.

 ASP.NET doesnt actually use the

ASP.NET files in the virtual directory.
The ASP.NET worker process loads
the assemblies from this directory.

 ASP.NETs ability to detect when you

change the original files.
ASP.NET maintains an active list of
all assemblies loaded within a
particular applications application
domain and uses monitoring code to
watch for changes and acts
accordingly.

Application Directory Structure

ASP.NET defines a few directories
with special meanings
Bin: This directory contains all the
precompiled .NET assemblies that
the ASP.NET web application uses.
App_Code: This directory contains
source code files that are
dynamically compiled for use in your
application.

 App_GlobalResources: This directory

stores global resources that are
accessible to every page in the web
application.
App_LocalResources: This directory
serves the same purpose as App_GR
except these resources are accessible
for their dedicated page only.
App_WebReferences: This directory
stores references to web services
that the web application uses. This
includes WSDL files and discovery
documents.

 App_Data: This directory is reserved

for data storage, including SQL
Server 2005 Express database files
and XML files.
App_Themes: This directory stores
the themes used by the web
application.
App_Browsers: This directory
contains browser definitions stored in
XML files. These XML files define the
capabilities of client-side browsers
for different rendering actions.

The global.asax
The global.asax file allows you to
write event handlers that react to
global events.

 every global.asax file defines the

methods for a single classthe
application class. The application
class derives from HttpApplication
A web application can have no more
than one global.asax file, and it must
reside in the root directory of the
application, not in a subdirectory.

Application Events
You can handle two types of events
in the global.asax file:
Events that always occur for every
request. These include requestrelated and response-related events.
Events that occur only under certain
conditions.

 Application_Start(): This method

is invoked when the application first
starts up and the application domain
is created. This event handler is a
useful place to provide applicationwide initialization code. For example,
at this point you might load and
cache data that will not change
throughout the lifetime of an
application.

 Session_Start(): This method is

invoked each time a new session
begins. This is often used to initialize
user-specific information.
Application_BeginRequest(): This
method is called at the start of every
request.
Application_AuthenticateRequest
(): This method is called just before
authentication is performed.

 Application_Error(): This method

is invoked whenever an unhandled
exception occurs in the application.
Session_End(): This method is
invoked whenever the users session
ends. A session ends when your code
explicitly releases it or when it times
out after there have been no more
requests received within a given
timeout period (typically 20
minutes). This method is typically
used to clean up any related data.

 Application_End(): This method is

invoked just before an application
ends. The end of an application can
occur because IIS is being restarted
or because the application is
transitioning to a new application
domain in response to updated files
or the process recycling settings.
Application events are commonly
used to perform application
initialization, cleanup, usage logging,
profiling, and troubleshooting.

 For example, the following

global.asax file reacts to the
HttpApplication.EndRequest event,
which happens just before the page
is sent to the user.
Application_Error

Interview Questions
What is global.asax in ASP.NET?
The global application class thats
used by the global.asax file should
always be stateless.
The global.asax file isnt the only
place where you can respond to
global web application events. You
can also create custom modules that
participate in the processing of web
requests.

ASP.NET Configuration
Configuration in ASP.NET is managed
with XML configuration files.
All the information needed to
configure an ASP.NET applications
core settings, as well as the custom
settings specific to your own
application, is stored in these
configuration files.

The machine.config File

The machine.config file defines supported
configuration file sections, configures the
ASP.NET worker process, and registers
providers that can be used for advanced
features such as profiles, membership, and
role-based security.
relevant settings by opening the new
machine.config.comments file, full text for
the standard settings along with
descriptive comments
Using the machine.config.comments file,
you can learn about the default settings,
and then you can add settings that
override these values to machine.config.

 Along with the machine.config file, ASP.NET

uses a root web.config file that contains
additional settings. All the web applications on
the computer inherit the settings in these two
files. However, most of the settings are
essentially plumbing features that you never
need to touch.

<processModel>
This section allows you to configure how
the ASP.NET worker process recycles
application domains, and the Windows
account it executes under, which
determines its privileges.

 The section group we want to look at

is <system.web>, which includes the
settings that tell your system just
how ASP.NET should run on your
machine.
The <system.runtime.remoting>
section group includes settings for
managing how remoting behaves on
your machine.
We'll find all the various ways you
may configure items such as session
state, authentication, page
compilation, and debug settings.

<machineKey>
This section allows you to set the
server-specific key used for encrypting
data and creating digital signatures.
You can use encryption in conjunction
with several ASP.NET features. ASP.NET
uses it automatically to protect the
forms authentication cookie, and you
can also apply it to protected view state
data

 Ordinarily, the <machineKey> element

takes this form:
<machineKey
validationKey="AutoGenerate,IsolateApps"
decryptionKey="AutoGenerate,IsolateApps
" validation="SHA1" />
The AutoGenerate,IsolateApps value
indicates that ASP.NET will create and
store machinespecific, application-specific
keys. In other words, each application
uses a distinct, automatically generated
key.

 validationKey. This specifies the key that

the HMAC algorithm uses to make
ViewState tamper proof.
The validationKey value can be from 40 to
128 characters long.
decryptionKey. This specifies the key
used to encrypt and decrypt data.
The decryptionKey value can be either 16
or 48 characters long.
validation. This specifies the hashing
algorithm used to generate HMACs to
make ViewState and forms authentication
tickets tamper proof.
SHA1 , MD5 , AES , 3DES

The web.config File

The web.config file in a web application
cant override all the settings in the
machine.config file.
process model settings, cant be
changed on a per-application basis.
New Configuration Sections for ASP.NET
3.5:
system.codedom:Configures your page
to use the latest version of the C#
compiler.

 system.web.extensions: Allows you

to enable some ASP.NET AJAX
features.
system.webServer: Configures the
ASP.NET AJAX features to work under
IIS 7.
configSections: Registers the
optional <system.web.extensions>
element, so that ASP.NET recognizes
it and knows how to process its data.

 Configuration Inheritance
ASP.NET uses a multilayered
configuration system that allows you to
use different settings for different parts
of your application.
consider the web request
http://localhost/A/B/C/MyPage.aspx,
where A is the root directory for the web
application.
One reason you might want to use
multiple directories in an application is to
apply different security settings.

 If settings conflict, the settings from

a web.config in a nested directory
always override the settings inherited
from the parent.
However, one exception exists. You
can designate specific locked
sections that cant be changed.

<location> :
The <location> element is an
extension that allows you to specify
more than one group of settings in
the same configuration file.
You use the path attribute of the
<location> element to specific the
subdirectory or file to which the
settings should be applied.

<configuration>
<system.web>
<!-- Basic configuration settings go
here. -->
</system.web>
<location path="/Secure">
<system.web>
<!-- Configuration settings for the
Secure subdirectory go here. -->
</system.web>
</location>
</configuration>

 This web.config file essentially plays

the role of two configuration files.
But there is one scenario where the
<location> element gives you
functionality you cant get any other
way.
This occurs when you want to lock
specific settings so they cant be
overridden.
<location allowOverride="false">
<system.web>
<!-- Locked configuration here. -->
</system.web>

 <system.web> Settings:
The <system.web> element contains
all the ASP.NET-specific configuration
settings.
These settings configure various
aspects of your web application and
enable services such as security,
state management, and tracing.
Authentication, authorization,
compilation, customErrors, identity,
httpHandlers, httpModules, pages,
sessionState, trace

 <customErrors>
This element allows you to configure
the behavior of your application in
response to various HTTP errors.

 On: Indicates that custom errors are

enabled. If no defaultRedirect
attribute is supplied, users will see a
generic error.
Off: Custom errors are disabled. This
allows full error details to be
displayed.
RemoteOnly: Custom errors are
shown only to remote clients while
full detailed errors are displayed to
local clients.

 custom error settings you define in a

configuration file come into effect only
if ASP.NET is handling the request.
if you request the nonexistent page
whateverpage.aspx
youll be redirected to filenotfound.htm
if you request the nonexistent page
whateverpage.html, ASP.NET will not
process the request,

<connectionStrings>
This section allows you to define
database connection strings that will be
used elsewhere in your application.
modified without recompiling the web
application

<appSettings>
You add custom settings to a
web.config file in a special element
called <appSettings>.
Custom settings are entered using an
<add> element that identifies a
unique variable name (the key) and
the variable contents (the value).
Email-Program:

Reading and Writing

Configuration Sections
Programmatically
ASP.NET provides the
WebConfigurationManager class in the
System.Web.Configuration namespace, which
allows you to extract information from a
configuration file at runtime.
The WebConfigurationManager class gives
convenient access to two configuration
sections:
<appSettings> section, and the
<connectionStrings> section

 example that displays information about

the assemblies that are currently
referenced:
example that rewrites the application
settings shown earlier so that it updates
one of the settings

Website Administration
Tool (WAT)
WAT to automate the web.config
changes
You make your changes using a
graphical interface (a web page), and
the WAT generates the settings you
need and adds them to the
web.config file for your application
behind the scenes.

 Simple Mail Transfer Protocol

(SMTP) is an Internet standard for
electronic mail (e-mail) transmission
across Internet Protocol (IP)
networks.
SMTP is the protocol in widespread
use today.
While electronic mail servers and
other mail transfer agents use SMTP
to send and receive mail messages