• Choose a category
• All
• Classic-Fiction

Note

The warm-up feature is an IIS feature. Autostart providers are an ASP.NET 4 extension that works for any type of ASP.NET applications, including Web Forms applications and ASP.NET MVC applications. Furthermore, warm-up also works for Windows Communication Foundation (WCF) services running under IIS.

Summary

With the release of IIS 7 just a couple of years ago, the ASP.NET platform and the Microsoft Web server platform are finally aligned to the same vision of HTTP request processing. A request that hits the IIS Web server goes through a number of steps—nearly the same set of steps that for years have characterized the ASP.NET runtime environment.

Today, you need to understand the internal mechanics of IIS to optimize deployment and configuration of ASP.NET applications. The great news is that if you know ASP.NET and its runtime machinery, you’re more than halfway to understanding and leveraging IIS capabilities.

Put another way, the integration between ASP.NET 4 and IIS 7.x couldn’t be tighter and more rewarding for Web application developers. In this chapter, I reviewed the key facts of the internal workings of IIS and ASP.NET when they process a request and discussed some of the features you want to dig out to deploy an application and optimize its behavior in a production environment.

In the next chapter, I’ll take a look at some details of the configuration of ASP.NET applications and discuss the schema of configuration files.

Chapter 3. ASP.NET Configuration

Computers are useless. They can only give you answers.

—Pablo Picasso

The .NET Framework defines a tailor-made, XML-based API to access configuration files and, in doing so, forces developers to adopt a common, rich, and predefined schema for storing application settings. In the more general context of the .NET configuration scheme, ASP.NET applications enjoy specific features such as a hierarchical configuration scheme that allows settings inheritance and overriding at various levels: machine, application, or specific directories.

Configuration files are typically created offline or during the development of the application. They are deployed with the application and can be changed at any time by administrators. Changes to such critical files are promptly detected by the ASP.NET runtime, Internet Information Services (IIS), or both, and they typically cause a restart of the worker process. ASP.NET pages can use the classes in the System.Configuration namespace to read from, and to write to, configuration files.

In this chapter, I’ll specifically delve into the ASP.NET configuration machinery. You’ll see how to fine-tune the ASP.NET runtime and review the whole collection of parameters you can set for an individual application.

The ASP.NET Configuration Hierarchy

Configuration files are standard XML files that rigorously follow a given schema. The schema defines all possible settings for machine and application files. Configuration in ASP.NET is hierarchical by nature and is based on a unique, machine-specific file known as the machine.config file plus a number of web.config files. The syntax of machine.config and web.config files is identical.

Note

ASP.NET protects its configuration files from direct Web access by instructing IIS to block browser access to configuration files. An HTTP access error 403 (forbidden) is returned to all browsers that attempt to request a .config resource as a URL. At least, this was considered to be true for a few years. In September 2010, an ASP.NET vulnerability was discovered and fixed by Microsoft via a security patch. You can read about it at http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx. The article includes a link to the patch, which is also available through standard Windows Update channels. Why is that important here? One of the effects of the vulnerability was that it fooled a system HTTP handler to return the content of any file being requested, including web.config.

Configuration Files