Dissecting ASP.NET Version 3.5's Web.config FileBy Scott Mitchell
In November, Microsoft released the final version of ASP.NET 3.5 and Visual Studio 2008. As discussed in An Overview of ASP.NET 3.5 and Visual Studio 2008, version 3.5 is not a major reworking of the .NET Framework. Rather, it adds new classes and functionality on top of the existing core.
If you've had a chance to check out Visual Studio 2008, you may have noticed that it creates a rather verbose
file with a bevy of configuration elements not found in the more terse
Web.config file created by Visual Studio
2005. Likewise, when opening an existing Visual Studio 2005 project in Visual Studio 2008, you are prompted with a dialog box
asking if you want to upgrade the website to use .NET Framework version 3.5. If you click Yes, Visual Studio updates the
Web.config file to include the additional markup.
In this article we will examine each of the additional configuration elements added by Visual Studio 2008 to ASP.NET 3.5 applications. Read on to learn more!
A Look at the Default
Web.config File Used by Visual Studio 2005
When you create a new ASP.NET web application in Visual Studio 2005, the project's default
Web.configfile looks something like the following. (I've removed comments for brevity)
<configuration> element is the XML document's root element. The default
by Visual Studio 2005 adds three child elements to the
<appSettings>- the place for the page developer to specify application-wide constants and other simple, scalar settings.
<connectionStrings>- the place to specify database connection strings used by the application.
<system.web>- contains configuration settings for the ASP.NET web applicaiton, such as authentication and authorization options, compilation options, custom error page settings, HTTP Handlers and Modules, and so on.
<system.web>element there are three additional child elements:
<compilation>- settings that dictate how ASP.NET pages are compiled
<pages>- default settings for all ASP.NET pages within the application. Here, the
<pages>element has a child element,
<namespaces>, which define those namespaces imported into all ASP.NET pages by default.
<authentication>- the authentication model used by the ASP.NET application.
Changes to the Default
Web.config File in Visual Studio 2008
As discussed in An Overview of ASP.NET 3.5 and Visual Studio 2008, Visual Studio 2008 can be used to create ASP.NET version 2.0, version 3.0, or version 3.5 applications. To specify the version being targeted, right-click on the website project in the Solution Explorer and select Property Pages from the context menu. From the Property Pages, select the Build option in the left column. You can then choose the version to target from the drop-down list on the right.
Visual Studio 2008 automatically updates the application's
Web.config file based on the version being targeted.
Similarly, when you open an existing ASP.NET 2.0 application in Visual Studio 2008, you are prompted as to whether you want to upgrade the website to ASP.NET version 3.5.
If you choose Yes, Visual Studio 2008 targets the application to version 3.5, thereby updating the
The (rather lengthy) default
Web.config markup used by Visual Studio 2008 for applications targeted for version 3.5 looks
similar to the following. (I've removed comments for brevity) The
Web.config file created by Visual Studio 2008
has some portions identical to the one created by Visual Studio 2005. Those portions that are different are are
highlighted a light yellow color. When reviewing the differences, keep in mind
that ASP.NET version 3.5 is ASP.NET version 2.0 with some additional features, such as the ASP.NET
AJAX framework and LINQ.
Web.configfile for ASP.NET 3.5 applications includes a
<configSections>section that defines additional configuration elements. In particular, it defines a configuration section named
<system.web.extensions>. In short, the
<configSections>says to the ASP.NET configuration system, "Hey, you may see a section in
<system.web.extensions>. If you do, let
System.Web.Configuration.SystemWebExtensionsSectionGroupparse the configuration markup." (Note that the default
Web.configfor ASP.NET 3.5 doesn't have a
<system.web.extensions>section, it just says that such a section can appear.)
<system.web.extensions> section is used by the ASP.NET AJAX framework for defining how Web services
are called from the framework's client-side script. For more information on this section, see
Configuring ASP.NET AJAX.
Additional Assemblies in the
Another added feature in the default
Web.configfile for ASP.NET 3.5 applications is the
<assemblies>element within the
<assemblies>element specifies the collection of assembly names that are used in the compilation of ASP.NET pages. This section adds a few addition assemblies to the collection, namely assemblies that are new to the .NET Framework version 3.5.
When the .NET Framework version 3.5 is installed, it places these new assemblies in the machine's Global Assembly Cache (GAC).
New Namespaces in the
In addition to adding new assembly names, the default
Web.configfile also adds the corresponding namespaces to the
<namespaces>section. In particular, two LINQ-related namespaces are added (
System.Xml.Linq) as well as the
System.Collections.Genericnamespace. Generics are not new to version 3.5 - they were introduced with version 2.0 - but previously the
System.Collections.Genericnamespace was not imported by default.
New Control Prefixes Added Via the
ASP.NET 3.5 introduces two new Web controls - the ListView and DataPager - as well as a number of AJAX-related controls. In order to use these controls in an ASP.NET page, the assemblies need to be registered with a particular prefix. This registration can occur at the page-level (in the
@Registerdirective) or in
<controls>element. Here, the
<controls>element registers two assemblies, both with the control prefix
asp. In short, this registration allows for the ListView, DataPager, and AJAX-related controls in the
System.Web.Extensionsassembly to be used like:
<asp:ListView runat="server" ... />.
New HTTP Handlers and Modules
The ASP.NET AJAX framework use a variety of HTTP Handlers and Modules. These Handlers and Modules do different things, from returning the script used by the framework to perform asynchronous postbacks to allowing for Web Service message calls to be encoded using JSON (as opposed to XML).
The Microsoft .NET Framework CodeDom, or Code Document Object Model, is a variety of classes that can be used to dynamically generate and compile and execute code at runtime. Visual Studio 2008 offers tools that allow a developer to create data access models that get converted into code at runtime. This conversion from a data model to code is possible because of the CodeDom.
<system.codedom> section in
Web.config provides instructions as to how the CodeDom should compile the
source code at runtime. In particular, the markup in the default
Web.config for ASP.NET 3.5 applications instructs
the CodeDom to compile against the .NET Framework version 3.5.
For more information on the CodeDom, check out Brian Korzeniowski's article, Microsoft
.NET CodeDom Technology.
Web Server Settings in
<system.webServer>section removes the AJAX-related HTTP Handlers and Modules added in the
httpModulessection, and readds them with configuration settings that allow these Handlers and Modules to be used in IIS 7's integrated pipeline.
In short, the latest version of Microsoft's production-grade Web server software, IIS, allows for the ASP.NET and IIS pipelines to be integrated so that managed HTTP Modules and Handlers can execute during IIS's native pipeline workflow. This integration allows for features like forms authentication and URL authorization to be used for any incoming resource (not just ASP.NET resources). For more information, see How to Take Advantage of the IIS 7 Integrated Pipline
If you are not using IIS 7, you can remove the
<system.webServer> section altogether, although there is
no harm in leaving it as-is.
Prior to ASP.NET 3.5, the ASP.NET AJAX framework was implemented as a stand-alone assembly (
System.Web.Extensions). The .NET Framework version 3.5 usurped the AJAX framework, making it part of the framework. The
<assemblyBinding>s section in the default
Web.configfile for ASP.NET 3.5 applications simply states that any references to the pre-3.5 version of the ASP.NET AJAX framework should, instead, use the version that's part of the 3.5 framework.
Web.configgenerated by Visual Studio 2008 can look quite intimidating since it includes a plethora of configuration elements not found in the default
Web.configfile generated by Visual Studio 2005. Moreover, these additional configuration elements are automatically added when opening a 2.0 application in Visual Studio 2008. These added configuration elements update the application so that it can seamlessly utilize the new 3.5 features, such as the ASP.NET AJAX framework and LINQ.