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 ASP.NET Development Server. The ASP.NET Development Server, which is included with Visual Web Developer, is a Web server that runs locally on Windows operating systems, including Windows XP Home Edition. It is specifically built to serve, or run, ASP.NET Web pages under the local host scenario (browsing from the same computer as the Web server). In other words, the ASP.NET Development Server will serve pages to browser requests on the local computer. It will not serve pages to another computer. Additionally, it will not serve files that are outside of the application scope. The ASP.NET Development Server provides an efficient way to test pages locally before you publish the pages to a production server running IIS.
The ASP.NET Development Server only accepts authenticated requests on the local computer. This requires that the server can support NTLM or Basic authentication.
.gif) Note: |
|---|
As a best practice, do not run Visual Web Developer while you are logged on as an Administrator — run it under a more restrictive account. This helps prevent inadvertent access to other files on the server. |
The ASP.NET Development Server works only with individual pages and does not include the extra facilities of IIS. For example, the ASP.NET Development Server does not support an SMTP mail server. If your Web application involves sending e-mail messages, you must have access to the IIS SMTP virtual server to test e-mail because the ASP.NET Development Server cannot forward e-mail messages or invoke a server that does.
Running the ASP.NET Development Server
The ASP.NET Development Server is installed by default with Visual Web Developer. If you are working with a file-system Web site, Visual Web Developer automatically uses the ASP.NET 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 ASP.NET Development Server, the URL of the page might be:
http://localhost:31544/ExamplePage.aspx
When you close the browser, the ASP.NET Development Server shuts down again.
If you want to run the ASP.NET Development Server on a specific port, you can configure the server to do so. You might do this in these scenarios:
If code in your application listens to a specific port and you want to be able to test the application using the ASP.NET Development Server.
If your application includes a reference to a client project or Web service that is bound to a specific port.
Visual Web Developer cannot guarantee that the port you specify will be available when you run your file-system Web site. For details, see How to: Specify a Port for the ASP.NET Development Server.
Security Context for the ASP.NET Development Server
An important difference between the ASP.NET 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 ASP.NET 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 ASP.NET 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 restricts access to resources on 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 ASP.NET 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 ASP.NET Development Server and IIS.
Even though you can use the ASP.NET 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.