ASP.Net Application

The ASP.NET Mobile Web Application is a subtype of Web Application specific to developing for mobile devices such as cell phones and PDAs. The primary thing that distinguishes a mobile webapplication from a standard web application in ASP.NET is the use of the ASP.NET mobile controls, which are built into the .NET Framework as of Version 1.1. These include the mobile Form control and standard controls such as labels, textboxes, and panels, as well as mobile-specific controls such as the TextView, PhoneCall, and SelectionList controls. Note that both mobile Web Forms pages (those that use the mobile controls) and standard Web Forms pages can coexist within the same application, if desired.

To simplify development of ASP.NET applications for mobile devices, Visual Studio .NET 2003 provides an ASP.NET Mobile Web Application project template. This template includes a default mobile Web Form, as well as a special section added to the Web.config file called <deviceFilters>, which contains settings for device-specific rendering.

The other type of application available to ASP.NET developers is the ASP.NET WebService. Like ASP.NET Web Applications, there are a number of terms floating around for this type of application. (Microsoft refers to web services as “XML Web Services,” perhaps in hopes of a positive association between web services and the XML standard.) A web service is an application that exposes programmatic functionality to clients over the Internet or an intranet using the underlying plumbing of a developing W3C standard called SOAP. In simple terms, it can be seen as a simple function call across the Internet.

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. 

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 Chapters 13 and 19.

.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.

.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.

.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 Chapters 3 and 6.

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 thesrcattribute). We’ll discuss the use of code-behind classes and the choice of which attribute to use in greater detail in Chapters 3 and 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 webapplication 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.

.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.

.cs extension

The .csextension 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.