When an asp.net application is started it processes the web.config file. Doing so it is combined with with all web.config files found up in the tree of virtual directories. Suppose you have a website located at www.YourSite.com/NiceWebApp/ and some supporting webservices like www.YourSite.com/NiceWebApp/Services/NiceService.asmx. When the webservice is loaded by the webserver the web.config of the NiceWebApp is read as well. Even when the physical path does not have a tree structure. This is nice, the site and service can share settings. Administering the settings can be done in one place: the site.
But things can go wrong as well. Suppose the website uses a custom role and membership provider. The code is in the app_code dir of the site, the web.config of the site loads it. This is a part of the site's web.config
<roleManager defaultProvider="DirActivityRoleProvider"
enabled="true"
cacheRolesInCookie="true"
cookieName=".ASPROLES"
cookieTimeout="10"
cookiePath="/"
cookieRequireSSL="false"
cookieSlidingExpiration="true"
cookieProtection="All" >
<providers>
<clear />
<add
name="DirActivityRoleProvider"
type="DirActivity.WebSite.DaWsRoleProvider"
applicationName="DirActivity" />
</providers>
</roleManager>
<membership defaultProvider="DirActivityMemberProvider" userIsOnlineTimeWindow="15">
<providers>
<remove name="AspNetSqlProvider" />
<add name="DirActivityMemberProvider"
type="DirActivity.WebSite.DaWsMemberShipProvider"
enablePasswordRetrieval="true"
enablePasswordReset="false"
requiresQuestionAndAnswer="false"
passwordFormat="Hashed"
applicationName="/" />
</providers>
</membership>
<pages theme="DirActivityTheme">
</pages>
It loads and configures a roleManger, a membership provider and sets a theme for the pages.
Now when the service loads it will also read and try to process the web.config of the site. Doing so it will try to load the assemblies for the custom providers and the theme stylesheet. It can't find any of them and the service will crash on each of them. To prevent this you have to reset all of this in the web.config of the service and explicitly clear the provider lists.
<roleManager enabled="false">
<providers>
<clear/>
</providers>
</roleManager>
<membership>
<providers>
<clear/>
</providers>
</membership>
<pages theme=""></pages>
As you can see the different entries have different possibilities to knock them out .
ASP.NET 1.1 and 2.0 running on the same web server
The example above deals with two asp.net 2.0 applications. Things get worse when an asp.net 1.1 app enters the stage. This will also try to process all files named web.config up in the virtual directory tree, regardless of their intended framework version. That's not to good. The real bad thing is that asp.net does not understand an asp.net 2.0 config file. It will first crash on the xmlns attribute of the configuration node, after that on the connectionstrings node and so on. Now suppose the root of your web site is an asp.net 2.0 application and in one the sub directories lives an asp.net 1.1 application. This is what happened to me, my site is the 2.0 site and inside lives Outlook Mobile Access which is an asp.net 1.1 application. I know you shouldn't combine all of that in one server but resources are limited, I have to get this rolling and am learning step by step. The site needs some configuration settings in a web.config in the root, oma will try to process that and will crash. Googling around I found this a problem many people wrestle with, but in a comment on a desperate post by Rick Strahl I found an easy solution which works perfect for me.
After reading in all web.configs up the tree asp.net 2 finally combines the settings with the web.config found in the \WINDOWS\Microsoft.NET\Framework\version\CONFIG. For a 2.0 app it will read the one in \WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG, for a 1.1 app it will not see this file. I moved the settings from the web.config in the root to this file and deleted the file in the root. Now all apps are quite happy: the 2.0 root has its settings and the 1.1 one isn't blinded by them. Only the administration is a little harder as this web.config is somewhat larger. I can live with that.