<p>I'd like to structure a Form with a TabControl but I'd like to avoid having every control on each TabPage end up being a member of the Form I'm adding the TabControl to. So far I've identified these options, please comment or suggest alternatives:</p>

<p>1) Write a UserControl for each TabPage</p>

<p>2) Leave only the Control on the main Form but turn the control variable public and cut-and-past all actual code into separate classes</p>

<p>3) Forgo the Form designer and do everything at runtime</p>

<p>4) Derive from Tabpage (not sure if this works and what the design-time implications are)</p>

<p>Thanks all,</p>

<p>Andrew</p>

In any complex WinForms application, you will probably run into the problem of too many controls on a form. Not that you'll run into a hard limit, but rather you'll run into a pain point -- such as you're describing.
In most scenarios, for me, your option #1 -- a user control for each tab page -- is the least painful approach. It allows you to encapsulate logical breakdowns of the controls in their own way, scoping them appropriately.
The downside to this is that you will likely end up exposing either a
ton
of properties on your user control. The way out of that problem is fairly simple, though: Use a custom class to represent the data which is "bound" to said control, and then expose a single property for the bound instance of the class.
You'll have better architecture overall, you'll be more maintainable, and as an added bonus, you won't go nuts trying to get the form to work. :)
EDIT:
I should note that you may also end up needing to expose some custom events from the user controls which represent your tab pages. Essentially, if there's a control on the tab whose event is needed by the parent form, you'll have to create an event and raise it so that the parent form knows about it. This isn't terribly difficult, but can add significant LOCs to the user controls.