Dan Maharry

Writing about web development since 1997

ASP.NET 4.0, Part 3: Someone has stolen web.config!

Welcome to part 3 of my tour through ASP.NET 4.0. In this instalment, we'll be investigating the 'new look' web.config file for ASP.NET 4.0 websites and recapping the config file hierarchy that .NET uses.

One of the more startling changes in ASP.NET 4.0 projects is in web.config. Or, rather in the lack of web.config. In VS2008 SP1, the default web.config was 139 lines long. The new one is 6 (yes, SIX) lines long. It now looks like this:

<?xml version="1.0"?> 
    <compilation debug="true" targetFramework="4.0" /> 

The thing with web.config is that as features have been added into ASP.NET in .NET 3.0, 3.5, 3.5SP1 and the out of band releases, web.config has grown to accommodate them. Routing worked if you added ten more lines; charting another ten and so on. As .NET 4.0 has offered the ASP.NET team a crack at refactoring their base libraries and folding some of these post-v2.0 features in, the same has been true of ASP.NET configuration. Thus the team in Building 42 have taken all 139 lines of 3.5 SP1 config and pushed all the common options – which translates to pretty much everything - into the machine-level web.config file on your server. The net result is that the brand new svelte web.config file in ASP.NET 4 is 6 lines of XML and no more.

The only settings left in your web.config then are the two compilation settings needed immediately for your project.

  • debug is set to “true” for Web Application projects and “false” for Web Site projects
  • targetFramework sets which version of the framework the website is to be built against. Possible values are 4.0, 3.5, 3.0 and 2.0. This is very handy when upgrading older web projects to v4.0 or indeed for reminding IIS and ASP.NET that this should continue to use a previous version of the framework.

Intellisense is your friend for adding more of your own settings to web.config and is always available in VS2010 except when opening old web.config files with the default namespace added to the root <configuration> element.

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

In this case, as with VS2005 and VS2008, you’ll have to delete the namespace and xmlns attribute before intellisense becomes available.

The *.config hierarchy

So a number of features such as Dynamic Data, routing and charting are all enabled by default for the first time. Within the machine-level web.config file. If you're unfamiliar with the idea of the config file hierarchy, let's review. In essence, these config files work like stylesheets, cascading values down from the least-specific machine.config file to the most specific directory-level web.config file.

  • The Machine-wide root config file is called machine.config. It contains the standard default settings for all .NET libraries as well as System.Web. You’ll find it in C:\Windows\Microsoft.NET\Framework\ v4.0.xyz\Config
  • The machine level web.config file builds on the settings laid out in machine.config and defines all the web-specific defaults for web projects that you create. This is the file where most of the old site-level web.config has been refactored to. You’ll also find it in C:\Windows\Microsoft.NET\Framework\ v4.0.xyz\Config
  • Also in C:\Windows\Microsoft.NET\Framework\ v4.0.xyz\Config, you’ll have noticed several more (policy) config files called web_hightrust.config, web_mediumtrust.config, web_lowtrust.config and web_minimaltrust.config. If you set the Trust level for your site or server to a value other than the default of “Full”, the settings in the corresponding policy config file listed here will be added to the machine level web.config file. More about trust levels, policy config files and defining your own trust level can be found here.
  • The site level web.config file is the one you edit within your project file. It is located in the root directory of your website. It inherits all the settings from the machine level web.config file.
  • Add another web.config file to any directory under the root of your web project and you can override or augment your site-level web.config file further just for the directory it lives in.

You can read more about the ASP.NET Configuration hierarchy and inheritance in this MSDN article.

Sitting to the side of this chain of config files, is aspnet.config, which you’ll find in C:\Windows\Microsoft.NET\Framework\v4.0.xyz. As we’ll see later on in this series when we look at the new performance counters for ASP.NET in IIS, this is the file to alter when you need to change how IIS executes ASP.NET page requests.

Next time, we’ll look at the new config transformation files built into VS2010 that ensure your config files are correct for whichever build scenario you’re targeting them at. Happy coding!

Pingbacks and trackbacks (5)+

Comments are closed