I was however informed in the comments that by overriding the NamingContainer property the control loses the ability to read its value from the PostBack data.

Since the controls I developed were not meant to to be used in a postback scenario, this wasn’t a big problem for me.

Fast-forward a couple of years and here I am, wondering why post back does not work in one of my projects

Anyway, I looked at the link provided by Alex, where Rick Strahl talks about overriding the ClientId and the UniqueId properties instead of NamingContainer.

In a standard web control, the two properties ClientID and UniqueID are mapped, respectively, to the id and name properties of the HTML control generated.

Since most (all? ) JS frameworks use the id property to access the varius HTML elements and the PostBack mechanism uses the name property, I think the “best of both worlds” solution is to only override the ClientId:

<p><span class="kwrd">public</span> <span class="kwrd">class</span> NiceTextBox : System.Web.UI.WebControls.TextBox
{
    <span class="kwrd">public</span> <span class="kwrd">bool</span> UseNamingContainer { get; set; }
</p><p>    <br />    <span class="kwrd">public</span> <span class="kwrd">override</span> <span class="kwrd">string</span> ClientID
    {
        get
        {
            <span class="kwrd">if</span> (<span class="kwrd">this</span>.UseNamingContainer)
                <span class="kwrd">return</span> <span class="kwrd">base</span>.ClientID;
            <span class="kwrd">else</span>
                <span class="kwrd">return</span> <span class="kwrd">this</span>.ID;
        }
    }
}
</p>

Now our NiceTextBox works even during post-back scenarios

But now, you want to back them up together with the code of your program, using subversion or CVS. Afterall, they are part of the application logic.

Better yet, you would like to automate the extraction procedure so that you only need to launch a batch file and your backup is done.

Gljakal’s Sql Exporter does just that: it extracts tables, views, stored procedures and triggers from your database and saves them as individual text files.

Used together with a source control software, you can have a precise idea of what changed between the various releases, just like you do with your applications’ source code.

You can do that with the interface version (shown in the picture) as well as with the command line version, that you can automate to run whenever you want.

Plus, it’s a free download!

<asp:TextBox ID=”TextBox1” runat=”server” />

<input name=”ctl00$ContentPlaceHolder1$TextBox1” type=”text”
    id=”ctl00_ContentPlaceHolder1_TextBox1” />

The client-side hack

Luke Foust, in his article Using JQuery to Make Asp.Net Play Nice with Asp.Net, explains a couple of client-side methods to let your javascripts select the right element in this situation. I recommend you to read it, because it contains some nice ideas and it also shows off some of the power of JQuery.
While these methods will work for most projects, they still present a couple of issues:

• Generally quite hard to mantain, especially the first hack
• Code bloat. While bandwidth is costantly becoming less of an issue, the generated page will have elements with horribly long declarations
• It breaks existing scripts. You’ll have to re-check and re-code most of the scripts that should already work
• Extra workload on the client. Todays PCs are fast, so this is less of an issue, however it is something you should consider if you have a lot of asp.net controls in your page.

The Solution

Let’s face it: the problem is really on the server, not on the client. Asp.net should not generate those horribly long IDs in the first place, unless we want to. So the best solution is a server-side hack.
How does asp.net know whether or not it should generate a unique id for our controls?
Every WebControl in asp.net exposes a property called (I’m sure you guessed it) NamingContainer, which tells asp.net what’s the parent control for our textboxes, labels and so on. All we have to do in our code is create a new class that will inherit the control we want to "sanitize" and hide that property from asp.net. Better said in code than in words:

using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;

namespace wtd
{

    /// <summary>
    /// A TextBox control without ugly IDs
    /// </summary>
    public class TextBox : System.Web.UI.WebControls.TextBox
    {
        public override Control NamingContainer
        {
            get
            {
                return null; 
            }
        }
    }

}

<%@ Register TagPrefix="wtd" Assembly="app_code"
     Namespace="wtd" %>

<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>

<wtd:TextBox ID="TextBox1" runat="server"></wtd:TextBox>

<input name=”TextBox1” type=”text” id=”TextBox1” />

Update

As pointed out by some of you in the comments, this method does not work in a traditional post-back scenario. See my new article for a possible solution to this problem.