The easiest job a web server has is to provide ordinary HTML pages. When you request such a file, the web server simply reads it off the hard drive (or retrieves it from an in-memory cache) and sends the complete document to the browser, which displays it. In this case, the web server is just a glorified file server that waits for network requests and dishes out the corresponding documents.

When you use a web server in conjunction with dynamic content such as an ASP.NET page, something more interesting takes place. On its own, the web server has no idea how to process ASP.NET tags or run VB code. However, it's able to enlist the help of the ASP.NET engine to perform all the heavy lifting. Figure 26-1 diagrams how this process works for ASP and ASP.NET pages. For example, when you request the page Default.aspx, the web server sends the request over to the ASP.NET engine (which starts automatically if needed). The ASP.NET engine loads the requested page, runs the code it contains, and then creates the final HTML document, which it passes back to IIS. IIS then sends the HTML document to the client.

Figure 26.1. How IIS handles a request

At this point, you might be wondering how the web server knows when it needs to get the ASP or ASP.NET engine involved. Essentially, the web server looks at the file extension of the requested page (such as .asp or .aspx) to determine the type of content. The web server compares this extension against a list to determine what program owns this file type. For example, the web server's list indicates that the .aspx extension is owned by the aspnet_isapi.dll component in a folder like c:WindowsMicrosoft.NETFramework64v4.0.30319 directory (assuming you're using version 4.0.3319 of .NET on a 64-bit system).

All web servers perform the same task as that shown in Figure 26-1. However, when you run an ASP.NET application in Visual Studio, you don't need to worry about deployment and file type registration. That's because Visual Studio includes a built-in web server. It receives the requests for the pages in your web application and then runs the corresponding code. This test web server has a significant limitation—it only accepts requests from the local computer. In other words, there's no way for other people on other computers to access your website.

To run your web application outside the development environment, you need a more powerful web server. The web server software runs continuously on your computer (or, more likely, a dedicated server). This means it's ready to handle HTTP requests at any time and provide your pages to clients who connect from the same network or over the Internet. On Microsoft Windows operating systems, the web server you'll use is IIS.

In most cases, you won't be developing on the same computer you use to host your website. If you do, you will hamper the performance of your web server by tying it up with development work. You will also frustrate clients if a buggy test application crashes the computer and leaves the website unavailable or if you accidentally overwrite the deployed web application with a work in progress. Generally, you'll perfect your web application on another computer and then copy all the files to the web server.

When you deploy your web application to a web server, it's exposed through something called a virtual directory. A virtual directory is simply the public face of your website directory.

