How to not persist in ViewState stuff that doesn't need to be persisted in ViewState?

From Microsoft's page Understanding ASP.NET View State:

in the instantiation stage of the page life cycle, the control hierarchy is created and those properties that are specified in the declarative syntax are assigned. Since these declarative properties are automatically reassigned on each postback when the control hierarchy is constructed, there's no need to store these property values in the view state.

What this means is that if your aspx file contains markup such as:

<asp:Label ID="Label1" runat="server" Font-Name="Verdana" Text="Hello, World!"></asp:Label>

The two things that will not have to be persisted in the ViewState are:

Font-Name: Verdana
Text: Hello, World!

These two properties do not have to be persisted in the ViewState because they are set every time.

Another example of things that don't have to be persisted in the ViewState are items declared in the aspx markup file:

<asp:DropDownList ID="DropDownList1" runat="server">
   <asp:ListItem>One</asp:ListItem>
   <asp:ListItem>Two</asp:ListItem>
   <asp:ListItem>Three</asp:ListItem>
</asp:DropDownList>

The DropDownList items:

One
Two
Three

Do not have to be persisted in the ViewState because they are declared every time.

That's what i want to do. i want things that do not have to be persisted in the ViewState to not be persisted in the ViewState. Conversely, things that do have to be persisted in the ViewState i want them persisted in the ViewState.

From MSDN again:

When the control hierarchy is built in the instantiation stage, the Label's Text property will be set to "Hello, World!" and its Font property will have its Name property set to Verdana. Since these properties will be set each and every page visit during the instantiation stage, there's no need to persist this information in the view state.

An Example

Except rather than declaring the attributes in the markup, imagine they are declared programatically:

Label1.Font.Name = "Verdana";
Label1.Text = "Hello, World!";

DropDownList1.Items.Add("One");
DropDownList1.Items.Add("Two");
DropDownList1.Items.Add("Three");

Now in order to signal to the magic of ASP.net that the properties are always there, and do not need to be persisted in the ViewState, i will make this changes during page Initialization:

protected void Page_Init(object sender, EventArgs e)
{
   //Set properties *before* PageLoad; before the viewstate is read
   //That way the properties will not have to be added to the viewstate
   Label1.Font.Name = "Verdana";
   Label1.Text = "Hello, World!";

   DropDownList1.Items.Add("One");
   DropDownList1.Items.Add("Two");
   DropDownList1.Items.Add("Three");
}

Except that doesn't work. Even though i'm setting the control's properties early enough in the page cycle, and even though i'm setting the properties every time, ASP.NET still thinks they need to be persisted in the ViewState.

Obviously i need my code to run further back in time. From a time when ASP.NET thought it was still reading the markup.

How can i not persist in ViewState stuff that doesn't need to be persisted in ViewState?

Postscript

Why do this? Just put it in the markup

Can't; not when the drop-down items come from a database
Set the control's ViewState property to false

Can't; not when that turns off things that do need to be persisted in the ViewState

Solution

You've essentially answered your own question.

You can't on a per-property basis decide what stays in and doesn't stay in ViewState, for stock asp.net controls.

If you roll your own custom controls, you could have more granularity and control exactly which properties are stored and which aren't, through a custom property list, etc., however you'd have to recreate the wheel.

You may be able to inherit from the built in controls (I doubt any are sealed) and override viewstate and/or control state handlers. Sounds like a huge undertaking for little gain to be honest.

I get why you're asking - why not be more efficient than the current model. The problem is ASP.NET has never been about efficiency and is certainly not light-weight. It's more about quick and rapid development at the cost of performance and simplicity - just look at the ajax UpdatePanel design pattern as an example. It's a completely bloated ajax implementation for the sake of easy development.