CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Peter's Gekko

public Blog MyNotepad : Imho { }

ASP.NET 1.1 working with an ASP.NET 2.0 web.config file

In a recent post I described the trouble an asp.net 1.1 application has with a web.config file targeted at asp.net 2.0. The main problem is that the asp.net 1.1. runtime does not understand parts of the 2.0 web.config and crashes. My first solution was to move settings to the global 2.0 config. In a brilliant comment Joshua Flanagan suggested to bring the problem to its owner. His idea was to teach asp.net 1.1 the 2.0 specific sections and tell it to ignore them. This sounds more complicated than it is and works well.

For a good overview of the web.config in 1.x I again recommend James Avery little book,  I blogged before on that. The global configuration of asp.net 1.x is in the machine.config file in \WINDOWS\Microsoft.NET\Framework\v1.x\CONFIG. (Note that 1.x does not have a global web.config like 2.0). This file has a list of sections and the assemblies to handle the sections. The framework has a very handy handler, the IgnoreSectionHandler. Which does exactly what's desired: nothing. This snippet tells asp.net to ignore the connectionstrings section

<?xml version="1.0" encoding="utf-8"?>

<configuration>

 

  <configSections>

    <!-- tell .NET Framework to ignore 2.0 sections -->

    <section

        name="connectionStrings"

        type="System.Configuration.IgnoreSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

        allowLocation="false" />

 

    <!-- tell .NET Framework to ignore CLR sections -->

    <section

        name="runtime"

        type="System.Configuration.IgnoreSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

        allowLocation="false" />

    <section

        name="mscorlib"

Entering it is easy, copy the runtime section, just below and change the name attribute. Asp.net has far more sections than 1.1, like the system.web.rolemanager and system.web.membership, which came by in the previous post. Add the sections as needed. Perhaps it would have been nice if there was an installation tool  which modifies the 1.x machine.config for all 2.0 specific sections. Hey MS, are you listening?

There is one incompatibility which is not handled. In 2.0 the configuration node has a namespace attribute.

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

  <appSettings/>

  <connectionStrings>

1.x trips over that. Delete the attribute:

<configuration>

  <appSettings/>

  <connectionStrings>

Asp.net 2.0 works without it. Assigning a namespace might be useful for future versioning, but it hinders backward compatibility.


Published Jun 23 2006, 05:05 AM by pvanooijen
Filed under:

Comments

pvanooijen said:

Afaik you can only apply a handler on a full section, not on a part (childnode). Correct me when I'm wrong. (and tell how to do it :))


 
# July 27, 2006 6:44 AM

Fraknlin said:

In case you haven't found a solution to handling child nodes, try something such as this:

<sectionGroup name="system.web">

<section name="xhtmlConformance" type="System.Web.Configuration.HttpCapabilitiesSectionHandler, System.Web, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

</sectionGroup>

In this manner, I can selectively ignore child nodes of <system.web>

# October 4, 2006 5:13 PM

Franklin said:

Rather it should be

<section name=[someName] type="System.Configuration.IgnoreSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowLocation="false"/>

# October 4, 2006 5:17 PM

pvanooijen said:

thanks Franklin, that's cool !

# October 5, 2006 4:17 AM

Ryan Lee said:

Thanks Peter, and all other for your suggestions/work.

I found a simpler way around the problem. It was almost an accident that I discovered it, but here it is...

All Web.config's will be read recursively back to the physical root from the origin (as you have explained) so that presents a problem when you need a virtual directory somewhere (anywhere) in the site. Wherever you input it, it will always be under the root, so it will have the same problem.

I discovered that if I moved my root app to a sub-directory and then re-mapped the root of my site to that sub-directory (having had already mapped the problematic virtual sub-directory first) that both sites now worked and only one or the other web.config files were parsed.

The web apps behave exactly as they should, because they are "virtually" in the same places as they were before. :-)

BTW, my root web-app is DotNetNuke 4 (using asp.net 2.0) and my custom web-app (asp.net 1.1) in the virtual directory.