For example, your website might exist in a directory on the server named c:MySite. To allow remote users to access this website through their browsers, you could expose it as a virtual directory. The virtual directory name might match the real directory name (in this case, MySite), or it might be something different. When the user requests a page in a virtual directory (say, http://WebServer/MySite/Checkout.aspx), the web server looks for the corresponding file in the corresponding physical directory (c:MySiteCheckout.aspx). You'll learn more about this process—how URL requests are processed by the web server—in the next section.

You can use ASP.NET applications in a variety of different environments, including local area networks (LANs) and over the Internet. To understand the difference, it helps to review a little about how web servers work with networks and the Internet.

A network is defined simply as a group of devices connected by communication links. A traditional LAN connects devices over a limited area, such as within a company site or an individual's house. Multiple LANs are connected into a wide area network (WAN) using a variety of technologies. In fact, the Internet is nothing more than a high-speed backbone that joins millions of LANs.

The cornerstone of the Internet is Internet Protocol (IP). On an IP network, each computer is given a unique number called an IP address. An IP address is typically written as four numbers from 0 to 255 separated by periods (as in 192.145.0.1) or as six hexadecimal values separated by colons (as in 2001:db8:85a3::8a2e:370:7334). The difference depends on the version of the IP standard that you're using—the older, more common IPv4 standard uses the first approach, while the newer IPv6 uses the second. Either way, to access another computer over a network, you need to use its IP address.

Of course, IP addresses aren't easy to remember and don't make for great marketing campaigns. To make life easier, web servers on the Internet usually register unique domain names such as www.microsoft.com. This domain name is mapped to the IP address by a special catalog, which is maintained by a network of servers on the Internet. This network, called the Domain Name Service (DNS), is a core part of the infrastructure of the Internet. When you type http://www.microsoft.com in a web browser, the browser contacts a DNS server, looks up the IP address that's mapped to www.microsoft.com, and contacts it.

So, what effect does all this have on the accessibility of your website? To be easily reached over the Internet, the web server you use needs to be in the DNS registry. To get in the DNS registry, you must have a fixed IP address. Commercial Internet service providers won't give you a fixed IP address unless you're willing to pay a sizable fee. In fact, most will place you behind a firewall or some type of network address translation (NAT), which will hide your computer's IP address. The same is true in most company networks, which are shielded from the outside world.

ASP.NET applications don't need to be accessible over the Internet. Many are useful within an internal network. In this case, you don't need to worry about registered domain names. Other computers can access your website using either the IP address of your machine or, more likely, the network computer name.

For example, imagine you deploy an application to a virtual directory named MyWebApp. On the web server, you can access it like this:

http://localhost/MyWebApp

Assuming the computer is named MyWebServer, here's how you can access the virtual web directory on another computer on the same LAN:

http://MyWebServer/MyWebApp

Now, assume that MyWebServer is registered in the DNS as www.MyDomain.com and is exposed to the Internet. You could then use the following URL:

http://www.MyDomain.com/MyWebApp

Finally, you can always use the computer's IP address, provided the computer is on the same network or visible on the Internet. Assuming the IP address is 123.5.123.4, here's the URL you would use:

http://123.5.123.4/MyWebApp

Because internal networks often use dynamic IP addresses and because DNS registration changes, using the computer name or domain name to access a website is almost always the best approach.

If you study the URLs that the built-in web server in Visual Studio uses, you'll notice they're a little different than what you usually see when surfing the Internet. Namely, they include a port number. That means instead of requesting a page like this:

http://localhost/MyWebApp/Default.aspx

you might request a page like this:

http://localhost:2040/MyWebApp/Default.aspx

That's because the Visual Studio web server watches requests on a dynamically chosen port number. (In this example, the port number is 2040, but you'll see that it changes each time you run Visual Studio.) By using a dynamic port number, Visual Studio makes sure its built-in web server doesn't infringe on any other web server software you have on the computer.

Real web servers are almost always configured to monitor port 80 (and port 443 for encrypted traffic). If you don't type in a port number for a URL, the browser assumes you're using port 80 for ordinary web access and port 443 for secure connections.

Some applications run on web farms, a group of server computers that share the responsibility of handling requests. Usually web farms are reserved for high-powered web applications that need to be able to handle heavy loads, because multiple computers can deal with more simultaneous surfers than a single web server. However, web farms are overkill for many small and midsized websites.

The way a web farm works is deceptively simple. Essentially, instead of placing web application files on a single web server, you place a copy on several separate web servers. When a request is received for your website, it's directed to one of these web servers (based on which one has the lightest load). That web server then deals with the request. Obviously, if you decide to update your application, you need to make sure you update each web server in the web farm with the same version to prevent discrepancies.

Some web hosting companies use web farms to host multiple websites. For example, your website might be running on more than one web server, but each of these web servers might also host multiple websites. This provides a flexible deployment model that lets different web applications share resources. However, web farms also introduce a few new challenges. If you're setting up a web farm of your own, you'll need to make sure each computer uses the same machine key, as described later in this chapter in the section "The Machine Key."

IIS exists in several different versions. The version of IIS you use depends on the operating system you're using:

