Chris May

I recently migrated one of the web applications I work on frequently to make use of the newly released ASP.NET AJAX toolkit.

In order to make this work, a bunch of changes were needed in the web.config.  So many in fact that I decided to merge my web.config file into theirs, rather than vice versa.

After all was done and working, we started getting a few javascript errors in stuff unrelated to any ajax controls.

After some investigation I relized that the naming convention for controls had changed.

Controls that used to be named ASDF:ZXCV were now named ASDF_ZXCV.

So in some instances we had javascript looking for elements where the element name was hard coded as "ASDF:ZXCV".  Of course the correct way to get the element name is to use the ClientId property of the control, but that was not used 100% of the time on our site. 

The problem is that when I upgraded the application from .Net 1.1 to a .Net 2.0 web application project, the upgrade tool included an item in the web.config file that was intended to ease the transition.

<xhtmlConformance mode="Legacy"/>

In ASP.NET 2.0, by default all rendered content is well formed XHTML.  This was different from ASP.NET 1.1.  By setting the xhtmlConformance mode to Legacy, it would not force the output to be XHTML compliant.

Another effect that this has, is the naming of controls.  When Legacy is turned on, control hierarchies are separated by a colon ":".  In standard mode, they are separated by a dollar sign "$" in the name property, and an underscore "_" in the ID property.

This can be seen if you use reflector on the control class, you can see this:

internal char IdSeparatorFromConfig
{
    get
    {
        if (!this.EnableLegacyRendering)
        {
            return '$';
        }
        return ':';
    }
}

In 99% of the places where we reference asp.net generated code, we relied on the ClientId property, so we had no problems.  But in that 1% of places where we took the shortcut of hard coding in the element, we got JS errors.