Most developers care about application performance. Even if speed isn't the most important attribute of their software, they certainly don't want the application to be slow. But streamlining code may seem too complex, and require skills that you don't have.

Relax. While code optimization certainly is the best way to improve your application's performance, you may be overlooking another option: adjusting the settings on the .NET Framework.

There are two traditional ways to accomplish this: by directly editing an application's config.web file, or by using .NET's built-in command line tools for overall configuration changes.

Both tasks are tedious, so Microsoft came out with the ASP.NET tab in IIS 6.0 to make configuring applications that much easier. In this article, I give you a guided tour, and show how it can make life easier for configuring Web applications.

To get started: Bring up the ASP.NET tab by opening the IIS Manager snap-in and right clicking on a Web site. Choose Properties, and select the ASP.NET tab. (If you have multiple versions of .NET installed on the server, you can switch between the different versions from here.)

ASP.NET Configuration Settings

Click on the "Edit Global Configuration" button, and you should see a screen similar to Figure 1.

Any changes to the settings that you make here affect all web.config files throughout this application's directory structure from the root down.

General Settings

The first property tab, open by default, is the General tab, in which you define general application settings. Here you can add connection strings and application keys.

Using connection strings and application keys can make your applications more readable and easier to manage. If you need to change your database or Web service connections, you only need to change them in one spot, instead of in several instances throughout the application.

Click the Add button in each section and provide the relevant information. In my example, I have an application key to the Salesforce Web service.

Custom Errors

The second property tab is for defining any page redirects invoked by HTTP error codes. For example, the notorious "Page Not Found" error code, 404, could be added here.

The Custom error mode property tells the ASP.NET compiler how to treat any error when encountered. Setting its status to "On" executes all error handling and routes the user to the destination pages once the code is encountered.

I recommend that you do set the status to "On" and any use explicit descriptive destination error pages for the most common error codes, to make your application user-friendly and professional. Any non-local users making requests and gett an errors are displayed the ASP.NET Yellow screen of death telling them there has been an application error, but not what the error is.

The "Remote Only" option only executes the error code redirects to local users of the server. This option is useful if you're doing local application testing on the servers and you want developers to encounter errors. It is also useful if your application is an Intranet based application (local network) only.

The Default Redirect URL field tells the compiler to redirect users to the URL specified for any errors that are not in the custom errors list.

Authorization

The Authorization tab allows you to create authorization rules for different user types that will be using your application. Click the Add button on this tab and you should see a screen similar to the one shown in Figure 3.

The Rule type is either to allow or deny access to the application. In the Verbs section, you set which HTTP transmission method requests are granted access to the resource by the user. For example, by selecting All Verbs, you are granting the user all method requests assigned to ASP.NET — the GET, HEAD, POST and DEBUG methods. You can filter these by adding one or more of them to the Specific verbs list. A comma must be used to separate items in the list.

Filtering is useful, in certain situations, to deny (or grant) certain HTTP requests to the application. For example, if you want to keep users from posting data to the application while you make changes to the database, then leave out the HTTP POST request.

The remaining Users and Roles section is where you restrict (or grant) access to user types. Access can also be applied to roles created with the Roles class of System.Web.Security Namespace for your application.

The most efficient way to manage user based security at the role level is with the Role class. By authenticating roles here, you can manage all your user security in one place, instead of several instances throughout the application.

Checking the Roles box allows you to list the roles to be applied. For example, selecting All users and listing a role called Admins permits all users who are of role type Admins to access the application.