If you've had a chance to check out Visual Studio 2008, you may have noticed that it creates a rather verbose Web.config
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
application's 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.config
file looks something like the following. (I've removed comments for brevity)
The <configuration> element is the XML document's root element. The default Web.config created
by Visual Studio 2005 adds three child elements to the <configuration> element:
<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.
Within the default Web.config file's <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.
Of course, these six elements are but a few of the many possible elements that may appear in the configuration file. But
these are the default ones that are entered by Visual Studio 2005.
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 Web.config file.
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.
The <configSections> Section
The default Web.config file 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 Web.config named <system.web.extensions>. If you do, let System.Web.Configuration.SystemWebExtensionsSectionGroup
parse the configuration markup." (Note that the default Web.config for ASP.NET 3.5 doesn't have a <system.web.extensions> section, it just
says that such a section can appear.)
The <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 <compilation> Section
Another added feature in the default Web.config file for ASP.NET 3.5 applications is the <assemblies>
element within the <compilation> element. 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 <namespaces> Element
In addition to adding new assembly names, the default Web.config file also adds the corresponding namespaces to
the <namespaces> section. In particular, two LINQ-related namespaces are added (System.Linq
and System.Xml.Linq) as well as the System.Collections.Generic namespace. Generics
are not new to version 3.5 - they were introduced with version 2.0 - but previously the System.Collections.Generic namespace
was not imported by default.
New Control Prefixes Added Via the <controls> Section
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 @Register
directive) or in Web.config in the <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.UI and System.Web.UI.WebControls
in the System.Web.Extensions assembly 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 <system.codedom> Section
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.
The <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>
The <system.webServer> section removes the AJAX-related HTTP Handlers and Modules added in the httpHandlers
and httpModules section, 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.
Updated <assemblyBinding>s
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.config file 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.
Conclusion
The default Web.config generated by Visual Studio 2008 can look quite intimidating since it includes a plethora
of configuration elements not found in the default Web.config file 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.
