This topic describes using either Internet Information Services (IIS) or the built-in Visual Studio Development Server for testing and running Web projects.
To test or run ASP.NET Web projects, you need a Web server. The production Web server for Microsoft operating systems is IIS, which includes a Web server, File Transfer Protocol (FTP) server, Simple Mail Transfer Protocol (SMTP) virtual email server, and other facilities. In order to run IIS, you must be working with a version of Windows that is designed to function as a server in a network environment.
In Windows XP, Windows Server 2003, and later versions of Windows Server, IIS is not installed by default; you can add it using the Add/Remove Windows Components option of Add or Remove Programs in Control Panel. (In Windows Server 2003 and later versions of Windows Server, you can install IIS using the Application Server component.)
It might be impractical for you to work with IIS for reasons such as the following:
You are developing ASP.NET Web pages while working with a Home Edition of Windows, which does not support IIS.
You do not want to host a Web server on your computer (for example, on your home network) for security reasons. Running a Web server such as IIS requires that you perform extra steps to help secure the server and that you are vigilant about installing the latest security updates.
The corporate policy where you work does not allow you to install certain server components such as IIS.
For more information about working with IIS, see the following topics:
If you cannot or do not want to use IIS as your Web server, you can still test your ASP.NET pages by using the Visual Studio Development Server. The Visual Studio Development Server, which is included with Visual Studio and Visual Web Developer Express, is a Web server that runs locally on Windows operating systems, including Home Edition versions. It is specifically built to serve, or run, ASP.NET Web pages on the local computer. It will not serve pages to another computer. Additionally, it will not serve files that are outside the application scope. The Visual Studio Development Server provides an efficient way to test pages locally before you publish the pages to a production server running IIS.
The Visual Studio Development Server only accepts authenticated requests on the local computer. This requires that your computer be configured to support NTLM or Basic authentication.
| Note |
|---|
As a best practice, do not run Visual Studio with administrative rights. This helps prevent inadvertent access to system files (such as machine.config, for example) files on your computer. |
The Visual Studio Development Server works only with individual pages and does not include the extra facilities of IIS. For example, the Visual Studio Development Server does not support SMTP or FTP. If your Web project involves sending email messages, you must have access to the IIS SMTP virtual server to test email because the Visual Studio Development Server cannot forward email messages or send emails by using a server that does support SMTP.
Running the Visual Studio Development Server
The Visual Studio Development Server is installed by default with Visual Studio. If you are working with a file-system Web site or a Web application project, Visual Studio automatically uses the Visual Studio Development Server to run pages. By default, the Web server is invoked on a randomly selected port for the local host scenario. For example, if you are testing a page called ExamplePage.aspx, when you run it on the Visual Studio Development Server, the URL of the page might be:
If you want to run the Visual Studio Development Server on a specific port, you can configure the server to do so. You might do this in these scenarios:
If your project includes a reference to a client project or Web service that is bound to a specific port.
If code in your project listens to a specific port and you want to be able to test the application using the Visual Studio Development Server.
For more information, see How to: Specify a Port for the ASP.NET Development Server.
Security Context for the Visual Studio Development Server
An important difference between the Visual Studio Development Server and IIS is the security context in which the respective servers run your ASP.NET pages. This difference can affect your testing because of differences in how the pages run.
When you run a page using the Visual Studio Development Server, the page runs in the context of your current user account. For example, if you are running as an administrator-level user, a page running in the Visual Studio Development Server will have administrator-level privileges. In contrast, in IIS, ASP.NET by default runs in the context of the special user (ASPNET or NETWORK SERVICES) that typically has limited privileges. The ASPNET or NETWORK SERVICES accounts are local to the server computer (not domain accounts), which prevents access to restricted resources on the local server or other computers.
If you are simply reading and running the code in ASP.NET pages, this difference is not very important. However, the different security contexts for the two Web servers can affect your testing of the following:
Access to other resources that the page requires This can include reading and writing files other than Web pages, reading and writing the Windows registry, and so on.
Database access When working with the Visual Studio Development Server, you can typically rely on Windows Integrated authentication to access SQL Server. However, when the same page runs in IIS under the ASPNET or NETWORK SERVICES account, the page is running in the context of a local user, and you often have to configure the page to use a connection string that includes information about a user and password. For details, see Accessing SQL Server from a Web Application and ASP.NET Security Architecture.
Code access security If your page involves access to resources that are protected under different zones, the page might run differently under the Visual Studio Development Server and IIS.
Even though you can use the Visual Studio Development Server to test that pages are functional, you should test them again after publishing the pages to a production Web server that is running IIS.
When you test a file-system Web site using the Visual Studio Development Server, static files such as images and style sheets are subject to ASP.NET authorization. For example, Visual Studio Development Server will not serve static files in a file-system Web site if they are in a folder that is restricted for anonymous users and if you are testing the site as an anonymous user. However, when you create a Web site project in an HTTP location, IIS might serve some static files without using authorization rules.
When you run a Web site in Visual Studio, project options determine which Web server Visual Studio uses to run (test) the site. By default, Visual Studio runs file-system Web site projects and Web application projects by using the Visual Studio Development Server. You can select IIS for a file system Web site project in the Start Options tab of the Property Pages dialog box. You can select IIS for a Web application project in the Web tab of the Project Properties window. For more information, see How to: Specify the Web Server for Web Projects in Visual Studio.
