A while back, Steve Smith brought up a recurring problem I think most of us have bumped into, which is having things like HttpHandlers and HttpModules that are setup in a root web.config being loaded in child/sub-applications (a.k.a., virtual directories). I recall that in 1.x, you had to copy the related assemblies into the sub-apps and then specify the <remove /> or <clear /> attribute to remove them, which was less than ideal.
I didn't realize this had been fixed until Steve brought it up, and a good friend and all around nice guy, Scott Forsyth (of ORCS Web), clued us in to the new ASP.NET 2.0 configuration section information InheritInChildApplications attribute. By using this on the <location /> element, you can prevent child/sub-applications (a.k.a., virtual directories) from inheriting settings.
Of course, now there are multiple blogs entries about this:
If you want to know more details about this, you can read the MSDN info or any of these blogs. I don't want to beat a dead horse.
But, I would caution you that if you're using it to use it wisely. Sometimes you have settings that you do want inherited. For instance, it was recently brought to my attention that a certain Web site under my purview that was using this nifty technique was not in fact inheriting the <customErrors /> setting that I had defined on the root web.config. And when something unexpectedly changed (apparently, the ASP.NET compiler decided to add System.Web.RegularExpressions in the <assemblies /> section), it caused this less-well-designed sub-application to start barfing, showing the standard ASP.NET error page, including bits and pieces of the source.
Thankfully, the source itself was not sensitive nor was it even code that we had written because, of course, we would have never written our code in such a way as to have such errors (naturally!). But I was surprised to find out that our custom error page was not showing in any case, and it was due to this nifty little tweak of using the inheritInChildApplications attribute.
So the moral of the story is to use that feature with care and ensure that you only use it for sections that you really do want to isolate (e.g., <httpHandlers />, <httpModules />, and maybe <authentication />, depending on your setup). Keep sections like <compilation /> and <customErrors /> outside of that location tag so they'll be inherited, or you'll need to redefine them in sub-applications. The other moral of the story is that some developers seem to think that not using a custom error page is a travesty of epic proportions that cancels out all good in the world, so you want to be sure to define it and ensure it is either being inherited or redefined in sub-applications. Otherwise, you will face the wrath of these impeccable developers!