ASP.NET 2.0 backwards compatible? NOT. Here’s an obvious one – level 200

Most RAD developers will probably not encounter this breaking change, but for me, this doesn’t seem like something obscure:

In my pages, I make my <HEAD/> element accessible from code:

Then, in my code-behind, I use:

protected HtmlGenericControl Head;

Then in code, I can add my title element as I need to, and I can add <meta/> elements programmatically. Well, I try to run this page under ASP.NET 2.0, and my VERY FIRST experience with ASP.NET 2.0 comes back with a big, fat ERROR screen.

Because the Page class in v2.0 has a Head property of type HtmlHead, my code will throw an error because I am accessing the HtmlHead Head; property through my HtmlGenericControl variable. It worked great in v1.1, but it’s definitely a breaking change in v2.0.

I don’t really have beef with this change because a quick modification to my code solves the issue. I do have beef, however, with the PR given to the “supposed“ backwards compatibility of v2.0. Almost every article and book you read about v2.0 will say, “Never fear, your v1.1 apps will run just fine on v2.0 because it’s 100% backwards compatible.“:

ASP.NET 2.0 Internals claims this in the first line, and a direct quote from Migrating from ASP.NET 1.x to ASP.NET 2.0: ”If you have ASP.NET 1.x applications in production, you will be relieved to know that ASP.NET 2.0 is fully backwards compatible. That is, your ASP.NET 1.x applications will run as normal on ASP.NET 2.0 without any changes.” Well, my ASP.NET 1.1 application would not run on ASP.NET 2.0 without any changes.

I wish they would just be truthful. I think statements like that are plain lies. I have no problem with new versions have some published compatibility issues. I know there will always be issues. I just want to know about them.

Microsoft, I love you, but if you say something, I would like to believe it. In this case, I wonder what other incompatibilities exist.

-now I await the inevitable comment that will prove me ignorant and misinformed. . . 🙂

Kevin Daly 5:12 pm on August 16, 2004

I think MS would argue that they can’t guarantee not breaking an unsupported feature, such as Head exposed to the server.
I was doing the same thing with Title for a while but it drove me nuts because any change to the UI would wipe the runat="server" attribute.
Anders Norås 7:32 am on August 17, 2004

The head element in the ASP.NET 2.0 page template is by default declared to run at the server. In addition the System.Web.UI.HtmlControls namespace has a new class called HtmlHead defined. When you set the id attribute of the head element to “Head” this becomes a member of your class (which inherits from System.Web.UI.Page).
The reason for you not seeing the code defining this member is that ASP.NET 2.0 uses partial classes to separate user defined code from tool generated code.
As a result of this you get a member naming conflict when defining an additional member called “Head” typed System.Web.UI.HtmlControls.HtmlGenericControl.

To solve your problem using your existing code which I reckon is similar to this:
ASPX snippet:
<head id="Head" runat="server">

Codebehind snippet:
protected HtmlGenericControl Head;
private void Page_Load(object sender, System.EventArgs e)
{
HtmlGenericControl meta=new HtmlGenericControl("meta");
meta.Attributes.Add("name","pragma");
meta.Attributes.Add("content","no-cache");
Head.Controls.Add(meta);
}

Remove the declaration of the “Head” member in the code behind file.

Another option is to add your metadata using the Page.Header.Metadata collection like this:
Page.Header.Metadata.Add("name", "pragma");
Page.Header.Metadata.Add(“content”,”no-cache”):
Jeffrey Palermo 9:34 am on August 17, 2004

Yeah, that’s exactly what I did to fix it. I decided to make this post to make this issue public. The more I dive into Whidbey, the more issues I encounter. Yes, there are always workarounds, but I wish v2.0 wasn’t touted as 100% compatible.
Sam 1:12 pm on May 4, 2005

Page.Header.Metadata.Add no longer works in the April 2005 beta. Not sure why they removed it, but its gone… wondering if there is another easier way now, so far I have not found it.

Sam
TeroTech.Com 10:49 am on May 18, 2005

Exactly my problem 🙁 …. why remove something that wasn’t broken in the first place !!

Comments are closed.

Programming with Palermo

Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert

ASP.NET 2.0 backwards compatible? NOT. Here’s an obvious one – level 200

Related