Web.config combinations going bad Incompatible entries and incompatible framework versions

Posted by Peter van Ooijen on June 21, 2006

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.

This entry was posted in ASP.NET. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://todotnet.com Sander

    I think there’s an easy solution.
    First you setup two application pools. One will be for ASP.NET 1.1 webapps, the other for v2.0 webapps.
    Then you go to the site or virtual directory and view its properties. There should be an ASP.NET tab available. Set this to the desired framework and select the appropriate application pool.
    That’s it! Both ASP.NET 1.1 and 2.0 sites can coexist peacefully.

  • http://codebetter.com/blogs/peter.van.ooijen/ pvanooijen

    hi Sander,
    I don’t think that will work as the 1.1 site (gs.nl/oma) is a subsite of the 2.0 site (gs.nl). It will find the (unintended) web.config despite being in another app-pool.
    In case I’m wrong, please elaborate.

  • http://todotnet.com Sander

    Sorry, I misinterpreted. Yes, it seems to be a bug http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=102118.
    A resolution may be to place the 1.1 site under it’s own domain (oma.gs.nl).

  • http://codebetter.com/blogs/peter.van.ooijen/ pvanooijen

    That’s OK. I don’t think it’s a bug, rather a design flaw.
    As oma is part of exchange I don’t want to move it to another domain. For now I’m happy without a web.config in the root.

  • http://flimflan.com/blog Joshua Flanagan

    There might be another solution, but I’m not sure if its better, or even if it would work. Something to try out.
    First, you can get rid of the namespace declaration in web.config without hurting anything.
    To deal with all of the unrecognized 2.0 handlers – you could create a custom ConfigurationSectionHandler which does absolutely nothing. You would then register each of the unrecognized sections (connectionStrings) with that handler in your ASP.NET 1.1 apps.

  • http://codebetter.com/blogs/peter.van.ooijen/ pvanooijen

    You can get rid of the namespace attribute. After that the app bumps into the connectionstrings node. I don’t know if that can be treated as a custom section as it’s not a sub-node of system.web.
    The next problem is that the 1.1 app is not my app, I have no idea if I can add a handler to that and what the risks are.

    But it does sound like an interesting experiment:)

  • http://flimflan.com/blog Joshua Flanagan

    Yes, you can register a handler for any node under configuration – it doesn’t need to be under system.web.

    And you can skip the part about “create a custom handler” – it looks like it already exists: System.Configuration.IgnoreSectionHandler

    Check out your 1.1 machine.config. It already has some sections registered for IgnoreSectionHandler. You could just register the handler for the .NET 2.0 specific sections in machine.config. Then you don’t need to modify the 1.1 app that you don’t control ;)

  • http://codebetter.com/blogs/peter.van.ooijen/ pvanooijen

    OK, sounds good. I’ll see if I can get to work, it’s interesring enough. In case I do i’t will be a new post. You’ll ge the credit :!

  • Alex

    I have the same problem and I’m trying to exclude the problematic sections with System.Configuration.IgnoreSectionHandler but I don’t know which one to exclude. Is there a way to which section causes the problem?

    Our Web config at the root of the web site has very little sections in it. ApplicationSettings and ConnectionStrings. We still get the error

    Thanks a lot

    Alex

  • http://codebetter.com/blogs/peter.van.ooijen/ pvanooijen

    Both these sections are 2.0 specific, so your 1.1 app has to ignore them both

  • Alex

    Thanks
    I Got rid of connectionstring and namespace but applicationsettings causes me a problem. It’s a sectionGroup with a type attribute and I can’t ignore it successfully.

    The “type” attribute is not handled by 1.1
    Do I need to exclude each section in a section group or the section group ittself should be enough? (I already tried both without success)

    Thanks!!

    Alex