Now that you have ASP.NET up and running, let’s take a look at where the files for your Web applications are kept on the computer. You can readily set IIS to look for Web applications within any folder of your choice, including the My Documents folder or even a network share. By default, IIS maps the wwwroot subfolder of C:\Inetpub on the server to your Website’s root directory, and it is generally considered a good repository for storing and managing your Web applications.

If you open this wwwroot folder in Windows Explorer, and compare it with the folder tree that appears on the left of the IIS console, you’ll notice that the folders in Explorer also appear under your Default Web Site node. Note that, while several of these folders have the regular Explorer folder icon in the IIS view, others have a special Web application icon, indicating that these folders contain the pages and other items for a particular Web application. These special folders are what IIS calls Virtual Directories, and, in fact, they do not have to share the name of the physical folder to which they map. We’ll see more on this shortly.

By putting your files within C:\Inetpub\wwwroot, you’ve given your Web server access to them. If you’ve been developing Web pages for a long time, habit may drive you to open files directly in your browser by double-clicking on the HTML files. Because ASP.NET is a server-side language, your Web server needs to have a crack at the file before it’s sent to your browser for display. If the server doesn’t get this opportunity, the ASP.NET code is not converted into HTML that your browser can understand. For this reason, ASP.NET files can’t be opened directly from Windows Explorer.

Instead, you need to open them in your browser using the special Web address that indicates the current computer, http://localhost/. [[link broken. Ed.] If you try this now, IIS will open up some HTML help documentation, because we’ve not yet set up a default Website. This localhost name is, in fact, equivalent to the so-called loopback IP address, 127.0.0.1, IP which you can check out by entering http://127.0.0.1/ [[link broken. Ed.] in your browser; you should see the same page you saw using localhost. If you know them, you can also use the name of your server or the real IP address of your machine to the same effect.

Note that if you do try any of these equivalents, a dialog will appear before the page is opened, asking for your network credentials, because you’re no longer using your local authentication implicit with localhost.

Now that we have IIS up and running, and ASP.NET installed, let’s look at how you can start, stop, and restart IIS if the need arises. For the most part, you’ll always want to have IIS running, except when you’re using certain programs locally that open ports and allow intruders to compromise the security of your computer. Some programs, like Kazaa, automatically stop IIS upon launch, because of potential security vulnerabilities. If you want to stop IIS when it’s not being used, simply follow the steps outlined below:

I’ve already briefly introduced the concept of virtual directories, which are a key mechanism in IIS; now I’d like to define a virtual directory a little more clearly.

A virtual directory is simply a name (or alias) that points to a local folder or network share on the server. This alias is then used to access the Web application held in that physical location. For instance, imagine your company has a Web server that serves documents from C:\Inetpub\wwwroot\mySiteA. Your users can access these documents through this URL:

You could also set up another physical location as a different virtual directory in IIS. If, for instance, you were developing another Web application, you could store the files for it in C:\dev\newSiteB. You could then create in IIS a new virtual directory called, say, CoolPages, which maps to this location. This new site would then be accessible through this URL:

As this application is in development, you would probably want to set IIS to hide this virtual directory from the public until the project is complete. Your existing Website would still be visible.

Let’s create a virtual directory on your server now:

Once your new virtual directory has been created, it will appear within the Website list as shown in Figure 1.4.

Figure 1.4. Once the virtual directory has been created, it will appear within the list of sites.

Now, if you type http://localhost/WebDocs/ [[link broken. Ed.] in your browser, IIS will recognize that you’re looking for a Website held in the My Pictures directory. By default, when we request a virtual directory in this way, IIS looks for an index HTML page such as index.html or default.htm. If there is no index page—in this case there isn’t—IIS assumes we want to see the contents of the requested location. However, viewing the entire content of a location like this is not usually something we want our users to do; they could then freely see and access all the files and directories that make up our Web page. Not only is this a little messy and unprofessional, but it also can provide information to hackers that could let them attack our site. So, by default, IIS won’t allow this—we’ll receive a message reading, “Directory Listing Denied” in our browser.

Bearing that in mind, there are, however, circumstances in which we do want to allow directory listings, so let’s see how we can enable this in IIS. First, we have to right click the virtual directory in the IIS console, and choose Properties. Then, we select the Virtual Directory tab, and check the Directory browsing box. When we click OK and open (or refresh) the same URL in our browser, we’ll see a list of all the files within the My Pictures folder.

The Properties dialog that we’ve just used lets us configure various other useful properties, including:

One thing to note at this point is that we can set properties for the Default Web Site node, and choose to have them ‘propagate’ down to all the virtual directories we’ve created. So, let’s now go ahead and enable directory browsing as the default for our Web applications. Please do remember what I’ve said about the dangers of allowing directory browsing on a production Web application, and keep in mind that you should never normally allow it in a publicly accessible environment (even on an intranet). However, during development, this facility can be very handy, as it allows us to navigate and run all our virtual directories by clicking on the listing in our browser, rather than having to type in long URLs each time.

To enable directory browsing:

To try it out, open your browser and type http://localhost/ in the address bar. The directory listing will appear within the browser as shown in Figure 1.5.

Figure 1.5. Enabling directory browsing for the Web server provides you with the ability to view directories in a way that’s similar to the view you’d see within Windows Explorer.

As you create Web applications, you’ll only need to select the directory that the Web application resides in to launch your work, but do remember to disable directory browsing should you later make your IIS Web server publicly visible.