Accessing Standard Local Web Sites

Using the WebDev.WebServer utility is relatively easy. You must supply a path to the Web site that you want to create, using the /path switch. Always use the optional /port switch to reduce security concerns. Finally, the optional /vpath switch lets you create a virtual folder for your application. The default setting uses the root folder (/).

I used the following command line to access the copy of my personal Web site on the local drive:

WebDev.WebServer /port:7171
   /path:"F:\My Web Site"

Executing this command starts the built-in Web server. You'll see an icon added to the Taskbar Tray, like the one shown in Figure 1. Right clicking on this icon displays the options shown in the figure. Select the Open in Web Browser option, and you'll see the Web site in the default browser for your machine. Copy the address bar from one browser to another, and you can test for compatibility issues in multiple browsers without ever leaving the local machine.

Figure 1: Starting a Web server adds an icon to the Taskbar Tray that you use to control it.

The icon remains in the Taskbar tray indefinitely. You can stop the Web server by choosing the Stop option on the context menu. The Web server stops immediately, and frees the resources it was using.

You can have as many of these Web servers running as required to perform testing on your system within the limits of the machine resources. Each Web server is completely separate. To avoid errors, provide a different port number for each Web server.

The Show Details option on the context menu displays the dialog box shown in Figure 2. This dialog box tells you the physical path to the Web site, the port that it's using, and the virtual path. Clicking the link at the bottom of the dialog box opens the default browser to the root of the Web site (rather than opening a default page). Click Stop to stop the server. Click the Close button when you want to continue using the Web server.

Figure 2: Use the ASP.NET Development Server dialog box to discover details about the Web server.

When you work with WebDev.WebServer from a batch file or a command prompt, you'll want to precede the command with the Start utility. Using the Start utility ensures that the command completes right away so that the batch file continues to execute or that you retain control over the command prompt. Using the previous example as a starting point, the command now becomes:

Start /B WebDev.WebServer /port:7171 /path:"F:\My Web Site"

The /B switch tells Start to start the application without creating a new application window. Otherwise, the Start utility creates a new command prompt window that doesn't contain anything. The user is likely to close the window and stop the Web server — with unexpected results for your application.

Built-in Web Server Limitations

This feature is really very interesting. However, you have to consider some of the limitations of using it, too. The WebDev.WebServer utility doesn't create a full-fledged Web server. Consequently, any security that you want to set up has to appear as part of your application in a Web.config file. The WebDev.WebServer utility does tend to follow whatever rules you set for Internet Information Server (IIS), if you have it installed. However, I found that this behavior isn't something you can count on; you certainly can't count on it when you send the application to other computer systems.

Anything you normally configure through the Internet Information Services console (located in the Administrative Tools folder of the Control Panel) is unavailable when working with the WebDev.WebServer utility. Consequently, if your application relies on a special ISAPI Filter, you won't be able to execute it using the WebDev.WebServer utility. The same holds true for anything else that you normally have to add using the Internet Information Services console.

However, savvy developers can get around some of these configuration limitations through judicious use of the Web.config file and by creating resources locally. Make sure you don't assume that an application won't work simply because you have to configure it in a new way.

Remember that this is a single user Web server. No one outside of the local computer can access the Web server because theoretically, it doesn't exist; it's virtual. This means that you can't perform some types of testing using the built-in Web server. The feature that makes it so secure also prevents you from performing some kinds of real world testing. Multi-user applications simply won't work with the built-in Web server.

It has limitations — but this is an extremely useful utility. Aren't you glad you know about it?