ASP.NET.in.a.Nutshell.Second.Edition [Electronic resources] نسخه متنی

2.3 Application File Types

A number of different file types are
associated with an ASP.NET application, and it's
important to understand the purpose of each type, even if you
aren't using all of them in your current
applications. In this section, we'll look at the
major file types associated with ASP.NET Web Applications and web
services and what each of them does.

2.3.1 web.config Files

web.config is the file
type used for configuration of various settings within an ASP.NET
application. Applications may contain more than one

web.config file (though there may be only one
per directory or subdirectory), and the

web.config files are applied in an hierarchical
fashion. What this means is that if you have defined a particular
setting (such as the user accounts permitted to access that
directory) in the

web.config file at the root of
your application, this setting applies to the application and all of
its subdirectories, if it has any. You can override that setting for
a particular subdirectory by using a

web.config
file in a subdirectory of the application. The

web.config files use an XML-based syntax, and
both the tag names and their attributes are case-sensitive.

web.config provides configuration settings for:

• Application-specific settings, such as connection string information
  (since the

  web.config file resides within the
  web application's file space, it is probably best to
  avoid storing sensitive information such as passwords in plain text
  in a configuration file, or at all, if that's
  feasible).

• Authentication and authorization.

• Browser capabilities (mapping specific functionality to the
  information retrieved from a User Agent string).

• Compilation settings, including whether an application should be run
  in debug or release mode.

• Custom error handling information.

• Globalization settings.

• HttpHandlers and
  HttpModules associated with the
  application.

• HttpRuntime
  settings.

• Application Identity and encryption/decryption key settings.

• ASP.NET Page defaults (for the @
  Page directive).

• ASP.NET Process settings, including settings for Web Gardens, and
  proactive restart of applications based on memory used or number of
  requests received.

• Code-access security settings, including mappings of trust levels to
  security policy files, and trust setting for an application.

• Session state settings, including whether to run Session state in
  process, out of process, or in SQL Server.

• Application Trace settings. Tracing is a useful new feature for
  debugging and troubleshooting that we'll discuss in
  Chapter 10.

• Web service settings.

Note that

web.config is an optional file. Any
configuration settings not set in a

web.config
file within the application will be inherited from the server-level
configuration file,

machine.config . A sample

web.config file is shown in Example 2-3.

Example 2-3. Sample web.config file

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<compilation 
defaultLanguage="c#"
debug="true"/>
<trace
enabled="true"
requestLimit="10"
pageOutput="false"
traceMode="SortByTime"
localOnly="true"/>
<sessionState 
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;user id=sa;password="
cookieless="false" 
timeout="20"/>
</system.web>
</configuration>

We'll discuss how to make changes to

web.config , and the syntax of the various
configuration sectionsChapter 8.

2.3.2 global.asax Files

global.asax performs a
similar function in ASP.NET that

global.asa
performs in classic ASP. That is, it is an optional file that may
contain code to respond to Application- or Session-level events. Like

global.asa in classic ASP, there can be only one

global.asax file per ASP.NET application. Unlike
the

global.asa file in classic ASP, which was
parsed, the

global.asax application file is
compiled at runtime into a .NET managed assembly ultimately derived
from the HttpApplication class. In addition to
handling Application- and Session-level events, such as
Session_OnStart,

global.asax also allows you to
handle events raised by HttpModules associated with your application
(in fact, the Session state in ASP.NET is implemented as an
HttpModule, so its events are already handled this way).

The

global.asax file can be constructed one of
two ways. The file can contain the event handlers and other code you
want associated with your application directly, or it can reference a
code-behind class file that contains the event handlers and code to
associate with the application. Note that the code-behind used, if
any, must inherit from the HttpApplication class
in the System.Web namespace. The latter is the way that the

global.asax files in ASP.NET applications
created with Visual Studio .NET are constructed. Example 2-4 shows a typical

global.asax file that uses code-behind, while
Example 2-5 shows the code-behind file it uses.

Example 2-4. global.asax using code-behind

<% -- Global.asax file-- %>
<%@ Application Codebehind="Global.asax.vb" Inherits="<namespacename>. Global" %>

Example 2-5. Code-behind file for global.asax in Example 2-4

