ASP.NET offers many improvements over classic ASP. The topics to be covered in this chapter highlight several of the major improvements in controlling, configuring, and deploying ASP.NET applications.
ASP.NET provides easy control of the entire application through the global.asax file. This text file allows you to create event handlers for a wide variety of events exposed by both the application as a whole and by individual sessions. You can also include methods and server-side include files which will apply globally to the entire application.
Configuration of web applications is handled using configuration files: machine.configand web.config. These XML files provide a flexible and hierarchical configuration scheme. Configuration settings can apply to every application on the web server, to specific applications, or to specific subdirectories within an application.
Since all of the configuration and control for ASP.NET applications is done with text files, either XML or some other variant of plain text, it is very easy to maintain and update a web application remotely. It is no longer necessary to be physically present at a web server to reconfigure the application through IIS.
Perhaps the single greatest improvement that .NET has made over previous generations of development environments is in the area of deployment:
DLLs only have to be located in a specific directory to be visible to an application.
There is no registration of objects, either in the Registry or elsewhere, required for an application to utilize the contents of a DLL. Installation does not require any registering of components with regsrvr32 or any other utility, though some globally available components will be placed in the Global Assembly Cache.
XCOPY installations are here.
There are no versioning issues with conflicting DLLs.
All of this will be described fully in this chapter. In the meantime, shout it from the rooftops: No more DLL hell!
The term application has been used throughout this book. Everyone knows intuitively, more or less, what an application is. Here is a precise working definition for a web application: An application consists of all of the web pages, files, code, objects, executables, images, and other resources located in an Internet Information Server (IIS) virtual directory (described shortly) or a subdirectory of that virtual directory.
The application will start the first time any page or web service is requested from the web server. It will run until any of a number of events cause it to shut down. These events include:
Editing global.asax, a server-side include file for global.asax, or a web.config file
Restarting IIS
Restarting the machine
If a page is requested and the application is not running, the application will automatically restart.
Unlike traditional EXE applications, web applications do not have a fixed starting point. A user can drop in through any number of paths or entry points. Web applications should be designed accordingly.
For example, a virtual directory may contain three web pages: default.aspx, login.aspx, and bugs.aspx. If you enter the following text at a browser:
http://localhost
you will go to default.aspx, which may send you to login.aspx. On the other hand, registered users may enter:
http://localhost/login.aspx
to go directly to the login page. In any event, once logged in, they can go to bugs.aspx. If someone tries going directly to bugs.aspx without logging in, your code must send them to login.aspx to log in first.
Classic ASP and new ASP.NET applications can coexist side-by-side on the same server. In fact, they can coexist in the same application directory. However, configuration, application, and session objects cannot be shared between them. They are totally distinct and independent.
Virtual directories inIIS are central to web applications. A virtualdirectory is any directory on the server, or accessible to the server, that has been designated as such in IIS. Virtual directories are isomorphic with applications; that is, each virtual directory is a separate application, and each application must have a single virtual root directory. When a new project is created in Visual Studio .NET, the application virtual directory is created automatically. When a new application is created using a text editor, you the developer must create the virtual directory using IIS, as described below.
Virtual directories are accessible to requests from browsers coming
in over the Internet. The URL is the name of the domain name,
followed by the virtual directory. For example, if an application
with a starting web page called MyPage.aspx was
using a virtual directory called ProgAspNet, and
the domain name of the hosting web server was
SomeDomainName.com, the URL to access that
application would be:
www.SomeDomainName.com/ProgAspNet/MyPage.aspx
To create, look at, or modify virtual directories in IIS, click on
the Start button, then Settings → Control Panel,
then Administrative Tools. Now you have a choice of two approaches:
click on either
Internet Services Manager or Computer Management.
From either, you get the Microsoft Management Console (MMC), which is used throughout Windows for displaying and controlling many system functions. In the left pane is a hierarchical tree structure showing resources relevant to the aspect(s) of the computer being managed. The right pane contains the child nodes of the currently selected node on the left.
Looking at Computer Management, the tree on the left has top-level nodes for System Tools, Storage, and Services and Applications. Drilling down through Services and Applications, then Internet Information Services, to the default Web Site, the MMC window should look something like that shown in Figure 20-1.
Internet Services Manager is identical to Computer Management except that the tree on the left starts with Internet Information Services.
Drilling further down, click on Default Web Site. The contents of the default web site will be visible, as shown in Figure 20-2. The default web site, by default, is the physical directory c:inetpubwwwroot. When IIS is installed on a machine, it creates this directory, along with several subdirectories (beginning with the underscore character). If you go to a browser and enter the URL:
http://localhost
you will see the contents of the default web site. If your web server is accessible over the Internet through a domain name, a remote user at a browser who entered that domain name as a URL, say for example:
www.SomeDomainName.com
would see the same thing.
You will not actually see anything in the browser unless one of the following conditions is true:
A suitably named file (default.htm, default.asp, default.aspx, or iisstart.asp) containing a default web page exists in the physical directory.
Directory Browsing is enabled by right clicking on Default Web Site, going to the Home Directory tab in the Default Web Site Properties dialog box, and checking the Directory browsing checkbox.
Tip
Note that enabling Directory Browsing can be a serious gap in security, so it is generally not something to do on a production site unless there is a good reason.
Compare the contents of the default web site in Figure 20-2 with the actual contents of c:inetpubwwwroo
t shown
in Figure 20-3. You can see that all the files and
directories actually in the physical directory are also in the
default web site in Figure 20-2. These physical
directories, such as images and
_private, are normal directories
with standard Explorer-style directory icons.
Other directories in the default web site shown in Figure 20-2, such as _vti_bin and Scripts, have a directory icon with a small globe on the lower-right corner. These are virtualdirectories, created either by IIS or by a developer.
Finally, some of the directories in the default web site shown in Figure 20-2 have an icon that looks like a cardboard box with a green thing inside (it’s a package, get it?). These are webapplicationdirectories . They can be either physical directories or virtual directories. The virtual directories created by developers are also application directories by default. This can be changed by right-clicking on the directory in question in the left pane, selecting Properties, then clicking either the Create Application Settings button to make it an application directory, or the Remove Application Settings button to convert the directory to a plain vanilla virtual directory.
When a new web application or web service is created in Visual Studio .NET, it automatically creates a physical directory under c:inetpubwwwroot with the same name as the application or web service. This new physical directory is also both a virtual directory and an application directory.
You can make a new virtual directory outside Visual Studio .NET using
the Computer Management window shown in
Figure 20-2 (or the equivalent
Internet Services Manager window)
by right clicking on Default Web Site in the left pane, selecting
New... → Virtual Directory, and following the
wizard. Once the new virtual directory is created, you can
right-click on it and select Properties to modify its properties.
Back in Chapter 2, you created a virtual directory
called ProgAspNet. This was
mapped to the physical directory c:myProject
s. In order
to access this virtual directory, enter one of the following URLs
from a browser, depending on whether you are on a local machine or
accessing the
application
over the
Internet:
http://localhost/ProgAspNet www.SomeDomainName.com/ProgAspNet
Each application is run in its own applicationdomain, which is created by the runtime server. Each application domain is isolated from every other application domain. If one application crashes or otherwise compromises its own stability, it cannot affect any other domains. This greatly enhances security and stability.
Since each application is independent from any other application, this also means that each application has its own independent configuration and control structures.
All the files that comprise a .NET application are gathered into an assembly. Assemblies are the basic units of .NET programming. They appear to the user as a single dynamic link library (DLL) or executable (EXE) file. DLLs contain classes and methods, which are linked into an application at runtime as they are needed. Assemblies also contain versioning information so that multiple versions of the same code can run side-by-side with no conflicts.
Assemblies must be physically located somewhere; these locations are called the assemblycache . There are two general types of assembly cache: global and application. In order to for a class or method to be visible to an ASP.NET application, the DLL containing the class or method must be located in the assemblycache, either global or application.
The Global Assembly Cache (GAC) is used to store modules that need to be available to all the applications on a server. It is typically located at c:winntassembly. The Global Assembly Cache will be discussed in Section 20.4 later in this chapter.
The application assembly cache contains compiled methods and classes specific to the application. Each application directory has a special in subdirectory to contain the application assembly cache. All that is necessary to “register” your DLL with an application is to copy it to the in directory. Any class or method in any DLL in the in directory is automatically visible to all web pages and services in the application (i.e., in the directory that is the parent directory of the in directory).