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 sections, in Chapter 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.