mostlylucid

The BPA -Seattle...an aural pick-me-up for the mortally jaded...

Scott Galloway — Sat, 15 Nov 2008 09:19:26 GMT

Way too much information on Control IDs and ASP.NET 4.0 Client Id Enhancements

Scott Galloway — Mon, 03 Nov 2008 21:41:30 GMT

Of of the ASP.NET enhancements which first made an appearance in the Visual Studio 2010 PDC CTP release is the ability to set a client Id which you can be confident will be used when the control renders it’s markup.
All of the samples in this post will use the following Server Control:

using System.Web.UI;

using System.Web.UI.WebControls;

namespace TestControls

{

public class NamingPanel : Panel, INamingContainer

{ }

}

NamingPanel is very simple server control which just enables us to see the effect of ClientId without all the cruft that goes with using a more complex control (e.g, GridView).

How does the Control Id get defined now?

When used with a ‘nested’ NamingPanel, the following markup:

<tc:NamingPanel runat="server" id="rootPanel">
    <tc:NamingPanel runat="server" id="childPanel1">
    <asp:TextBox ID="TextBox" runat="server" Text="Hello!"></asp:TextBox>
    </tc:NamingPanel>
</tc:NamingPanel>

results in this rendered HTML:

As you can see the id “TextBox” defined in the original markup gets mangled to preserve ‘uniqueness’ by including the Ids of it’s parent controls within it’s own id attribute.
Whilst making the id attribute ‘unique’ does ensure that we can ensure that selecting a specific control client side using the id attribute will result in a single control, it does tend to get a bit verbose; the example above is only 2 levels deep, with more nesting; or even just using a control in Nested MasterPages can result in hugely long values for the Client Id…

The second major problem with the ‘unique’ Client Ids is that you can’t guarantee that your client Id will remain the same if you move a control from one ‘NamingContainer’ to another.

NOTE: A NamingContainer is a control which either directly or indirectly implements the INamingContainer interface. In essence it defines a ‘NameSpace’ for controls…you’d most commonly implement this interface on Composite Server Controls to ensure that any of the contained child controls are rendered with the parent ids prefixing their own Ids, ensuring they remain unique within the page.

What happens if you don’t specify an ‘id’ for one of these parent controls in markup? Given the following markup:

<tc:NamingPanel runat="server" id="rootPanel">
    <tc:NamingPanel runat="server">
    <asp:TextBox ID="TextBox" runat="server" Text="Hello!"></asp:TextBox>
    </tc:NamingPanel>
</tc:NamingPanel>

results in this rendered HTML:

Taking a look at the id for the TextBox you can see that there’s an odd name inserted in the id attribute “ctl00”, where did this come form? Well, in the System.Web.UI.Control class there’s a declaration as follows (note, this and all other source in the post is from the ASP.NET 2.0 source using Reflector):

private static readonly string[] automaticIDs = new string[] {

"ctl00", "ctl01", "ctl02", "ctl03", "ctl04", "ctl05", "ctl06", "ctl07", "ctl08", "ctl09", "ctl10", "ctl11", "ctl12", "ctl13", "ctl14", "ctl15",

"ctl16", "ctl17", "ctl18", "ctl19", "ctl20", "ctl21", "ctl22", "ctl23", "ctl24", "ctl25", "ctl26", "ctl27", "ctl28", "ctl29", "ctl30", "ctl31",

"ctl32", "ctl33", "ctl34", "ctl35", "ctl36", "ctl37", "ctl38", "ctl39", "ctl40", "ctl41", "ctl42", "ctl43", "ctl44", "ctl45", "ctl46", "ctl47",

"ctl48", "ctl49", "ctl50", "ctl51", "ctl52", "ctl53", "ctl54", "ctl55", "ctl56", "ctl57", "ctl58", "ctl59", "ctl60", "ctl61", "ctl62", "ctl63",

"ctl64", "ctl65", "ctl66", "ctl67", "ctl68", "ctl69", "ctl70", "ctl71", "ctl72", "ctl73", "ctl74", "ctl75", "ctl76", "ctl77", "ctl78", "ctl79",

"ctl80", "ctl81", "ctl82", "ctl83", "ctl84", "ctl85", "ctl86", "ctl87", "ctl88", "ctl89", "ctl90", "ctl91", "ctl92", "ctl93", "ctl94", "ctl95",

"ctl96", "ctl97", "ctl98", "ctl99", "ctl100", "ctl101", "ctl102", "ctl103", "ctl104", "ctl105", "ctl106", "ctl107", "ctl108", "ctl109", "ctl110", "ctl111",

"ctl112", "ctl113", "ctl114", "ctl115", "ctl116", "ctl117", "ctl118", "ctl119", "ctl120", "ctl121", "ctl122", "ctl123", "ctl124", "ctl125", "ctl126", "ctl127"

};