As a general rule, when you want to publish your website, you should use a server version of Windows to host it. Desktop versions, such as Windows Vista and Windows 7, are fine for development testing, but they implement a connection limit, which makes them less suitable for real-world use. Most editions of Windows 7 and Windows Vista limit IIS to ten simultaneous connections, including Business, Professional, Enterprise, and Ultimate. The Home Premium edition of both operating systems ratchets the limit down to three simultaneous requests, while the Home Basic and Starter editions don't support IIS at all.

Before you can start using IIS, you need to make sure the web server computer has the required IIS software. The following sections provide a high-level overview of the process. They tell you where to go to find IIS and switch it on, depending on the version of Windows that you're using.

The process for enabling IIS 7.5 (in Windows 7) or IIS 7 (in Windows Vista) is the same. In both versions of Windows, IIS is included but not initially installed. To switch it on, you need to follow these steps:

The initial release of Windows Server 2008 used IIS 7, just like Windows Vista. However, Windows Server 2008 was soon replaced by Window Server 2008 R2—a refreshed edition with performance enhancements, bug fixes, and a few new features. One of those features is IIS 7.5.

The setup and configuration of IIS is essentially the same in both releases of Windows Server 2008 (and with both versions of IIS). You use the Server Manager to configure the server computer. The basic process is as follows:

When you're ready to deploy a website on a computer that has IIS, the first step you'll usually take is to create the physical directory where the pages will be stored (for example, c:MySite). The second step is to expose this physical directory as a virtual directory through IIS. This means the website becomes publicly visible to other computers that are connected to your computer. Ordinarily, a remote computer won't be allowed to access your c:MySite directory. However, if you map c:MySite to a virtual directory, the remote user will be able to request the files in the directory through IIS.

Before going any further, choose the directory you want to expose as a virtual directory. You can use any directory you want, on any drive, and you can place it as many levels deep as makes sense. You can use a directory that already has your website files, or you can copy these files after you create the virtual directory. Either way, the first step is to register this directory with IIS.

The easiest and most flexible way to create a virtual directory is to use the IIS Manager utility. Here's what you need to do:

When you finish these steps, you'll see your new virtual directory appear in the list in IIS Manager.

You can remove an existing virtual directory by selecting it and pressing the Delete key, or you can change its settings by selecting it and using the icons in the Features View on the right.

Once you've created your virtual directory, fire up a browser to make sure it works. For example, if you've created the virtual directory with the alias MyApp and it contains the page MyPage.aspx, you should be able to request http://localhost/MyApplication/MyPage.aspx.

One of the slightly unusual details of website management is that some settings are set on the website itself (on the virtual directory), while others are applied through a feature called application pools. This two-part design allows for more efficient management, because you don't need to duplicate the application pool settings (which very rarely need to be changed) for each new web application. Instead, you can reuse a single application pool for all your websites. And if you modify the application pool later, all the linked web applications are affected.

