HomeASP.NET Setting Up Internet Information Services a...
Setting Up Internet Information Services and ASP.NET
This article will explain how to install ASP.NET, configure Internet Information Services, (IIS), and create virtual directories. It is excerpted from chapter two of the book The Definitive Guide to SAMBA 3, written by Roderick Smith (Apress, 2004; ISBN: 1590592778).
THE LAST CHAPTER GAVE a sweeping introduction to the .NET Framework. But before you start creating ASP.NET web pages and applications, you need to make sure that you have the correct environment on your computer.
In other words, before you dive into the theory and concepts of ASP.NET in any more detail, it’s time to take care of a few easier tasks. In this chapter, you’ll walk through the process of installing ASP.NET, configuring Internet Information Services (IIS), and creating virtual directories. These tasks are supported by wizards or graphical tools, so they don’t require the same level of expertise as actual ASP.NET programming.
Web Servers and You
Web servers run special software to support mail exchange, FTP and HTTP access, and everything else clients need in order to access web content. In the Microsoft Windows operating system, the built-in IIS component plays this role, allowing any computer to become a web server.
In most cases, you won’t be developing on the same computer that you use to host your website. If you were, you would hamper the performance of your web server by tying it up with development work. You would 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. This process of deployment is described in Chapter 12.
However, in order to use ASP.NET, your computer needs to act like a web server. In fact, while you’re testing an ASP.NET application your development computer will work in exactly the same way as it would over an Internet connection to a remote client. When you test a page, you’ll actually request it through IIS, and receive the rendered HTML over an HTTP channel. The only difference between the way your computer works while testing the website and the way a web server behaves when the application is deployed is that your computer won’t be visible and accessible to remote clients on the Internet.
This configuration allows you to perfect your security model and perform realistic testing on your development computer. The drawback is that you need to have the IIS web hosting software on your computer in order to test an ASP.NET website. IIS is included with Windows 2000, Windows XP, and Windows 2003 Server, but it’s an optional component and it isn’t installed by default. To create ASP.NET programs successfully, you need to make sure IIS is installed before you install the .NET Framework or Visual Studio .NET.
Installing Internet Information Services
Installing IIS is easy. Here are the steps you follow on a Windows 2000 or Windows XP computer:
Click Start, and select Settings -> Control Panel.
Choose Add or Remove Programs.
Click Add/Remove Windows Components.
If Internet Information Services is checked (see Figure 2-1), you already have this component installed. Otherwise, click it and click Next to install the required IIS files. You’ll probably need to have your Windows setup CD handy.
Figure 2-1. Installing Internet Information Services
If you’re using Windows Server 2003, you can install IIS through the Add/Remove Windows Components dialog box, but it’s more likely that you’ll use the Manage Your Server wizard. Choose Add or Remove a Role when you start the wizard, and follow all the instructions. Choose the Web application server role to install IIS and the ASP.NET engine in one operation.
When IIS is installed, it automatically creates a directory named c:\Inetpub\wwwroot, which represents your website. Any files in this directory will appear as though they’re in the root of your web server.
To test that IIS is installed correctly and running, browse to the c:\Inetpub\wwwroot directory and verify that it contains a file called localstart.asp. This is a simple ASP (not ASP.NET) file that is automatically installed with IIS. If you try to double-click this file to run it from the local directory, you’ll receive an error message informing you that your computer doesn’t know how to handle direct requests for ASP files (see Figure 2-2) or another program such as Microsoft FrontPage will try to open it for editing.
Figure 2-2.Attempting to open an ASP file through Windows Explorer
This limitation exists because of the way that ASP and ASP.NET files are processed. In a typical web scenario, IIS receives a request for a file. It then looks at the file extension and uses that to determine if the file should be allowed, and what program (if any) is required to handle it. Ordinary HTML files will be sent directly to your browser. ASP files, however, will be processed by the ASP service, which IIS will start automatically. The ASP service loads the requested file, 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. The whole process, which is diagrammed in Figure 2-3, is quite similar to how ASP.NET files are processed, as you’ll see later.
Figure 2-3.How IIS handles an ASP file request
In order to test that IIS is working correctly, you need to request the localstart.asp file through IIS, over the standard HTTP channel. You can do this using an Internet browser. Just open an application like Internet Explorer, and type a request for the file using the name of your computer. For example, if your computer’s name is devtest, you would type http://devtest/localstart.asp. IIS will receive your request, ASP will process the file, and you’ll receive a generic introductory page in your browser (see Figure 2-4).
If you don’t know the name of your computer, right-click the My Computer icon either on your desktop or in Windows Explorer, and select Properties. Then, choose the Computer Name tab. The computer name is next to the heading “Full computer name.” Alternatively, you can save some effort by using one of two presets that automatically refer to the local computer, whatever its name. These are the “loopback” address 127.0.0.1, and the alias localhost. That means you can try entering http://localhost/localstart.asp or http://127.0.0.1/localstart.asp on any computer to test if IIS is installed.
Figure 2-4.Requesting an ASP file through IIS
What If I Can’t Connect?
If you try the previous steps, but receive an “Unable to connect” message, you may need to investigate further. Your first step is to check that IIS is installed correctly and enabled. To check this, you need to use a utility called IIS Manager by selecting Settings -> Control Panel -> Administrative Tools -> Internet Services Manager from the Start menu. You should see your computer listed under the Internet Information Services node in the tree. Expand this node, and click on the Websites folder. In the list on the right, it should indicate that your computer’s default website is running, as shown in Figure 2-5. If not, try right-clicking the icon that represents your computer and choose to restart IIS.
Figure 2-5.The default website is currently running
Lastly, you may need to tweak your Internet settings. For this task, choose Settings -> Control Panel -> Internet Options from the Start menu. Then choose the Connections tab. If you’re working on a local network and have special proxy server settings applied, verify that they don’t conflict with your computer by clicking the LAN Settings button.
If you connect to the Internet using a connection that isn’t always present (such as a modem that connects over a telephone line), you may receive an error message that informs you that a local page cannot be loaded because you’re currently working offline. In this case, just click Connect, and the page will appear successfully without you needing to actually connect to the Internet. To prevent this message from appearing, you can select Never Dial A Connection from the Connections tab, although this will not always stop the problem from reoccurring. If you’re prevented from performing another operation (such as creating a web project in Visual Studio .NET) because the operating system believes you’re offline, simply enter http://localhost/localstart.asp in a browser, and then click Connect when you’re prompted to go online.
To add more pages to your web server, you can copy HTML, ASP, or ASP.NET files directly to the c:\Intetpub\wwwroot directory. For example, if you add the file TestFile.html to this directory, you can request it in a browser through the URL http://localhost/TestFile.html. You can even create subdirectories to group together related resources. For example, the file c:\Intetpub\wwwroot\MySite\MyFile.html can be accessed through a browser using the URL http://localhost/MySite/MyFile.html. If you’re using Visual Studio .NET to create new web projects, you’ll find that it automatically generates new subdirectories in the wwwroot directory. So if you create a web application named WebApplication1, the files will be stored in c:\Inetpub\wwwroot\WebApplication1, and made available through http://localhost/WebApplication1.
Using the wwwroot directory is straightforward, but it makes for poor organization. To properly use ASP or ASP.NET, you need to make your own virtual directory for each web application you create. With a virtual directory, you can expose any physical directory (on any drive on your computer) on your web server, as though it were located in the c:\Inetpup\wwwroot directory.
To create virtual directories, you need to use the administrative Internet Information Services utility. To start it, select Settings -> Control Panel -> Administrative Tools -> Internet Services Manager from the Start menu on the taskbar. The next few sections walk you through the steps and explain the settings that you can configure.
NOTE This chapter is written with IIS 5 in mind. Both Windows 2000 and Windows XP use IIS 5. However, if you’re programming on Windows 2003 Server, you’ll be using IIS 6 instead. IIS 6 features a revamped request processing architecture, and a slightly tweaked user interface. You’ll be able to use most of the instructions in this chapter with IIS 6, but you may want to supplement your knowledge with the online help for IIS 6 or a dedicated book about IIS 6 administration.
Creating a Virtual Directory
When you’re ready to create a new website, 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 that 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.
To create a new virtual directory for an existing physical directory, right-click the Default Website item in the IIS tree, and choose New -> Virtual Directory from the context menu. A wizard will start to manage the process, as shown in Figure 2-6.
Figure 2-6.The Virtual Directory Creation wizard
As you step through the wizard, you’ll need to provide three pieces of information: an alias, a directory, and a set of permissions. These settings are described in the following sections.
Alias
The alias is the name a remote client will use to access the files in this virtual directory. For example, if your alias is MyApp and your computer is named MyServer, you can request pages using URLs such as http://MyServer/MyApp/MyPage.aspx.
Directory
The directory is the physical directory on your hard drive that will be exposed as a virtual directory. For example, c:\Intetpub\wwwroot is the physical directory that is used for the root virtual directory of your web server. IIS will provide access to all the allowed file types in this directory.
Permissions
Finally, the wizard asks you to set permissions for your virtual directory, as shown in Figure 2-7. There are several permissions you can set:
Read. This is the most basic permission—it’s required in order for IIS to provide any requested files to the user. If this is disabled, the client will not be able to access ASP or ASP.NET pages, or static files like HTML and images. Note that even when you enable read permission, there are several other layers of possible security in IIS. For example, some file types (such as those that correspond to ASP.NET configuration files) are automatically restricted, even if they’re in a directory that has read permission.
Run scripts. This permission allows the user to request an ASP or ASP.NET page. If you enable read, but don’t allow script permission, the user will be restricted to static file types such as HTML documents. ASP and ASP.NET pages require a higher permission because they could conceivably perform operations that would damage the web server or compromise security.
Execute. This permission allows the user to run an ordinary executable file or CGI application. This is a possible security risk as well, and shouldn’t be enabled unless you require it (which you won’t for ordinary ASP or ASP.NET applications).
Write. This permission allows the user to add, modify, or delete files on the web server. This permission should never be granted, because it could easily allow the computer to upload and then execute a dangerous script file (or at the least, use up all your available disk space). Instead, use an FTP site, or create an ASP.NET application that allows the user to upload specific types of information or files.
Browse. This permission allows you to retrieve a full list of files in the virtual directory, even if the contents of those files are restricted. Browse is generally disabled, because it allows users to discover additional information about your website and its structure as well as exploit possible security holes. On the other hand, it’s quite useful for testing, so you might want to enable it on a development computer.
Figure 2-7.Virtual directory permissions
To host an ASP.NET application, you only need to enable the read and execute permissions (the first two check boxes). If you’re using a development computer that will never act as a live web server, you can allow additional permissions. (Keep in mind, however, this could allow other users on a local network to access and modify files in the virtual directory.) You can also change the virtual directory permissions after you have created the virtual directory.
NOTE Remember, virtual directory permissions are only used when you’re requesting a page through IIS. If you can directly access the computer’s hard drive using Windows Explorer or some other tool, these permissions won’t come into effect.
You can manage all the virtual directories on your computer in the Internet Information Service utility by expanding the tree under the Default Website item. You’ll notice that items in the tree have three different types of icons, as shown in Figure 2-8.
Figure 2-8.Web folders
Different icons have different meanings:
Ordinary folder. This represents a subdirectory inside another virtual directory. For example, if you create a virtual directory and then add a subdirectory to the physical directory, it will be displayed here.
Folders with a globe. This represents a virtual directory.
Package folders. This represents a virtual directory that is also a web application. By default, when you use the wizard to create a virtual directory, it’s also configured as a web application. This means that it will share a common set of resources and run in its own separate application domain. The topic of web applications is examined in more detail in Chapter 5.
When you create a virtual directory with the Virtual Directory Creation wizard, it’s also configured as a web application. This is almost always what you want. If your virtual directory isn’t a web application, you won’t be able to control its ASP.NET configuration settings, and you won’t be able to create a web application in it using Visual Studio .NET.
Virtual Directories Allow Access to Subdirectories
Imagine you create a virtual directory called MyApp on a computer called MyServer. The virtual directory corresponds to the physical directory c:\MyApp. If you add the subdirectory c:\MyApp\MoreFiles, this directory will automatically be included in the IIS tree as an ordinary folder. Clients will be able to access files in this folder by specifying the folder name, as in http://MyServer/MyApp/MoreFiles/SomeFile.html.
By default, the subdirectory will inherit all the permissions of the virtual directory. However, you can change these settings using the Internet Information Services utility. This is a common technique used to break a single application into different parts (for example, if some pages require heightened security settings).
IIS makes it easy to configure virtual directories after you’ve created them. Simply right-click the virtual directory in the list and choose Properties. The Properties window will appear, as shown in Figure 2-9, with its information divided into several tabs.
Figure 2-9.Web directory properties
The Virtual Directory tab contains the most important settings. These include options that allow you to change the permissions you set when creating the virtual directory with the wizard. You can also see the local path that corresponds to this virtual directory. If you’re looking at the root of a virtual directory, you can set the local path to point to a different physical directory by clicking the Browse button. If you’re looking at an ordinary subdirectory inside a virtual directory, the local path will be read-only.
Remember, when you create a virtual directory with the wizard, it’s also configured as a web application. You can change this by clicking the Remove button next to the application name. Similarly, you can click the Create button to transform an ordinary virtual directory into a full-fledged application. Usually you won’t need to perform these tasks, but it’s nice to know they are available if you need to make a change. They can come in useful when transplanting an application from one computer to another (as discussed in Chapter 12).
Any changes that you make will be automatically applied to all subdirectories. If you want to make a change that will affect all the virtual directories on your server, right-click the Default Website item and choose Properties. The change will be cascaded down to all the contained virtual directories. If your change conflicts with the custom settings that you have set for a virtual directory, IIS will warn you. It will present a list of the directories that will be affected and give you the chance to specify exactly which ones you want to change and which ones you want to leave as is (as shown in Figure 2-10).
Figure 2-10. A change that affects several directories
If you explore the directory properties, you’ll discover several other settings that affect ASP applications but don’t have any effect on ASP.NET websites. These include the Application Protection (memory isolation) setting, and the options for session state, script timeout, and default language. These settings are all replaced by ASP.NET’s new configuration file system, which you’ll learn about in Chapter 5. Some other settings are designed for security, and these are examined in Chapter 25.
TIP Remember, IIS permissions are set on a directory-by-directory basis, which means that all the files in a directory need to share the same set of IIS permissions. As a consequence, the easiest way to apply different settings to different files is to create a virtual directory with more than one subdirectory, and set different options for each subdirectory.
The next two sections briefly explain two other types of IIS configuration: custom error pages and file mappings.
Documents
This tab allows you to specify the default documents for a virtual directory. For example, consider the virtual directory http://localhost/MySite. A user can request a specific page in this directory using a URL like 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 defined for that virtual directory. It will scan the list from top to bottom, and return the first matching page. Using the list in Figure 2-11, IIS will check first for a Default.htm file, then for Default.asp, index.htm, iisstart.asp, and Default.aspx. If none of these pages are found, IIS will return the HTTP 404 (page not found) error.
Figure 2-11. The default document list
You can configure the default document list by removing entries or adding new ones. Most ASP.NET applications simply use Default.aspx as their homepage.
The Custom Errors tab (Figure 2-12) allows you to specify an error page that will be displayed for specific types of HTTP errors. As you’ll discover in Chapter 11, you can use various ASP.NET features to replace HTTP errors or application errors with custom messages. However, these techniques won’t work if the web request never makes it to the ASP.NET service (for example, if the user requests an HTML file that doesn’t exist). In this case, you may want to supplement custom ASP.NET error handling with the appropriate IIS error pages for other generic error conditions.
Figure 2-12.IIS custom errors
File Mappings
As explained earlier in this chapter, IIS hands off requests for ASP pages to the ASP service, and requests for ASP.NET pages to the ASP.NET service. However, both ASP and ASP.NET support a variety of file types. How does IIS know which files belong to ASP.NET and which ones belong to ASP?
The answer is found in the application file mappings. To view file mappings, click the Configuration button on the Virtual Directory tab. You’ll see the window shown in Figure 2-13.
You’ll notice that ASP files are mapped differently than ASP.NET files. For example, .asp requests are handled by C:\[WinDir]\System32\inetsrv\asp.dll, while .aspx requests are handled by C:\[WinDir]\Microsoft.NET\Framework\[Version]\aspnet_isapi.dll. In other words, ASP.NET doesn’t replace ASP. Instead, it runs alongside it, allowing ASP requests to be handled by the existing asp.dll, and providing a new aspnet_isapi.dll for ASP.NET page requests. This design allows both types of applications to be hosted on the same web server with no potential conflict (and little possible integration). You could also use a similar approach to make sure that .aspx page requests in one virtual directory are handled by a different version of the ASP.NET service than requests in another virtual directory. If a file type isn’t mapped (like .html), its contents are sent directly to the user as plain text, without any processing.
Figure 2-13.File mappings
If you’re only working with a single version of ASP.NET, you probably won’t need to worry about file mapping. One reason that you might want to work with file mapping is to explicitly remove file mappings you don’t need or mappings that could be a security risk. In other cases, you might want to add a file mapping. For example, you could specify that the ASP.NET service will handle any requests for GIF images by adding a mapping for the .gif file type that points to the aspnet_isapi.dll file. This would allow you to use ASP.NET security services and logging for GIF file requests. (Note that this sort of change can slow down performance for GIF requests, because these requests will need to trickle through more layers on the server.) ASP.NET uses this technique to improve security with configuration and source code files. ASP.NET is registered to handle all requests for .config, .cs, and .vb files so that it can explicitly deny these requests, regardless of the IIS security settings.
CAUTION You should never remove any of the ASP.NET file type mappings! If you remove the .aspx or .asmx file types, web pages and web service won’t work. Instead of being processed by the ASP.NET service, the raw file will be sent directly to the browser. If you remove other files types like .vb or .config, you’ll compromise security. ASP.NET will no longer process requests for these types of files, which means that malicious users will be able to request them through IIS and inspect the code and configuration information for your web application.
Adding a Virtual Directory to Your Neighborhood
Working with a web application can sometimes be a little awkward. If you use Windows Explorer and look at the physical directory for the website, you can see the full list of files, but you can’t execute any of them directly. On the other hand, if you use your browser and go through the virtual directory, you can run any page, but there’s no way to browse through a directory listing because virtual directories almost always have directory browsing permission disabled.
While you’re developing an application you may want to circumvent this limitation. That way you can examine exactly what comprises your web application and run several different pages easily, without needing to constantly type a full file name or dart back and forth between Internet Explorer and Windows Explorer. All you need to do is enable directory browsing for your virtual directory. You can easily enable or disable this setting from the Virtual Directory Properties window.
To make life even easier, you can add a virtual directory to the Network Neighborhood in Windows Explorer. First, open Windows Explorer. Then click Network, and double-click Add Network Place from the file list, as shown in Figure 2-14.
Figure 2-14.Select Add Network Place
The Add Network Place wizard will appear. This wizard allows you to create a network folder in Windows Explorer that represents your virtual directory (see Figure 2-15). The only important piece of information you need to specify is the address for your virtual directory (such as http://MyServer/MyFolder). Don’t use the physical directory path.
Figure 2-15.Specify the virtual directory
You can then choose the name that will be used for this virtual directory. Once you finish the wizard, the directory will appear in your Network Neighborhood, and you can browse through the remote files (see Figure 2-16). The interesting thing is that when you browse this directory, you’re actually receiving all the information you need over HTTP. You can also execute an ASP or ASP.NET file by double-clicking—which you can’t do directly from the physical directory.
Once you’ve installed IIS, you can install ASP.NET. At the time of publication ASP.NET was available in two different packages:
The free .NET runtime. You can download the installation files fromhttp://www.asp.net, or you can order them on a CD athttp://microsoft.order-2.com/developertools.
The Visual Studio .NET application, which includes the .NET Framework and an IDE to design your applications.
Like most Microsoft setup applications, the process is quite straightforward. A graphical wizard (shown in Figure 2-17) takes you through every step of the lengthy process.
Figure 2-17.The Visual Studio .NET setup
After the setup is complete, you’ll find several new directories on your computer. These include the following, among others:
C:\[WinDir]\Microsoft.NET\[Version] contains the core .NET files. This includes the VB .NET, C#, JScript .NET, and J# language compilers, the ASP.NET service, and numerous utilities.
C:\[WinDir]\Assembly contains the higher-level functionality of .NET—namely, it’s where the shared .NET Framework assemblies are located. These assemblies contain all the types in .NET class library.
C:\[WinDir]\Microsoft.NET\[Version]\Config contains computer-specific configuration files, the most important of which is the machine.config file.
C:\[WinDir]\Microsoft.NET\[Version]\Temporary ASP.NET Files contains natively compiled ASP.NET web page code. The ASP.NET service uses this directory behind the scenes, compiling code and caching it for the best possible performance.
C:\Program Files\Microsoft Visual Studio .NET is the default location for the Visual Studio .NET software, if you’ve installed it. The directory name varies slightly depending on the version of Visual Studio .NET that you’ve installed.
Note that [WinDir] represents your Windows directory (typically WINDOWS or WINNT), while [Version] represents the version of the .NET Framework that you’ve installed (such as v1.1.4322).
Verifying that ASP.NET Is Correctly Installed
After installing ASP.NET, it’s a good idea to test that it’s working. All you need to do is create a simple ASP.NET page, request it in a browser, and make sure that it’s processed successfully.
To perform this test, create a text file in the c:\Inetpub\wwwroot directory. Name this file test.aspx. The filename isn’t that important, but the extension is. It’s the .aspx extension that tells IIS that this file needs to be processed by the ASP.NET engine.
Inside the test.aspx file, paste the following code:
<html> <body> <h1>The date is <% Response.Write(DateTime.Now.ToLongDateString()) %> </h1> </body> </html>
When you request this file in a browser, ASP.NET will load the file, execute the embedded code statement (which retrieves the current date and inserts it into the page), and then return the final HTML page. This example isn’t a full-fledged ASP.NET web page, because it doesn’t use the web control model you’ll be exploring in the second part of this book. However, it’s still enough to test that ASP.NET is working properly. When you enter http://localhost/test.aspx in the browser, you should see a page that looks like the one shown in Figure 2-18.
Figure 2-18.ASP.NET is correctly installed
If you see only the plain text, as in Figure 2-19, ASP.NET isn’t installed correctly. This problem commonly occurs if ASP.NET is installed but the ASP.NET file types aren’t registered in IIS. In this case, ASP.NET won’t actually process the request. Instead, the raw page will be sent directly to the user, and the browser will only display the content that isn’t inside a tag or script block.
Figure 2-19. ASP.NET isn't installed or configured correctly
This problem can usually be solved by repairing your installation of ASP.NET using the original setup CD or DVD. To start this process, type in the following command at the command line (or in the Run window) using the Visual Studio .NET DVD. (It’s split into two lines due to page constraints, but it should be entered on a single line.)
This book includes a wide range of code examples that are available online athttp://www.prosetech.com. These samples are downloadable as a single ZIP file, which you can extract onto your computer using a utility like WinZip. In order to run the files, you’ll need to place them into a virtual directory of your choice.
Along with the sample files are the additional project and solution files that Visual Studio .NET creates automatically for web applications. In order to open these projects in Visual Studio .NET without any problem, you must use the exact same directory structure that I’ve used (which incorporates a C:\ASP.NET root directory). Generally, this directory structure will be created automatically when you unzip the file, but you’ll need to make sure you use the same drive (C:) to match what Visual Studio .NET expects. After you’ve unzipped all the code files, you’ll have to map the new directories to the appropriate virtual directories. This can be accomplished quite quickly if you follow the exact installation instructions described on the website or in the readme.txt file included with the code download.
The ASP.NET Account
When ASP.NET is installed, a new Windows user account is created called ASPNET. By default, the ASP.NET service runs under this account when it executes any ASP.NET code, including the code in your custom web pages and web services.
The ASPNET account has a set of carefully limited privileges. By default, the ASPNET account won’t be allowed to perform tasks like 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 Temporary ASP.NET Files directory, so that it can compile and cache web pages.
The limited security settings of the ASPNET account are designed to prevent malicious code from damaging your web server. However, you’ll probably find that your applications require some additional permissions beyond those given to the ASPNET account. For example, your code might need to write data to a specific directory, use the Windows event log, and execute database operations. You can grant permissions to the ASPNET account in the same way that 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.
If you’re using a computer for development testing only, you can use a shortcut to give the ASP.NET service greater privileges. Instead of using the ASPNET account, you can configure ASP.NET code so that it runs under the local system account. The local system account is a built-in Windows account with administrator-level permissions. Code that runs under this account has the ability to do almost anything on the current computer. Using the local system account is a poor idea on a production system, but it isn’t a bad approach for testing a new web application on a development computer.
NOTE The ASP.NET account is a global setting that affects all web applications on the computer, provided you’re using IIS 5. If you’re using Windows Server 2003, you must use configure the IIS 6 application pool settings instead. Editing the machine.config will have no effect.
To change the ASP.NET settings to use the local system account, you need to perform the following steps.
Open the machine.config file in the C:\[WinDir]\Microsoft.NET\[Version]\ Config directory using Notepad. (If you’ve installed the .NET Framework 1.1 on a Windows XP computer, this directory will be C:\Windows\Microsoft.NET\ v1.1.4322\Config.
Search for the text userName="Machine". You’ll find this setting in the processModel tag, which looks something like this:
The userName="Machine" instruction tells ASP.NET to run using the special ASPNET account. Modify this attribute to be userName="System". This tells ASP.NET to use the local system account.
Now you must restart the ASP.NET service. To do this, you can either reboot the computer, or you can use Task Manager to manually terminate the ASP.NET service. In the latter case, look for the process named aspnet_wp.exe. Select it and click End Process.
The effect of the ASP.NET account is explored in Chapter 25, which tackles security in more depth.
NOTE You might wonder how virtual directory permissions and the ASP.NET account settings interact. Essentially, the virtual directory permissions determine what files a user can request. If the user successfully requests an ASP.NET file, the ASP.NET engine will then execute the corresponding web page code. The ASP.NET account settings determine what this code is allowed to do.
The Last Word
In this chapter, you learned how to make sure your computer is ready to host ASP.NET websites. Before you continue to the next part, make sure you’ve verified that you can request the sample ASP.NET page (as described in the section “Verifying that ASP.NET Is Correctly Installed”). This ensures that both ASP.NET and IIS are installed and configured properly. Once that’s in place, you’re ready to begin designing full-fledged ASP.NET applications and web pages. You can start with Chapter 3, which presents a comprehensive overview of the new Visual Basic .NET language.
ASP.NET 
/ 22 
Implement Gzip and Deflate Compression in ASP.Net