As you can see this defines an array containing some predefined IDs to be used when no id is specified for a control; again, this retains uniqueness for control names. At runtime the ID for the control is generated by reading the ‘UniqueID’ property of the Control class.

public virtual string UniqueID

{

get

{

if (this._cachedUniqueID == null)

{

Control namingContainer = this.NamingContainer;

if (namingContainer == null)

{

return this._id;

}

if (this._id == null)

{

this.GenerateAutomaticID();

}

if (this.Page == namingContainer)

{

this._cachedUniqueID = this._id;

}

else

{

string uniqueIDPrefix = namingContainer.GetUniqueIDPrefix();

if (uniqueIDPrefix.Length == 0)

{

return this._id;

}

this._cachedUniqueID = uniqueIDPrefix + this._id;

}

return this._cachedUniqueID;

}

As you can see this code has the following check:

if (this._id == null)

{

this.GenerateAutomaticID();

}

Simply, if there’s no id already in existence for the control at render time then one is generated using a call to the following method:

private void GenerateAutomaticID()

{

this.flags.Set(0x200000);

this._namingContainer.EnsureOccasionalFields();

int index = this._namingContainer._occasionalFields.NamedControlsID++;

if (this.EnableLegacyRendering)

{

this._id = "_ctl" + index.ToString(NumberFormatInfo.InvariantInfo);

}

else if (index < 0x80)

{

this._id = automaticIDs[index];

}

else

{

this._id = "ctl" + index.ToString(NumberFormatInfo.InvariantInfo);

}

this._namingContainer.DirtyNameTable();

}

As you can see, this method simply looks at the specified array of control names for the next ’ctlXXX’ value until it runs out then it generates one. The ctlXXX ‘counter’ restarts for each NamingContainer…so it’s pretty unlikely you’ll get to the end of the static array of control names. The ‘automaticIDs’ array is used simply as a performance optimization…saving even this very simple piece of code from running on each control rendering.

So What’s With the Control’s ‘Name’

In the examples in the previous section you can see that there’s not just an Id attribute, rather there’s also a ‘name’ attribute for each control, e.g., “rootPanel$childPanel1$TextBox". You’ll see that this looks really similar to the Id property (and is in fact generated using almost an identical code-path), so why are there two different attributes. In the simplest explanation, consider the ‘name’ attribute to be the ‘server side’ name and the ‘id’ attribute to be the client side one.
When you “post’ or ‘get’ a form in HTML the ‘name’ attribute links the specific HTML control to the value which gets posted back; this is where the ‘uniqueness’ part comes in. By being unique it’s possible to hook up the posted value back to the Control on the server, in addition this also specifies the correct event to call on postback.

NOTE: While in current ASP.NET, it’s possible to translate from the name attribute to the id attribute this is not guaranteed and will most likely break when using the new ASP.NET 4.0 functionality. We will not alter the ‘name’ attribute in ASP.NET 4.0…

Client Ids in DataBound Controls

The most critical reason for ensuring rendered controls have unique id attributes is controls within Data Bound controls. As an example the following markup defines a simple ListView hooked up to the Northwind database:

<tc:NamingPanel runat="server" id="rootPanel">
<tc:NamingPanel runat="server">

          <asp:SqlDataSource ID="SqlDataSource1" runat="server" ConnectionString="<%$ ConnectionStrings:ConnectionString %>"
              SelectCommand="SELECT [ProductName] FROM [Alphabetical list of products]"></asp:SqlDataSource>
          <asp:ListView ID="ListView1" runat="server" DataSourceID="SqlDataSource1"
              onselectedindexchanged="ListView1_SelectedIndexChanged">
              <ItemTemplate>
                  <tr style="">
                      <td>
                          <asp:Label ID="ProductNameLabel" runat="server"
                              Text='<%# Eval("ProductName") %>' />
                      </td>
                  </tr>
              </ItemTemplate>
                  <LayoutTemplate>
                  <table runat="server">
                      <tr runat="server">
                          <td runat="server">
                              <table ID="itemPlaceholderContainer" runat="server" border="0" style="">
                                  <tr runat="server" style="">
                                      <th runat="server">
                                          ProductName</th>
                                  </tr>
                                  <tr ID="itemPlaceholder" runat="server">
                                  </tr>
                              </table>
                          </td>
                      </tr>
                      <tr runat="server">
                          <td runat="server" style="">
                          </td>
                      </tr>
                  </table>
              </LayoutTemplate>
          </asp:ListView>
      </tc:NamingPanel>
</tc:NamingPanel>

The markup above has the ListView inside the NamingPanels we had previously. This markup generates the following HTML (or a sinppet of it…)

    <table>
            <tr>
                <td>
                                <table id="rootPanel_ctl00_ListView1_itemPlaceholderContainer" border="0" style="">
                    <tr style="">
                        <th> ProductName</th>
                    </tr>
                    <tr style="">
                        <td>
                            <span id="rootPanel_ctl00_ListView1_ctrl0_ProductNameLabel">Chai</span>
                        </td>
                    </tr>

As you can see, the controls in the ListView are rendered using a mix of user-defined as well as auto-generated ids…this is great for ensuring the names are unique but pretty useless if you need to know the ids of the controls at render time…As an example it’s really difficult to ensure that client side code such as Javascript can easily identify a specific control within the page without mixing in the classic <%=Control.ClientId%> server side markup into the JS.

NOTE: Databound controls are more difficult than usual when trying to ensure unique control Ids you only have access to some of the container controls at design-time (e.g., ctrl0 in the above html is not accessible in the designer…so you can’t change the id without hooking into backend events).

More Control over Control Ids…ASP.NET 4.0 Client Ids

So, what are we doing in ASP.NET 4.0 to let you define the ids?

NOTE: The information below is different to the Visual Studio 10 PDC CTP VPC (love those acronyms!). Following the CTP release we refactored to remove the ‘set’ on the ClientId property…this is to improve the behavior of the API, previously the value you got back from ClientId would almost certainly not match the value you set. In the new API you set the Id parameter and can then ‘get’ the ClientId property…

IMPORTANT: The new Client Id functionality has no impact on the server side name of the control, so string myString = TextBox1.Text; is completely unaffected by the Client Id changing.

In order to enable you to have more control over Client Ids we added a of property on ‘System.Web.UI.Control’:

ClientIdMode

Legacy – This is exactly equivalent to the ASP.NET 2.0 Client Id behavior. This is also the default if no ClientIdMode property is set in the current control’s hierarchy.
Static – You set it, you get it…most controllable but potentially the least ‘safe’. If a control is set to ‘static’ ClientIdMode then exactly what you set for Id is used as the client id, no matter what naming container the control sits in.
Predictable – Mostly for use in DataBound controls, only uses ‘set’ Id attributes of parent Naming Containers (so, no automatic id generation using ‘ctlXXX’ names). This also works in conjunction with the DataBound control property RowClientIdSuffix to allow you to define the ‘uniquefying’ item for the specific row. Previously, the auto-generated name ctrl0…ctrl1…ctrl2…etc…was used to provide this uniqueifying function for controls in the rows of DataBound controls.
Inherit - Essentially the ‘default’ behavior for controls, explicitly setting ClientIdMode = ‘Inherit’ essentially clears the ClientIdMode for the current control and allows this and any child controls (which have either ‘Inherit’ as ClientIdMode or ClientIdMode not set) will take the ClientIdMode of any parent control (including Page and Config…see below)

Page

You can also set the ClientIdMode at Page level, this defines the default ClientIdMode for all controls within the current page…

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" ClientIdMode="Static"%>

Config

It’s also possible to set the ClientIdMode in the config section at either machine or application level…this defines the default ClientIdMode for all controls within all pages in the application.

<system.web>
<pages clientIdMode="Predictable"></pages>
</system.web>

So what can I do with that?

Restarting Control Naming

As mentioned earlier the client id for a control is derived from the NamingContainers in which the control sits in the Control Hierarchy, normally this is only the actual controls within the page (e.g., in DataBound controls), however when using MasterPages you can end up with ids as found in the following HTML:

Even though the TextBox shown in the HTML is only within two NamingContainers within the page, due to the way MasterPages hook together you wind up with a control id like the following: ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1

Obviously this is a pretty long id…guaranteed unique within the page but unnecessarily long for most purposed. In this example we now want to reduce the length of the rendered id and make it more user defined (so, shortened, no ctlXXX etc…). The easiest way to achieve this is the following

<tc:NamingPanel runat="server" ID="ParentPanel" ClientIdMode="Static">
    <tc:NamingPanel runat="server" ID="NamingPanel1" ClientIdMode=”Predictable">
        <asp:TextBox ID="TextBox1" runat="server" Text="Hello!"></asp:TextBox>
    </tc:NamingPanel>
</tc:NamingPanel>

In this sample (identical to earlier markup) we’ve set the ClientIdMode to ‘Static’ on the outermost NamingPanel as well as setting the next ‘Child’ control to ‘Predictable’. This results in this markup (note, the rest of the page, MasterPages etc,…is identical to the previous example)

Here we’ve essentially restarted the naming hierarchy for Controls to the outermost NamingPanel , eliminating the ContentPlaceHolder and MasterPage names from the id (note: the ‘name’ attribute is unaffected…meaning we retain the normal ASP.NET functionality for events, ViewState etc…). A nice side-effect of restarting the naming hierarchy is that even if the markup defining the NamingPanels is moved to a different ContentPlaceholder, the rendered Client Ids remain the same.

NOTE: The developer does now take more responsibility for ensuring that rendered Control Ids are unique…not doing so can break functionality which expect to find unique HTML elements for each Id (e.g., Javascript’s GetElementById()).

Predictable DataBound Client Ids

As we showed previously, the Client Ids generated for Controls within DataBound list controls are pretty messy and not really predictable…How does the new Client Id functionality help?

We want to achieve the following:

Shorten the Client Ids for Controls
Make the Client Id predictable
Make the Client Id unique across pages (rather than ‘within’ pages)

So, how do we do this?

<tc:NamingPanel runat="server" id="rootPanel">
<tc:NamingPanel runat="server">

          <asp:SqlDataSource ID="SqlDataSource1" runat="server" ConnectionString="<%$ ConnectionStrings:ConnectionString %>"
              SelectCommand="SELECT [ProductName], [ProductID] FROM [Alphabetical list of products]"></asp:SqlDataSource>
          <asp:ListView ID="ListView1" runat="server" DataSourceID="SqlDataSource1"
              onselectedindexchanged="ListView1_SelectedIndexChanged" ClientIdMode=”Predictable” RowClientIdSuffix=”ProductID”>
              <ItemTemplate>
                  <tr style="">
                      <td>
                          <asp:Label ID="ProductNameLabel" runat="server"
                              Text='<%# Eval("ProductName") %>' />
                      </td>
                  </tr>
              </ItemTemplate>
                  <LayoutTemplate>
                  <table runat="server">
                      <tr runat="server">
                          <td runat="server">
                              <table ID="itemPlaceholderContainer" runat="server" border="0" style="">
                                  <tr runat="server" style="">
                                      <th runat="server">
                                          ProductName</th>
                                  </tr>
                                  <tr ID="itemPlaceholder" runat="server">
                                  </tr>
                              </table>
                          </td>
                      </tr>
                      <tr runat="server">
                          <td runat="server" style="">
                          </td>
                      </tr>
                  </table>
              </LayoutTemplate>
          </asp:ListView>
      </tc:NamingPanel>
</tc:NamingPanel>

In the markup above, we have used the ClientIdMode and RowClientIdSuffix properties. RowClientIdSuffix is a property which can only be used in DataBound controls and actually differs based on the DataBound control it’s used with:

GridView: You can specify the name of a column in the DataSource or multiple columns which are then combined at runtime. As an example if you specified RowClientIdSuffix as “ProductName, ProductId” in a GridView then the rendered control Id would be "rootPanel_GridView1_ProductNameLabel_Chai_1”.

ListView: You can specify a single column in the DataSource which will be appended to the Client Id. As an example if you specified RowClientIdSuffix as “ProductName” in a ListViewthen the rendered control Id would be "rootPanel_ListView1_ProductNameLabel_1”. In this case the last ‘1’ comes from the ProductId of the DataItem.

Repeater: No RowClientIdSuffix property is allowed. In a Repeater the index of the Row is used. In the case above, you would wind up with "rootPanel_Repeater1_ProductNameLabel_0”. The ‘0’ is simply the index of the current row.

Note: FormView, DetailsView do not have multiple rows so do not have a RowClientIdSuffix property.

Conclusion

So, there you have it…I dare say I’ll post again in future about this topic, we have a sample app which will find it’s way onto Codeplex in the near future!

NOTE: In current CTP builds you cannot use UpdatePanels with controls when you use the new Client Id functionality. This is fixed internally and will work correctly in future public releases.

All about me...

Scott Galloway — Thu, 25 Sep 2008 02:57:52 GMT

Reading Phil and ScottHa's 'Five things you didn't know about me' posts and started one of my own...but I only got to number two before I realized that the rest are either very illegal / potentially career ending so I stopped. Anyway I haven't posted here for a while and I wanted to give my reader an update on what's happenin' wit me...

Features...the name MS gives to 'stuff that's in the product', working away on some WebForms stuff. Some stuff has already made it to the world. I've worked on the ability to specify your own Ids for controls (client side) and currently looking at some Routing stuff, improving how our controls render their content as well as a hodge-podge of other stuff for ASP.NET 4.0. In general I 'own' WebForms so all of my work revolves around improving the experience using this stuff.

Releases...if there's one thing the ASP.NET team does really well it's generate 'stuff', one of my responsibilities is how / where / when we release this 'stuff'; as an example we just released work from the ASP.NET QA team as well as 'Dynamic Language Support' updates. Doing this takes a lot of work for everyone involved, from the teams actually doing the work to my little part at the end where I make sure we're good to release stuff (legal, honest, useful) / do the physical release.

Process...probably my least favorite bit of my job, but a necessary one. All sorts of not very interesting stuff around navigating the bullshit that comes with working in a big company right through to dealing with incoming bugs / making sure dev's fixing them, PMs are making judgement calls and QA is testing the fixes. No-one likes doing it but my job's to buffer the team from all of the crap which inevitably goes along with what we do.

Community...one of my favorite bits of my job, working with groups like the ASP Insiders, events and generally looking after how the product team interacts with this stuff (and making sure we don't forget it!). Sounds easy but my (*heavily filtered) inbox gets >300 mails a day, about 10% of which are bang (!) mails...one of the hardest skills as a PM in MS is just managing your mail / keeping up with all the threads going on at any particular moment.

Personal life...pretty much dead. I made the decision after breaking up with my last girlfriend in March to take a year off and get things straight...5 years of continuous dating with a mean relationship length of ~2 months wasn't healthy.

So that's me...I'm a bit 'behind the scenes' on the team at the moment (well, compared to superstars like Haacked) but hey, I'm happy getting things done. I'll start speaking at conferences in the next few months...especially as my features will start getting more attention.

Mix tape!

Scott Galloway — Sat, 13 Sep 2008 04:18:30 GMT

ViewState does not suck...part 1

Scott Galloway — Tue, 09 Sep 2008 19:24:50 GMT

I was trawling through new posts on the ASP.NET blog site and came across this one from Tess (who is someone I should probably know but don’t…). What I found interesting (as well as the post which is excellent) was the first comment:

“When will MS simply drop the Viewstate completely? This is a good example of a solution to a problem that shouldn't be a problem to begin with. “

This got me to thinking, ViewState has gotten a really bad rap over the years (with notable exceptions). Let’s look at what ViewState actually is and why it might not be the villan it’s often painted out to be…

What is ViewState…at it’s simplest it’s a hidden field which contains data about the controls currently on the page. Really, that’s it…now it does this pretty cleverly, serializing a whole bunch of stuff into a Base64 encoded string (which can also be encrypted, validated etc…).

For those of us who wrote web apps back in the dark ages i.e., before ASP.NET, we remember the days where we had a bunch of hidden fields used to track changes in a page, and it was frankly a pain in the ass…it was far more transparent but a lot of grunt work just to track if a field’s value had changed / store some additional data in the page for use in postback. ViewState solves that problem pretty nicely actually.

So, what’s the problem people have? Two things:

1. people misuse it; it’s partly our fault and partly theirs.

From ‘Truly Understanding Viewstate’:

CASES OF MISUSE

a. Forcing a Default
b. Persisting static data
c. Persisting cheap data
d. Initializing child controls programmatically
e. Initializing dynamically created controls programmatically

Now, as I said it’s not entirely their fault…ViewState is enabled by default…if you bind a bunch of data to a DataBound Control then you’ll get a huge amount of ViewState serialized to and from the browser each time, it’s not that easy to figure out what having no ViewState will break / just enable it for certain controls and not others (which is what ControlState lets you do…just not for existing controls).
At it’s core the problem ViewState really has is that it’s a Leaky Abstraction; it’s ALMOST there but doesn’t quite hit the sweet spot nowadays…

So, how do you use ViewState correctly…what can you do to avoid the pitfalls?

Stay tuned!

John Lam’s Dev Kit

Scott Galloway — Mon, 08 Sep 2008 22:35:43 GMT

Kind of a ‘tools’ list but a great post on what John uses on his machine…a few new ones I hadn’t seen which is always nice!

Know Issues / Breaking changes in ASP.NET 3.5 SP1

Scott Galloway — Fri, 15 Aug 2008 00:44:22 GMT

UPDATE 08/27: Found a couple of more changes

We’re using this forum post to track our Breaking Changes / Known issues in the SP1 release. Initial text is below but please feel free to link to this forum post from any blogs etc...to track these changes.

I'll also keep this blog post updated with any changes...

With the release of ASP.NET in .NET 3.5 Service Pack 1 some breaking changes have been introduced. This post will be used to list those changes and any workarounds / fixes for these issues.

Issue: Dynamic Data fails on Entity Framework data models that contain 1->0..1 and *->1 database relations
Reason:
Dynamic Data fails on Entity Framework data models that contain 1->0..1 and *->1 database relations with an error like "'System.Web.UI.WebControls.EntityDataSourceWrapper' does not contain a property with the name 'Orders.OrderID'". These types of relationships occur in many databases including Northwind and AdventureWorks. The error is caused by a naming mismatch that Dynamic Data has with the wrapper objects being returned by the EntityDataSource.
Workaround:
We have a temporary fix available at: http://www.codeplex.com/aspnet/Release/ProjectReleases.aspx?ReleaseId=16367 which replaces the data model provider with one that names the properties correctly.

Issue: After installing .NET 3.5 SP1, a web site using a derived version of the UpdateProgress control may encounter the following exception: “A ProgressTemplate must be specified on UpdateProgress control with ID ‘id’.”

Reason:
In the .NET Framework 3.5, the UpdateProgress control enforced the requirement of a ProgressTemplate from it’s PreRender routine. A derived UpdateProgress control could subvert that requirement by overriding OnPreRender in the derived control, and avoiding calling base.OnPreRender. In the .NET Framework 3.5 SP1, the UpdateProgress control now uses CreateChildControls to instantiate the ProgressTemplate, causing the requirement to be enforced at a different point in the page life cycle, and preventing the OnPreRender technique from subverting the check.

Issue: Hidden files/folders inside App_Browsers are not ignored
Reason:
3.5SP1 does not “honor” the fact that _vti_cnf is Hidden… and it still tries to read it and parse the file inside that folder.. which results in this error.

Workaround:
At the moment the workaround is to simply delete _vti_cnf folder however we are still investigating a fix for this issue.

Issue: The HtmlForm action attribute is now honored when defined in declarative markup.
Reason:
3.5 SP1 added a settable Action property to the HtmlForm type. This new feature makes it much easier for developers to explicitly set the form’s action attribute for scenarios where a developer wants to use a different Url than the normal postback-generated Url. However this change also means that if the action attribute has been set in an .aspx page’s declarative markup, ASP.NET will use the setting from the markup when rendering a <form /> element.
Workaround:
Previous versions of ASP.NET always ignored the action attribute if it was present in the declarative markup for a <form /> element. Developers should remove the action attribute from their declarative markup to return to the original behavior where ASP.NET renders the postback Url.
Example:
Before (the action attribute was ignored by ASP.NET as dead code): <form name="form1" method="post" runat="server" action="test.aspx"></form>
3.5 SP1 (remove the action attribute to have ASP.NET render the postback Url): <form name="form1" method="post" runat="server" ></form>

Issue: After installing .NET 3.5 SP1, a web site using pageBaseType now encounters the following compilation error: “Make sure that the class defined in this code file matches the 'inherits' attribute.”
Reason:
The behavior you are seeing is the original behavior of ASP.NET 2.0. When the .NET Framework 3.5 and Visual Studio 2008 were introduced, a bug was introduced that affected certain pageBaseType scenarios that unfortunately were not intended. It seems as if you might have run into one of these scenarios. In the .NET Framework 3.5 SP1, the bug was fixed and these scenarios no longer occur; pageBaseType again works the same as in ASP.NET 2.0, as requested by customers. Unfortunately, this means that customers who have relied on the unintended behavior that was introduced in the .NET Framework 3.5 will now encounter problems when they run their applications.

We are now evaluating creating a HotFix for these scenarios and providing workarounds for customers to help with this issue.

Here are some details about the issue; we will post a more detailed description soon. The mismatch is caused by the class in the code file not being assignable to the pageBaseType that is defined in the web.config file. The sequence that occurs is this:

- During code generation for a page (MyPage.aspx) in a Web site, ASP.NET creates a separate class from the class that is defined in the code-behind file source (MyPage.aspx.cs). The web.config file’s pageBaseType value can be used in cases where you want all pages to have certain properties. It applies to all pages, not just to pages that do not have code-behind files.

- If MyPage.aspx has a CodeFile attribute and therefore inherits from a class that is defined in MyPage.aspx.cs, the class defined in MyPage.aspx.cs must extend the pageBaseType class.

Workarounds:
1. If the pageBaseType class (for example, MyBasePage) is not needed for all pages, you can remove it from the web.config file, or;

2. Where pages do require the pageBaseType value, modify the classes in the code-behind files to extend the base type. In the filename.aspx.cs code-behind file, make sure that the class inherits from the pageBaseType that is specified in the web.config file (for example, public partial class CodeFileClass : MyBasePage instead of public partial class CodeFileClass : System.Web.UI.Page).

3. An alternative workaround will allow you to add the following attribute to your page directive:

CodeFileBaseClass="System.Web.UI.Page"

Find my inane babble on Twitter

Scott Galloway — Wed, 13 Aug 2008 03:29:03 GMT

Keeping the noise down on the blog...you can find the non-lucid stuff on my Twitter feed (warning, cats and pancakes abound!)

Premature optimization and user perception...my pet project and CSS Sprites

Scott Galloway — Sat, 12 Jul 2008 02:54:36 GMT

One of the themes I'm looking at for vNext of ASP.NET is the optimization of sites by reducing the number of server requests required for a single page.
A new classic in the area of improving the perceived performance of your sites by reducing the number of server roundtrips is Steven Sounders book 'High Performance Websites'. Steven's book is very small, very readable and probably the best book on anything to do with the web that I've read in years.
This book was a huge revelation for me...I spent most of my coding career writing the slickest, highest performing code I could...and frankly thinking about the structure of the actualy pages the user sees would've been a better use of my time in a lot of cases. As an example,, this was one of the last sites which I worked on as a full time developer...the code is about the best I ever created, the DB is optimized up the wazoo and I very nearly killed myself trying to make it 'perfect'...but for the hundreds of hours I spent sweating blood over the code you could now spend a couple of thousand dollars on a faster server and improve the performance even more...(even ignoring the fact that it's HUGELY overengineered...even has it's own MVC system and templating feature...hey, I was bored!)
As servers get faster and programming frameworks get more efficient, the amount of time your web server actually spends processing a page, doing a DB request and whatever else it has to do to generate HTML gets smaller and smaller; with better use of caching, AJAX and other techniques it's likely that you page actually returns it's total content to the user in milliseconds.... You can really only make minimal gains to 'preceived performance' in your sites by optimizing the dynamic code in your web application these days...(and this will likely only reduce over time)

Welcome to Moore's law

The fact is that for 99% of web pages the issue is no longer really about optimizing the amount of time your page takes to return HTML content to the user...it's what happens afterwards which leads to poor download performance.

The Problem

Websites nowadays have more and more separate elements in a single webpage, images, css, js files, flash content, videos etc...often the number of requests sent from single page can take MANY (as in several orders of magnitude) times longer than the bit we developers commonly fret about. As an example a few seconds ago I requested the CNN homepage, the actual page of HTML content loaded in 222ms, but the OTHER 153 requests for the rest of the stuff the page needed took a total of 4.65s.
One way to avoid a large number of these other requests is to combine requests for multiple objects together. In ASP.NET 3.5 SP1 we'll be shipping a feature called 'ASP.NET AJAX Script Combining', as the name suggests this feature combines multiple HTTP requests (in this case for the ASP.NET AJAX scripts) into a single request, potentially greatly reducing the number of roundtrips to the server.

Where is this going?

Well, a feature I've been playing with (and which I'm considering for ASP.NET vNext) is an ASP.NET CSS Sprite Control. Zack Owens has already posted about a technique for doing this in ASP.NET, but I wanted to increase the usability of generating these sprites; think using an ASP.NET image control and them magically being combined and output as part of a Sprite...
For those who don't know, CSS Sprites are essentially a technique which involves combining multiple images into one and using CSS to specify which one to show when they download. With this technique you both reduce the number of server requests as well as 'pre-loading' images on the fly (when's the last time you had an image rollover which seemed to stutter as it loaded the next image?).
Anyway, that's the idea; below is a some ASP.NET markup I'm playing with...this would resuly in a single PNG image being generated, along with a CSS definition for the sprite and for each 'image' to be displayed in the page.
This is still very much a work in progress and there's a ton of challenges around persisting the generated image in a scalable way etc...But well, I've been quiet of late so I thought I'd let you know what I'm playing with these days...

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title></title>
<cs:SpriteManager runat="server" GroupName="DEFAULTGROUP" ImageFormat="png"></cs:SpriteManager>
</head>
<body>
<form id="form1" runat="server">
<cs:Sprite ID="Sprite" ReferenceId="Clock" runat="server" ImageUrl="~/icons/Clock.ico"/>
<cs:Sprite ID="Sprite1" ReferenceId="Contacts" runat="server" ImageUrl="~/icons/contacts 1.ico"/>
<cs:Sprite ID="Sprite2" ReferenceId="Alerts" runat="server" ImageUrl="~/icons/alerts.ico" />
<cs:Sprite ID="Sprite3" ReferenceId="Download" runat="server" ImageUrl="~/icons/download.ico"/>
<cs:Sprite ID="Sprite4" ReferenceId="Desktop" runat="server" ImageUrl="~/icons/desktop.ico" />
</form>
</body>
</html>

Yes, yes I know!

Scott Galloway — Thu, 03 Jul 2008 22:47:36 GMT

Blog, I have not abandoned you! I'm in a 'quiet' phase right now...be back soon (when work settles down a bit).