Scott Forsyth's Blog

Postings on IIS, ASP.NET, SQL Server, Webfarms and general system admin.

Cloud Resources

IIS Resources

ASP.NET files and inheritance

I've been completely silent on my blog for a few months while having my head down in projects, but I thought I should start up some activity, even if it's a quickie.  I feel that I've been covering so much ground but not enough time to report on it.

I was asked today about ASP.NET web.config inheritance.  Understanding which ASP.NET files and folders are inherited through folders and applications makes development and troubleshooting so much easier.

Here is the summary to keep in mind:

  • web.config files inherit all the way down the tree, past all application boundaries.
  • global.asax only lives within its application
  • /bin and the /app_{folders} only live within their application

So, this means that anything set in the root web.config file will inherit down the entire site, even if some folders are marked as applications. 

Where this gets messy is if the web.config file has references to assemblies but sub-applications don't have those assemblies.  For example, let's say that you have a HTTP Module configured in the root of the site and referenced from the site web.config file.  If you have a sub-application called /subfolder which is marked as an application, then /subfolder will attempt to load the HTTP Handler from /subfolder/bin.  Since it doesn't exist, an error will be thrown. 

There are multiple ways around this.  Probably the cleanest if the HTTP Handler isn't needed in /subfolder is by 'removing' the reference by adding a <remove> clause in the /subfolder/web.config file.  You can do this with <remove name="name" />.   Here is an example of how to remove a HTTP Module in a subfolder:

      <remove name="ErrorLog"/>

Here is what the site web.config might look like:

      <add name="ErrorLog"  type="GotDotNet.Elmah.ErrorLogModule, GotDotNet.Elmah, Version=1.0.5527.0, Culture=neutral, PublicKeyToken=978d5e1bd64b33e5" />

A property on the other hand will need to be set to nothing.  For example, let's say that your site web.config file has <pages styleSheetTheme="SiteTheme" /> set.

That setting will carry all the way down the site, past all application barriers.  But, let's say that a sub-application doesn't have the App_Theme set, an error will be thrown in the sub-application.  One solution is to add the following to the sub-application's web.config file.

<pages styleSheetTheme="" />

As I mentioned above, there are multiple solutions.  Another solution is to put a copy of the assembly or App_Theme folder in the sub-applications.  Yet another option as a last resolve is to put a skeleton assembly just to keep the web.config settings happy.  There should be little reason to resort to this though.

For the themes and other properties of that nature, you can usually override them either implicitly or explicitly from the page or code-behind.

Another situation to keep in mind is if you set some folders that use ASP.NET v1.x and others that use ASP.NET v2.x.  The site web.config will be used by both frameworks.  With this in mind, make sure that you don't have something in one web.config file that isn't compatible with other framework versions further down the same site path.  For example, setting the <connectionStrings> section of web.config will cause an error with v1.x of the framework.  Of course this only happens in the rare situation that you have ASP.NET v2.x in place with v1.x in a subfolder.  For example, if you have v1.x used for legacy testing, or to support part of the site that doesn't run on v2.x for some reason, then you may have this configuration

That's all there is to it.  Make sure to remember that web.config inherits all the way down the site tree but none of the other .NET files do and you'll be a step further in easier and more powerful development and troubleshooting.

Posted: Dec 29 2005, 09:40 AM by OWScott | with 16 comment(s)
Filed under:


Ian Doubell said:

This exact problem with an httpModule inherited in a sub site could not be fixed this way. The sub site still fell over with the remove tag in place. Very confusing.
# January 23, 2006 4:41 AM

Scott Forsyth said:

Unfortunately that is the case with v1.x of the framework. A recent project I've done in the last couple days brought this to light for me.

It works properly in v2.x but in previous versions the <remove /> in the vdir is applied after the <add /> in the root dir. The makeshift (put probably best) solution is to put a copy of the module in the vdir's bin folder just to make the web.config files happy. The <remove /> is still worthwhile if you don't want to run that module in the vdir, but it's not enough by itself.
# January 23, 2006 9:00 AM

csavvy said:

OMG...your weblog really helped me out.  I as having big problems as I was using dotnetnuke in my root web directory, but the settings in web.config were being inherited by child directories that I created other custom applications for underneath the root.  Using the remove tags worked very well in 2.0.  Thanks.

# December 4, 2006 7:05 PM

David said:

Likewise, your blog really helped out.  Was having the same problem, now I know why!

# January 11, 2007 8:02 PM

David Mackey said:

Thanks for the article. I was setting up a new site and had no idea how to get rid of the inheritance - your article worked wonders.

# January 14, 2007 12:38 AM

jaredbarr said:

If a sub application requires its own forms authentication,

root/ = 2.0 application requiring authentication

root/subapplication/ = 2.0 application requiring separation authentication

The subapplication will not seem to read the <authentication> section of its own web.config.  In fact it won't redirect to the root's login page either as authorization is required.  I have several upcoming apps which would require this but cannot understand how to have a web.config in a sub application to work.

# February 8, 2007 6:08 AM

Eric said:

Thanks for this great post. It helped me to successfully integrate a sub application into Community Server!

One useful addition may be this. If the root web.config has a pages setting like this:

<pages pageBaseType="SomeType, SomeAssembly" /> and that assembly is in the root's bin directory. The best way to 'undo' this in the subapplication is to add the pages tag but replace the pageBaseType with the default ASP .NET page, like so:

<pages pageBaseType="System.Web.UI.Page" />

Thanks again!

# February 10, 2007 3:23 PM

Claire said:

Thanks for the clear explanation, this can be very confusing the first time you plonk a website in a subdirectory.  

You can also use <clear /> inside <httpModules />

And to clear <add verb="" path="" /> settings within <httpHandlers> use <remove verb="" path="" />

# February 14, 2007 8:38 AM

Rob said:

The following works for me:

Put the <add> in the root application. The sub app does not require any modifications or <remove> tags this way...

<add verb="GET" path="myhandler.axd" type="Module.Classname, Module" validate="false"/>

# March 30, 2007 9:44 AM

jrblack10 said:

I have been reading many Blogs on the issue of web.config and inheritance, and yours seems to clear up a few things for me, but I still have a problem.  I have a .Net 2 app in the root web and in virtual folders/web I have .Net 1.1 app (Reporting Services).

Below is my error:

Parser Error Message: Child nodes are not allowed.



      <controls> <- THIS IS REPORTED AS THE ERROR

          <add tagPrefix="asp"



              Version=1.0.61025.0, Culture=neutral,


If you can help clear this up, that would be GREAT!

# May 16, 2007 10:13 AM

Morten Pedersen said:

Thanks-very good post.

It also helped me to remove the assemblies loaded at the parent application like:

<compilation debug="true" defaultLanguage="c#">


       <remove assembly="S

# June 20, 2007 11:40 AM
Leave a Comment