I found a really weird "feature" that's causing a lot of issues with my controls (especially because they try to do callbacks but fails because of this).

Try and create this custom control:

public class SimpleCustomControl : System.Web.UI.WebControls.CompositeControl
{
	protected override void RenderContents(HtmlTextWriter writer)
    {
		writer.Write(this.UniqueID);
    }

	protected override void OnUnload(EventArgs e)
	{
		// Uncomment one of following two lines and the ID of the control ID will change
		// IF the control is in a UserControl that's placed a webpart.
		// string clientid = this.ClientID;
		string uniqueid = this.UniqueID; 
		base.OnUnload(e);
	}
}

Take this control and add it to a usercontrol, and use this usercontrol as a webpart. Preferably also add some other controls to the usercontrol. Note the UniqueID and ClientID of the control that gets rendered out, as well as the ID's of the other controls in the usercontrol. Now remove the line in OnUnLoad that accesses UniqueID, and recheck the IDs.

EVERYTHING just changed. Basically when you access the UniqueID or ClientID during OnUnload, it removes the prefix "WebPartManager1$" (or whatever you named your webpartmanager) from all the IDs.

I have NO clue why this happens, but it's causing a sh*t load of problems for my controls. The funny thing is that if you put this control inside a CustomControl instead of a UserControl the problem goes away.

So you probably think that why don't I just cache the UniqueID during PreRender. Sorry but the problem is that OnUnLoad is called first by the WebPartManager, and then later it goes through it's full lifecycle, but by then it's already too late. I guess there's one important question here: Why the heck does WebPartManager call OnUnload on all webpart controls completely out of their lifecycle? And how would I tell that this is what is happening?

Does anyone have an idea why this happens? It very much looks like a bug in the CLR though.

I found the actual reason for OnUnLoad to fire is that the WebPartManager moves all the controls in the webpartzones over to its own childcollection (what a hack Microsoft!). This causes the childcontrols of the webpartzone to get cleared, which again fires OnUnLoad. So no wonder the ID's change since the object tree changes. The problem is that the UniqueID and ClientID are cached in the control, so accessing them after the move will not update them.

I still haven't found a good workaround though, apart from trying to control my entire API from not accessing UniqueID (the problem here is that this is used a lot for state management throughout the API).

I opened up a bug report for this:

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=317651