I had already switched the 1.1 virtual directory to use the appropriate framework version in the asp.net tab (properties) prior to encountering the problem at hand.

# October 15, 2006 7:32 PM

pvanooijen said:

thanks for your approach but I'm afraid it will not be that easy in my scenario to implement it. The 2.0 app is the www root of my public site. The 1.1 apps are Exchange owa and oma. Once these are running you don't want to start fiddeling with them :) For now I'm quite happy with my solution, it has been running stable for months.

# October 16, 2006 8:28 AM

gabe said:

I dont think this method will work if you define a custom section group in the web.cong.  .NET 2.0 supports a new attribute (type) on the section group where 1.1 did not.  And telling 1.1 to ignore the section group section is not going to fly.

So I think with any sections that have new attributes that you cannot ignore you are going to run into an issue.  Is this correct?

# November 15, 2006 2:25 PM

pvanooijen said:

There is only one way to find out: juts try :) You will know the moment the 1.1. app tries to load.

But I think you are right and 1,1 will trip.

# November 15, 2006 2:46 PM

kevin said:

This technique fails if a new attribute is part of the 2.0 definition.  As suggested by gabe.

# May 23, 2007 5:10 PM

kendall said:

a solution to the child nodes issue is to create a "pages" _sectionGroup_ within the "system.web" sectionGroup, and then have a section for the "namespaces" child node.  so far, this is working as expected.  note that the sectionGroup for system.web already exists so you should put the "pages" sectionGroup within that.  also note that by default there is a "pages" section within system.web that needs to be moved to the new "pages" sectionGroup.  below is an example:

<sectionGroup name="system.web">

    <sectionGroup name="pages">

         <section name="pages" type="System.Web.UI.PagesConfigurationHandler, System.Web, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

         <section name="namespaces" type="System.Configuration.IgnoreSectionHandler, System, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowLocation="false" />

    </sectionGroup> <!-- end pages sectionGroup -->

... <!-- all the rest of the system.web sectionGroup goes here -->

</sectionGroup> <!-- end system.web sectionGroup -->

# July 2, 2007 5:01 PM

pvanooijen said:

Thanks, that's a welcome addition :)

# July 5, 2007 5:35 AM

Chris Larson said:

I had the same probem, and I tried some of the approaches described above, none of which worked (separate app pools & ignore section).

I also have the problem that my root web is the public site, so separate domains won't work for me.

I then found this: www.velocityreviews.com/.../t372410-running-a-11-app-under-a-20-root-web.html, which did work.  Note that there is not answer to the basic question he poses -- is there a problem doing this?

One more approach to working around this problem.

Chris

# July 13, 2007 1:16 PM

Duane McDowell said:

We had the same problem described in your entry here.

A bit of information about our situation.. we had a 1.1 web application that we decided to migrate to dotnet 2.0. When moving to the 2.0, we added some AJAX controls from the new ajax control library provided by microsoft.  Our Application also uses  Reporting Services 2000 in a virtual directory under the root.  I found your blog entry and your blog helped me understand what was going on with our Windows 2003/IIS 6.0 development server that was causing our Reporting Services 2000 to generate errors.

I discovered once I used the technique described here to tell Framework 1.1 to ignore the sections, that I still had a problem with the ajax sections of the web applications web.config.  Without the Ajax sections, Reporting Services would work.. With them I would get errors.

After some trial and error, I was able to get Reporting Services 2000  virtual directories to work if I took the ajax sections out of the application web.config and move them to the dotnet 2.0 framework web.config and the framework machine.config.

The question I have is.. is there a better way of handling this than the way I came up with?  

# August 2, 2007 2:43 PM

pvanooijen said:

You're lucky, it is working !

Sorry no, this post and the comments are everything and more I know off

# August 17, 2007 9:45 AM

Nnada kumar said:

Can i ignore child elements of <httpModule> and <httpHandlers>

# February 20, 2008 1:40 PM

pvanooijen said:

1.1. does understand these tags. But when 1.1 whil try to load a 2.0 handler or module assembly you're most likely in trouble.

# March 2, 2008 3:12 PM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add
Check out Devlicio.us!