Before you examine how to create and change application pools, you need to understand that application pools are quite limited in scope. Most web application configuration is performed through the virtual directory. The web application pool sets a small group of low-level settings that apply only to ASP.NET applications, such as the maximum number of requests to put on hold before sending a "Service Unavailable" response to new clients (by default, it's 1000) and the number of times the website should be allowed to crash catastrophically before being shut down altogether (by default, 5). Although these settings are interesting, most shouldn't be touched by anyone but a seasoned network administrator. In most cases, the default values are the best bet.

However, application pools include two settings that are uniquely important and may require your customization:

To take a look at the application pools defined on your computer, expand the IIS Manager tree, and click the Application Pools item that's nested under your computer name, before the Sites group (Figure 26-5).

Figure 26.5. The standard application pools

When you first install IIS, you start with a couple of basic application pools named DefaultAppPool and Classic .NET AppPool. When you install ASP.NET, the installation program creates two more IIS application pools—ASP.NET v4.0 and ASP.NET v4.0 Classic.

When you look at the application pool list, you can quickly pick out several details, such as the version of .NET that the application pool uses, whether it runs in classic mode or the more modern integrated mode, and how many applications are currently assigned to that pool. For example, in Figure 26-5, one application is assigned to the ASP.NET v4.0 pool, while the other pools have no web applications at all.

Here's a quick rundown of the essential tasks you can perform when viewing application pools in IIS Manager:

Figure 26.6. Basic application pool settings

Some of the subtlest issues with ASP.NET deployment involve security. When the web server runs your web application, it performs all its work under a specific Windows user account that has a carefully limited set of privileges. The actual account that's used depends on the web server you're using:

New ASP.NET programmers often ask why ASP.NET code doesn't run under another account—say, the account of the user who is making the request from the browser. However, if you consider this situation, you'll quickly realize the problems. It's almost certain that the end user doesn't have a Windows account defined on the web server. Even if the user has a corresponding user account, that account shouldn't have the same rights as the ASP.NET engine.

The trick is to use an account that's limited enough that it can't be abused by attackers but still has the required permissions to run your code. Both the application pool account and the network account achieve that goal, because they have a set of carefully limited privileges.

By default, the ASPNET account won't be allowed to perform tasks such as reading the Windows registry, retrieving information from a database, or writing to most locations on the local hard drive. On the other hand, it will have the permissions that are essential for normal functioning. For example, the ASPNET account is allowed to access the c:WindowsMicrosoft.NETFramework64 v4.0.30319Temporary ASP.NET Files directory so it can compile and cache web pages.

The limited security settings of the ASPNET and network service accounts are designed to prevent attacks on your web server. In most cases, the goal is to prevent any attacks that could exploit flaws in your application and trick it into undertaking actions that it's technically allowed to do (such as deleting a file) but should never perform. Although this is a worthwhile goal, you'll probably find that your applications require some additional permissions beyond those given to the ASPNET and network service accounts. For example, you might need access to a specific file or a database. To make this possible, you grant additional permissions to these accounts in the same way you would grant them to any other Windows user account. However, the process isn't always obvious—so you might want to consult a good handbook about Windows system administration before you take these steps.

Alternatively, you might want to change the account that's used to run the worker process to a different account with the required permissions. The following sections explain how.

Changing the ASP.NET Account

The Windows account is one of the advanced settings that's associated with an application pool. To change it, select the appropriate application pool, and click Advanced Settings in the Actions pane on the right. The setting you need to change is Identity (Figure 26-7).

Figure 26.7. Advanced application pool settings

To change the Identity setting, select it, and then click the ellipsis (...) button on the right side of the property box. The Application Pool Identity window will appear (Figure 26-8). It gives you two choices:

Use a built-in account:

Choose one of the predefined account types from the "Built-in account" list, including ApplicationPoolIdentity (in IIS 7.5 only), Network Service (the low-privileged account used by default in IIS 7), Local Service (which is similar to network service, but without the ability to access network locations), or Local System (which runs as an administrator with extensive privileges).

Use a custom account:

Choose "Custom account," click Set, and then supply a user name and password for a specific account. If you take this approach, the information you enter is encrypted on the web server, so it can't be dug up by crafty hackers.

Figure 26.8. Changing the application pool account

When you make your change in this way, you affect all the web applications that use the application pool. Another option is to create a new application pool first, using the Add Application Pool command from the Actions pane. You can then configure this application pool to use a specific user account.

The application pool allows you to modify a small number of low-level settings. But the vast majority of tweakable options are set directly on your website. To see these, select the web application in the IIS Manager tree, and look at the array of icons that appears in the Feature view on the right (Figure 26-9).

Figure 26.9. The icons for website configuration

The website configuration settings are split into three broad groups, which are arranged alphabetically: ASP.NET, IIS, and Management.

The IIS Configuration Icons

The IIS settings are more general than the ASP.NET settings. They apply to any virtual directory, including those that contain ordinary HTML pages and no ASP.NET content. However, many of the IIS settings also have an important effect on the way ASP.NET works, such as those that configure security. Although there's no way to cover all the options in a single chapter, here's a rundown of the highlights:

Authentication:

This configures the protocols that IIS uses to authenticate people, if your website uses Windows authentication (Chapter 19). You'll learn about this in the "Windows Authentication" section later in this chapter.

Default Document:

This sets the page that IIS will return by default, if it receives a request for a virtual directory with no page specified (for example, http://localhost/MySite). You'll learn how this work in the "The Default Page" section.

Directory Browsing:

Use this to allow directory browsing (which is generally appropriate only for a test web server, not a live web server with your deployed application). To turn on directory browsing, double-click this icon, and then click the Enable link in the Actions pane. Now, if you request the virtual directory with no page information (for example, http://localhost/MySite) and there's no default document in that directory, IIS will return an automatically generated HTML page with a directory listing. You can browse the page you want by clicking it (see Figure 26-10), as you can with the Visual Studio test server. This convenience may make testing easier.

Error Pages:

Use this to designate custom error pages that IIS will show when it encounters common problems. You'll see how they work in the "Custom Error Pages" section, later in this chapter.

Request Filtering:

This specifies the file types that IIS won't serve. For example, if IIS receives a request for .config, .cs, .vb, or .mdf file, it denies it based on this list of excluded file extensions. You can add new restricted file extensions or remove those that don't apply (however, this must be done carefully, or you risk opening up a security vulnerability in your application).

SSL Settings:

Use this to configure your website to require secure SSL connections. You'll learn more about SSL in the "Confidentiality with SSL and Certificates" section later in this chapter.

Figure 26.10. A website that allows directory browsing

Note

A few IIS features apply to the entire computer. The icons for these features appear only when you select your computer in the IIS tree. One example is the Server Certificates icon described in the "Confidentiality with SSL and Certificates" section.

Consider the virtual directory http://localhost/MySite. A user can request a specific page in this directory using a URL such as http://localhost/MySite/MyPage1.aspx. But what happens if the user simply types http://localhost/MySite into a web browser?

In this case, IIS will examine the list of default documents that are defined for that virtual directory. To see the default documents, select the virtual directory, and double-click the Default Document icon (in the IIS section).

IIS scans the default document list from top to bottom and returns the first matching page. Using the list in Figure 26-11, IIS will check first for a Default.htm file and then for Default.asp, index.htm, index.html, iisstart.asp, and default.aspx, which is the home page that most ASP.NET applications use. If IIS doesn't find any of these pages, either it will return an error message or, if you've enabled the Browse permission (which usually you won't), it will provide a file list.

Figure 26.11. The default document list

You can easily modify the default document list using the links in the Actions pane on the right. Click Add to insert a new default document, click Remove to remove an existing one, and use the Move Up and Move Down links to rearrange the order IIS uses when checking for default documents.

In any web page request, there are a number of errors that can occur. The user may attempt to request a restricted file, the file may not exist, the server may be too busy, or the page itself may generate an unhandled exception. Ordinarily, IIS deals with these errors in one of ways. If you're requesting the page locally (from a browser that's actually running on the web server), it returns the rich error page shown in Figure 26-12. If you're making the request from another computer, IIS keeps good security in mind and returns a much terser description of the problem, as shown in Figure 26-13.

Figure 26.12. An error for a local request

Figure 26.13. An error for a remote request

Custom error pages allow you to replace the standard server-generated pages with something a bit nicer. For example, you can show an apologetic, user-friendly error messages that describes the problem, provides an e-mail link to contact the administrator, or just looks generally less intimidating than the terse computer jargon of a standard error message.

To configure custom error pages, select the virtual directory, and double-click the Error Pages icon (in the IIS section). You'll see a list of HTTP errors that are mapped to specific HTML error pages (as shown in Figure 26-14). You can add or remove items or double-click an error to choose a different HTML file. You can also click the Edit Feature Settings link in the Actions pane to set a default error page (which is used when no other list entry applies).

Figure 26.14. IIS custom errors

By default, IIS keeps showing rich error pages (like the one in Figure 26-12) for local requests. But if you want to test your rich error pages, you can turn off this feature. Just click the Edit Feature Settings link, and choose the "Custom error pages" option, instead of "Detailed errors for local requests and custom error pages for remote requests."

As you learned earlier in this chapter, some organizations use groups of web servers that work together to host web applications. This arrangement, called a web farm, has some side effects.

For example, if you decide to use session state in a web farm, you must use StateServer or SQLServer mode, as described in Chapter 9. Otherwise, a user's session information might get trapped on one server. If a subsequent request is directed to another server, the information will be lost, and a new session will be created. Another wrinkle occurs with view state (discussed in Chapter 9) and forms authentication (Chapter 18). The problem in both cases is the same—ASP.NET encodes some information to prevent tampering and verifies the information later. For example, with view state, ASP.NET adds a hash code, which double-checks the next time the page is posted back to make sure the user hasn't changed the hidden view state field (in which case the request is rejected). The problem that can happen with web farms is that the hash code one web server creates might not match the hash code expected by another web server that uses a different secret key. As a result, if a page is posted back to a web farm and a different web server gets involved, an error can occur.

To resolve this problem, you must configure each web server in the web farm to use the same key. With a web hosting provider, this detail should already be configured. If you have your own web farm, it won't be—the default is for each server to create its own random key. So, obviously, these keys won't match.

To configure web servers to use the same key, select the website, and double-click the Machine Key icon (in the ASP.NET section). Then, clear all the four check boxes (which tell IIS to automatically generate application-specific keys). Finally, enter the validation key and decryption key in the two provided text boxes (Figure 26-15), and then click the Apply link in the Actions pane.

Figure 26.15. Entering fixed keys

As long as you set all the servers in the web farm to use the same key, they can share view state and use other features, such as forms authentication. Of course, you can't create the key string on your own and have it be sufficiently random. (To the human eye, the validation key and decryption key simply look like longs strings of meaningless characters.) Instead, on the first web server, you can ask IIS to generate two sufficiently random keys by clicking the Generate Keys link in the Actions pane on the right side.

In Chapter 19, you learned two different ways to restrict unknown users from accessing your website choice. The first choice is to use ASP.NET's built-in forms security system, which uses a login page to authenticate a new user (usually, by comparing a user name and password against a database record) and an authentication cookie to keep track of each logged-in user. The second choice is to use Windows authentication to force each person to supply the credentials of a valid Windows account that's defined on the web server (or another server on the network). This technique is more specialized and less common, but it's sometimes used inside small companies, especially when creating internal web applications that have a small set of known users.

It's easy enough to test a website that uses Windows authentication, because the Visual Studio web server automatically logs in the current user under the current Windows account. But on a real web server, you need to configure IIS before it can perform the same task. That's because IIS supports several different protocols that it can use when authenticating a user with Windows authentication. Depending on your network and the level of security you want, you need to choose the right one. Table 26-1 describes your options.

The IIS documentation has more about these different authentication methods. However, choosing the one that's right for your network environment may involve a long discussion with your friendly neighborhood network administrator.

Before you can use any type of Windows authentication, you need to install the appropriate support for IIS. (By default, it's an optional feature that isn't included.) To add support, open the Control Panel, choose Programs and Features, and then click the link "Turn Windows features on or off." Head to the Internet Information Services

Figure 26.16. Installing support for authentication methods

Once you have the authentication features you need installed, you simply need to select your website in IIS manager and double-click the Authentication icon (in the IIS group). Now you'll see whatever authentication options you've installed. Figure 26-17 shows an example on a web server that supports Integrated Windows authentication.

Figure 26.17. Configuring Windows authentication

You can enable more than one authentication method. In this case, the client will use the strongest authentication method it supports, as long as anonymous access is not enabled. If anonymous access is enabled, the client will automatically access the website anonymously, unless the web application explicitly denies anonymous users with this rule in the web.config file:

<deny users="?" />

A certificate allows you to demonstrate that your site and your organization information are registered and verified with a certificate authority. This generally encourages customer confidence, although it doesn't guarantee the company or organization acts responsibly or fairly. A certificate is a little like a driver's license—it doesn't prove you can drive, but it demonstrates that a third party (in this case, a department of the government) is willing to attest to your identity and your qualifications. Your web server also requires a certificate in order to use SSL, which automatically encrypts all the information sent between the client and server.

To add a certificate to your site, you first need to purchase one from a certificate authority. These are some well-known certificate authorities:

Creating a Certificate Request

The first step in the process of getting a certificate is to e-mail a certificate request for your web server. IIS Manager allows you to create a certificate request automatically. To do so, choose your computer in the IIS Manager tree, and double-click the Server Certificates icon. Then, click Create Certificate Request in the Actions pane to start the Request Certificate Wizard (shown in Figure 26-18).

Figure 26.18. Requesting a certificate

The Request Certificate Wizard collects some basic information, such as your address, the strength of encryption key you would like (the higher the bit length, the stronger the key), and so on. At the end of the process, you'll create a key request. You can save the generated file as a text file, but you must ultimately e-mail it to a certificate authority. The certificate authority will return a certificate, which you can install by clicking Complete Certificate Request in the Actions pane.

Tip

If you don't want to go to the trouble of buying a certificate, you can create a test certificate to use with your application. However, test certificates aren't suitable for real, live websites, because they lead to lots of browser security warnings (which is sure to scare away your users). To create a test certificate of your own, check out the instructions at http://tinyurl.com/2hndyq.

Protected Sub Page_Load(ByVal sender As Object, _
  ByVal e As System.EventArgs) Handles Me.Load

    If Request.IsSecureConnection Then
        lblStatus.Text = "This page is running under SSL."
    Else
        lblStatus.Text = "This page isn't secure.<br />"
        lblStatus.Text &= "Please request it with the "
        lblStatus.Text &= "prefix https:// instead of http://"
    End If
End Sub

It's just as straightforward to deploy web applications that use other components. That's because any custom components your website uses are copied into the Bin subdirectory when you add a reference in Visual Studio. No additional steps are required to register assemblies or to copy them to a specific system directory.

Of course, this principle doesn't hold true if you're using shared assemblies, which are stored in a special system location called the global assembly cache (GAC). Usually, you won't store components in this location, because it complicates development and offers few benefits. The core .NET assemblies are located in the GAC because they're large and likely to be used in almost every .NET application. It doesn't make sense to force you to deploy the .NET assemblies with every website you create. However, this means it's up to the administrator of the web server to install the version of the .NET Framework you require. This detail just isn't in your website's control.

The simple model of deployment you've seen so far is often called zero-touch deployment, because you don't need to manually configure web server resources. (It's also sometimes called XCopy deployment, because transferring websites is as easy as copying directories.) However, some applications are more difficult to set up on a web server. Here are some common factors that will require additional configuration steps:

To solve these problems in the most effective way, it helps to work with an experienced Windows administrator.

By default, when you deploy an application you've created with Visual Studio, you deploy the uncompiled source files. The first time a page is requested, it is compiled dynamically and cached in a temporary directory for reuse. The advantage of this approach is that it's easy to make last-minute changes directly to your files without needing to go through any compilation steps. However, this approach has some clear disadvantages:

To improve performance and prevent other people from seeing your code, you have another option—you can use ASP.NET's precompilation feature. Essentially, you use a command-line tool named aspnet_compiler.exe, which is stored in the familiar c:WindowsMicrosoft.NET Framework64[Version] directory. You use this compiler on your development machine before you deploy the application. It compiles the entire website into binary files.

Here's the syntax for the aspnet_compiler tool:

aspnet_compiler -m metabasePath targetDirectory

Essentially, you need to specify the source (where the web application resides) and the target directory (where the compiled version of the application should be copied).

To specify the source, you use the -m option and specify the metabase path in the form W3SVC/1/ROOT/[VirtualDirectoryName], just as you would with aspnet_regiis. Here's an example:

aspnet_compiler -m W3SVC/1/ROOT/MyApp C:MyAppDeploy

You can then copy the files from the target directory to your web server (or if you're really crafty, you can use aspnet_compiler to send the compiled files straight to the target directory as part of your build process).

If you use the command line shown previously, the c:MyAppDeploy directory will contain all the .aspx files but no .vb files—meaning all the source code is compiled into assemblies in the Bin directory and hidden. Even more interestingly, the information in the .aspx files has also been removed. If you open a web page, you'll find that it doesn't contain any tags. Instead, it just contains the statement "This is a marker file generated by the precompilation tool and should not be deleted!" All the tags have been moved into the compiled files in the Bin directory, along with the source code. The aspnet_compiler just keeps the .aspx files so you can remember what web pages there are.

When you create a website in Visual Studio, you can simultaneously create a virtual directory for that website. If you choose to do so, Visual Studio won't use its built-in web server. Instead, all your requests will flow through IIS. (Happily, you'll still see the same behavior and have access to the same debugging tools.)

To try this, you must first start Visual Studio as an administrator. To do so, right-click the Visual Studio shortcut, and choose Run As Administrator.

Now, choose File

Figure 26.19. Creating a virtual directory to hold a new project

This approach often isn't the best way to create a virtual directory. It has several limitations:

For these reasons, it's more common for developers to create their application using the built-in web server in Visual Studio and then create a virtual directory by hand when they're ready to deploy it to a test or production web server.

Visual Studio doesn't give you the full options of IIS Manager, but you can get a little more control. In the New Web Site dialog box, type http://localhost (for the current computer), and click the Browse button. You'll see all the virtual directories that are defined in IIS, just as in IIS Manager (see Figure 26-20).

Figure 26.20. Viewing virtual directories in Visual Studio

You can't view or change their properties, but you can choose an existing virtual directory where you want to create your application. You can also use the Create New Virtual Directory button in the top-right corner of the window (it appears as a folder icon with a globe). Click this button, and you'll get the chance to supply the virtual directory alias and its physical file path (see Figure 26-21).

Figure 26.21. Creating a virtual directory in a specific location

Visual Studio also includes a quick and easy way to transfer your web application files without using a separate program or leaving the design environment. You simply need to open your web project and select Website

Figure 26.22. Copying a website

This window includes two file lists. On the left are the files in the current project (on your local hard drive). On the right are the files on the target location (the remote web server). When you first open this window, you won't see anything on the right, because you haven't specified the target. You need to click the Connect button at the top of the window to supply this information.

When you click Connect, Visual Studio shows a familiar dialog box—it looks almost the same as what you see when you create a virtual directory for a new project. Using this window, you can specify one of the following types of locations:

Once you choose the appropriate destination, click Open. Visual Studio will attempt to connect to the remote site and retrieve a list of its files.

The Copy Web Site feature is particularly useful for updating a web server. That's because Visual Studio compares the file list on the local and remote websites, and it flags files that exist in one location only (with the status New) or those that are newer versions (with the status Changed). You can then select the files you want to transfer and click one of the arrow buttons to transfer them from one location to the other (see Figure 26-24).

Figure 26.24. Synchronizing a remote website

The website copying feature is great for transferring files to a test server. However, it doesn't give you the option of precompiling your code. If you're deploying your application to a live web server and you want to keep the source code tightly locked down, you'll want something more.

As described earlier in this chapter, you can use the aspnet_compiler command-line utility to compile ASP.NET applications. This functionality is also available in Visual Studio through the website publishing feature. While the website copying feature is designed to let you update individual files (which is ideal when updating a test server), the publishing feature is intended to transfer your entire website in compiled form with a couple of clicks.

Here's what you need to do: