When you create a new project, the project template you choose determines whether your project is web-based. A web-based project is one that is accessed or managed via a web protocol, such as HTTP, HTTPS, or FTP. The list of web project templates is listed in Table 4-1.
Project template |
Managed |
Description |
Output |
---|---|---|---|
ASP.NET Web Application (C#/VB/J#) |
Yes |
ASP.NET Web Forms Application |
Managed DLL and content files |
ASP.NET Web Service (C#/VB/J#/MC++) |
Yes |
ASP.NET Web Service |
Managed DLL and content files |
ASP.NET Mobile Web Application |
Yes |
ASP.NET Web Forms Applications for mobile devices |
Managed DLL and content files |
Empty Web Project (C#/VB/J#) |
Yes |
An empty project to which to add source and content files |
Managed DLL and content files |
ATL Server (VC++) |
No |
ATL-based web application |
Unmanaged DLL and content files |
ATL Server Web Service (VC++) |
No |
ATL-based web service |
Unmanaged DLL and content files |
Although web projects look like normal projects when viewed in the IDE, they behave quite differently behind the scenes. Any content files (web pages, graphics, etc.) must reside on a web server; the same is true for the build output (a managed or unmanaged DLL).
VS.NET has two completely different strategies for ensuring that all of the necessary files are in the right place. One is used by C#, VB.NET, and J# projects, and the other is used by Visual C++ projects. We will talk about each separately, in Section 4.2" and Section 4.3" later in this chapter. Before we do that, we need to talk about IIS web applications, since both types of projects depend on the separation provided by web applications to function properly.
In IIS, every directory is considered to be either a nonvirtual directory or a virtual directory. Nonvirtual directories are stored under the web server's root directory. A virtual directory can be anywhere on the server's filesystem, but the URL that is used to access that content makes it appear to the end user that it is physically below the root directory (hence the term virtual).
For example, suppose that the web server root is in the default location, c:\inetpub\wwwroot. If that directory were to contain a file called default.htm, a web browser would use the address http://server/default.htm to access that resource. If there were a directory at c:\inetpub\wwwroot\dir1 containing a file foo.htm, then the URL would be http://server/dir1/foo.htm. dir1 would be a nonvirtual directory within the web server's root directory. The structure of nonvirtual directories is presented directly through the structure of the URLs used to access their contents.
IIS does not force us to have such a strict mapping between URLs and the structure of our filesystem. Virtual directories allow us more flexibility. For example, we could use the IIS administration tool (located in the Administrative Tools section of the Control Panel) to map the e:\website directory as a virtual directory called dir2. (A virtual directory can have a different name than the actual directory on which it is based.) If e:\website contains a page.htm file, a web browser could access this with the URL http://server/dir2/page.htm. Because we set up a virtual directory called dir2, IIS will map the request for /dir2/page.htm to the e:\website\page.htm.
A web application is a directory tree with its own application settings. These application settings include security configuration, error handling, and file extension mappings. By default, a directory (virtual or not) will belong to its parent directory's application. However, any directory can be set as having its own application, at which point it gets its own settings. (Of course, these settings will propagate to any subdirectories that do not have their own application.)
You make a directory the root of a web application using the IIS administration utility. Open the directory's Properties page by right-clicking on the directory in the tree and selecting Properties from the context menu. If the directory is not a web application directory (i.e., if it picks up its application settings from its parent), you will be able to turn it into a web application by clicking on the Create button in the Application Settings section of the Directory tab, which is shown in Figure 4-1. (If the directory is already a web application, in place of a Create button, you will see a Remove button, enabling you to remove the web applicationthis will cause the directory to revert to using its parent's settings.)
|
A web server will always have at least one web applicationeven if you do not create any web applications of your own, there is an application for the web server's home directory. You can configure this from the Properties page for the web site itself. The tab has a different name in this caseit is labeled Home Directory instead of just Directory, but it otherwise works in the same way.
Once you create an application by clicking the Create button, all of the code in that application and all of the directories below it (at least those that are not applications themselves) now share application-wide settings. In an ASP application, Session and Application state are scoped by the web application. Process isolation settings are also configured on a per-application basis. In ASP.NET, the Session and Application state are partitioned in a similar way, but the process isolation settings are ignored in favor of an ASP.NET worker process.
|
Whenever you create a new web project, VS.NET creates a new web application (unless an appropriate one already exists). This means there is a one-to-one mapping between VS.NET web projects and IIS web applications. For a .NET web project, VS.NET will also create a bin directory underneath the web application directory. The bin directory is where VS.NET places the project's build output. (ASP.NET automatically loads any assemblies in the bin directory into the web application's AppDomain.)
.NET Framework VersionsVisual Studio .NET 2003 shipped with Version 1.1 of the .NET Framework. This was the second release of the .NET Framework, and it saw the introduction of so-called side-by-side support. Side-by-side support simply means that multiple versions of a software product may be installed simultaneously on a single machine. The idea is that if you have applications that have been developed on and regression tested against Version 1.0 of the .NET Framework, you can carry on running those applications against that version even though you may have newer applications on the same machine using Version 1.1 or later. Normal executable files indicate which version of the framework they require using settings in their file headers. However, for web applications, this is not good enoughthe ASP.NET Framework will be up and running long before any executable files get loaded, so we must use a different technique to indicate which version of the framework we require. The .NET Framework version is chosen on a per-web application level. By default, a newly created web application will use the latest version of the framework on the machine, but it is easy to downgrade to an earlier versioneach version of the framework ships with a tool called aspnet_regiis.exe that can do this. It is vitally important that you run the right copy of this toolif you have multiple versions of the .NET Framework, you will have multiple copies. The tool is typically found here:
(The final directory indicates the version numberthis is the normal location for Version 1.0.) Having located the correct version of the tool, simply run it thus: aspnet_regiis -s W3SVC/1/ROOT/WebApp where WebApp is the name of the web application that requires the old version of the framework. The aspnet_regiis utility can also be used to set up the IIS default application configuration. This is useful when you have installed IIS after installing the .NET Frameworkif IIS is not present when the framework is installed, it obviously cannot be configured. Running aspnet_regiis with the -i switch will perform this configuration. |