The Artima Developer Community
Sponsored Link

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

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Peter van Ooijen

Posts: 284
Nickname: petergekko
Registered: Sep, 2003

Peter van Ooijen is a .NET devloper/architect for Gekko Software
Web.config combinations going bad Incompatible entries and incompatible framework versions Posted: Jun 21, 2006 2:41 PM
Reply to this message Reply

This post originated from an RSS feed registered with .NET Buzz by Peter van Ooijen.
Original Post: Web.config combinations going bad Incompatible entries and incompatible framework versions
Feed Title: Peter's Gekko
Feed URL: /error.htm?aspxerrorpath=/blogs/peter.van.ooijen/rss.aspx
Feed Description: My weblog cotains tips tricks and opinions on ASP.NET, tablet PC's and tech in general.
Latest .NET Buzz Posts
Latest .NET Buzz Posts by Peter van Ooijen
Latest Posts From Peter's Gekko

Advertisement

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.

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

Topic: [INETA] Technology Webcast Series Continues Previous Topic   Next Topic Topic: Feeding Frenzy Episode 1

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use