Dynamic controls and viewstate (mis)management

[Scott Roberts]

I always thought that the viewstate "keys" included the control ID. As long
as the control IDs were unique, there shouldn't be any conflicts. Well, it
appears that that may not be the case with dynamic controls. Our application
was having a problem very similar to the one described here:

http://weblogs.asp.net/alessandro/archive/2008/01/04/failed-to-load-viewstate-typical-problem-with-an-obvious-solution.aspx

Unfortunately, the "fix" isn't quite so simple. Our problem exists with
dynamically loaded user controls, and simply turning off the viewstate is
not an option. Basically, what we are doing is dynamically loading different
user controls into an update panel depending on the user's selection in an
adjacent treeview. So if the user is viewing uc1 then clicks the tree node
for uc2, during postback we simply create and display uc2. The problem,
then, is that the viewstate from uc1 *may* stomp on the newly added uc2. The
"fix" is to re-create uc1 during postback (even though we have no use for
it), add it to the control tree, remove it from the control tree, then
create uc2.

I guess I'm just wondering if there is a way to avoid having to re-create a
user control that we are not going to display just to clean up the
viewstate?

Here is a small code snippet that demonstrates the problem:

aspx snippet:

<form id="form1" runat="server">
<div>
<asp:Button ID="PostbackBut ton" runat="server" Text="Post Back"
/></div>
</form>

aspx.cs snippet:

protected void Page_Load(objec t sender, EventArgs e)
{
if (!IsPostBack)
{
Button b = new Button();
b.ID = "button1";
Page.Form.Contr ols.Add(b);

// Modify text *after* adding to Page.Form.Contr ols
// so that the Text property ends up in viewstate.
b.Text = "Button1";
}
else
{
// Uncomment this block to make it work.
//Button b = new Button();
//Page.Form.Contr ols.Add(b);
//Page.Form.Contr ols.Remove(b);

Label l = new Label();
l.ID = "label1";

// Set text *before* adding to Page.Form.Contr ols
// so that the value gets overwritten by the
// viewstate value (if any).
l.Text = "label1";

Page.Form.Contr ols.Add(l);
}
}

When you click the PostbackButton you will notice that the Label will
display "Button1". It's getting the viewstate property from the Button.Text
created on the previous page_load (!IsPostBack). If you uncomment the
specified code block, the Button created during IsPostBack will "eat" the
viewstate property and the label will behave "properly".

My question is: Why isn't the control.id utilized as part of the viewstate
key for dynamic controls?