Watch Out When Setting the ID of a Master Page Dynamically

In my latest book Beginning ASP.NET 3.5 in C# and VB.NET I made the mistake to recommend setting the ID in Page_Load (on page 276), like this:

protected void Page_Load(object sender, EventArgs e)
{
  this.ID = "Master";
}    

While this code runs fine in simple scenario's where all you need to do is change the client ID, it will present major problems when you're in a more dynamic scenario, for example when editing data with a GridView or ListView control. When you set the ID in Page_Load and then try to delete an item in a ListView (as is discussed on page 451 and onwards) you may get the following error:

Could not find a row that matches the given keys in the original values stored 
in ViewState.  Ensure that the 'keys' dictionary contains unique key values 
that correspond to a row returned from the previous Select operation.

This error in the PlanetWrox project caused by the master's ID was reported by Gerard Torres in a post on the Wrox forum. He tried out the ID setting in his own PlanetWrox project with the aforementioned error as the result. At first this error may put you on the wrong track (it did to me), leading you to think there's a problem with the keys, like the DataKeyNames attribute on the ListView or with the primary keys in the database. However, it turns out that the keys are stored in ViewState correctly, but with a non matching name. On PostBack, when the key values need to be extracted from ViewState, there is a mismatch between the values stored in ViewState (prefixed with Master1) and the recreated control into which the data is loaded (which is still prefixed with ctl00 because the Master1 prefix has not been set yet).

So always make sure you set the ID in Page_Init, and not in Page_Load. Also, don't try to set the ID in Page_PreInit. Although the Page class has a PreInit event, the master page doesn't.

Finally, try to avoid relying on fixed control IDs altogether. It makes your application more fragile, as changing master pages or your control hierarchy can seriously screw up your client IDs. Instead, use the ClientID and the UniqueID properties that each control has. These controls give you the client side IDs of the controls at run-time, so they are always up-to-date.