'Global.asax.vb codebehind file
Imports System.Web
Imports System.Web.SessionState
Public Class Global
Inherits System.Web.HttpApplication
Sub Application_BeginRequest(ByVal sender As Object, _
ByVal e As EventArgs)
' Fires at the beginning of each request
End Sub
Sub Application_AuthenticateRequest(ByVal sender As Object, _
ByVal e As EventArgs)
' Fires upon attempting to authenticate the user
End Sub
Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
' Fires when an error occurs
End Sub
End Class

We'll discuss the uses of the

global.asax file in more detail in Chapter 13 and Chapter 19.

2.3.3 .aspx Files

.aspx files, also
known as ASP.NET pages or Web Forms, are the meat and potatoes of an
ASP.NET Web Application. These files contain the HTML tags, server
controls, and code that present a user interface to your users, and
process their requests (or call helper functions in business-tier
components to do so). Like the

global.asax file,

.aspx files may either contain code directly or
refer to a code-behind class that contains the code for that page.
Note that the code-behind used, if any, must inherit from the
Page class in the System.Web.UI namespace.
We'll discuss

.aspx files in
detail in Chapter 3.

2.3.4 .asmx Files

.asmx files are the files used to implement
ASP.NET Web Services. These files contain the methods, marked with
the WebMethod attribute, that will be exposed by
your application as web services. Like

global.asax and

.aspx
files,

.asmx files may either contain code
directly or refer to a code-behind class that implements the methods
to be exposed as web services. Note that the code-behind used, if
any, must inherit from the WebService class in the
System.Web.Services namespace We'll discuss

.asmx files in detail in Chapter 4.

2.3.5 .ascx Files

.ascx files are used to implement what are
known as ASP.NET user controls. User controls are a technique for
code reuse that lies somewhere between the function of the
#Include directive in classic ASP (which you can
still use in ASP.NET, if you choose) and the function of custom
ASP.NET Server Controls. User controls are made up of HTML tags,
server controls, and code (or any combination of the above), and can
be reused through a simple tag-based syntax. They have the advantages
of being simpler to develop than custom server controls, as well as
offering greater functionality than includes (such as the ability to
expose properties and methods). We'll discuss user
controls further in Chapter 3 and Chapter 6.

2.3.6 Code-Behind and Class Files

In addition to the file types mentioned here, you'll
also frequently deal with code-behind and/or
class files. A
code-behind file, also known as a code-behind class file, is a file
containing .NET managed code (such as VB.NET or C#) that defines a
class from which an ASP.NET page file, web service file, or
application file inherits. This inherited relationship is indicated
by the codebehind or
src attribute, which indicates the file containing
the code-behind class, and the inherits attribute,
which indicates the namespace name (if any) and the class name of the
class to inherit. Example 2-4 shows these attributes
in action. At runtime, when the page, the web service, or the
application is initialized for the first time, the ASP.NET runtime
locates the code-behind file and either executes the compiled
assembly associated with it (in the case of the
codebehind attribute, which is used when the class
will be precompiled) or compiles the class into an assembly
dynamically (in the case of the src attribute).
We'll discuss the use of code-behind classes and the
choice of which attribute to use in greater detail in Chapter 3 and Chapter 4.

Class files are simply source code files containing .NET managed code
that is organized into namespaces and classes and that has been
compiled before deployment, using either the Visual Studio .NET
environment or the appropriate command-line compiler, into a .NET
managed assembly. Class files are typically kept separate from the
web application in which their assemblies are used, just as the
source code for COM components used in classic ASP applications is
typically kept separate from the web tree.

2.3.6.1 .vb extension

The

.vb extension
indicates source code files written in Visual Basic .NET. By default,
code-behind classes created by the Visual Studio .NET environment use
the naming convention
filename.parentfileextension.languageextension.
Thus, a VB.NET code-behind file for an ASP.NET page might have the
name

WebForm1.aspx.vb . This naming convention
clearly conveys the relationship between the code-behind file and the
page that inherits from it, as well as the language used in the
code-behind file, so you can adopt this naming convention or use a
similar one, even when not developing in the Visual Studio .NET
environment.

2.3.6.2 .cs extension

The

.cs extension indicates source code files
written in Microsoft's new C# (pronounced "C
Sharp") language. These files, when created by
Visual Studio .NET, use the same naming convention as the one just
described.