Taken out of context I know this may seem like a strange thing to do, but
just take this as an academic question if necessary...

Calling methods on a persisted control that has been added to a page that
has been rendered and unloaded generates these exceptions -

A first chance exception of type 'System.Net.Sockets.SocketException'
occurred in System.dll
A first chance exception of type 'System.Threading.ThreadAbortException'
occurred in mscorlib.dll
A first chance exception of type 'System.Threading.ThreadAbortException'
occurred in System.Web.dll

This happens even if I take the control out of the original page, and
regardless whether I persist it as a static or a session variable.

Now I really wouldn't care about these silent errors, provided they didn't
affect anything, but this is not the case; web projects with persisted
controls tend to hang on startup - the beginning page's render method is
fired, but the browser load continues indefinitely, and pausing execution
just shows dissassembly.

Why don't I just handle .aspx myself... well I don't have access to the
methods that properly load pages. I would have to use my own control
classes, not based on any of the existing object model already provided.
Certainly doable considering I do not need view state, but this would
require additional work that I have to justify. I will be making my own
control base classes later, but the render output will not be HTML.

So... the question is, is there anyone with suffcient knowledge of the
internal workings of the .aspx handler to tell me if it is possible to
persist already rendered controls without a problem?

Paul