For this customer I'm working for, I built a generic attachment control. This control takes 2 types, one implementing an ICanHaveAttachment interface and the other implementing an IAttachment interface. The ICanHaveAttachment implementations are, in my case, partial EF models which all can have attachments.
This control is in a library and has no ascx file. All controls - being a fileupload, label, button and repeater - in this user control are created at runtime. The control itself, as it is a generic control and the designer hasn't got the ability to handle that, is put in a panel on the pages, also at runtime.
Now one instance of this control was in an updatepanel. Being a good student, I added

to my control, to make sure it does a complete postback instead of an async postback, which wouldn't work with a fileupload.
However, when I tried this particular piece of code, it didn't seem to be working as that upload button would still perform an async postback. After digging around in the javascript that handles postbacks, I found this particular line of code:

Apparently, registering controls as postback controls only works with controls that have an ID, which is fine when you create them in a designer, because than it's a required attribute. If you create controls at runtime, however, ID isn't mandatory and is easily forgotten...
Adding an ID at runtime made all my sorrows go away and will do so for yours :)