I have derived a small example of the problem mentioned above.  It is setup
like this:

Assembly 'PluginHelper' has a class named 'Helper'.
Assembly 'PluginFramework' has a class named 'PluginBase' and a class named
'TextPlugin' that inherits 'PluginBase'.
Assembly 'PluginImpl' has a class named 'TextPlugin' that inherits
'PluginFramework.TextPlugin'

'PluginHelper.Helper' uses reflection to load the 'PluginFramework' assembly
and call a static method on the 'TextPlugin' class.
The static method on the 'TextPlugin' class calls a static method on
'PluginFramework.PluginBase' (its parent).
The static method on the 'PluginBase' class uses reflection to load the
'PluginImpl' assembly and create an instance of the 'PluginImpl.TextPlugin'
class.  It then casts the instance to 'PluginBase' and returns it to the
caller ('PluginFramework.TextPlugin').

The expected behavior is for the plugin base class to get an instance of the
text plugin implmentation class and cast that back to the plugin base class -
it is a grandparent, after all.

This works fine at run time!

To test at design time (where I *really* need it in my real project), I
created a simple windows app project and added a simple custom button that
inherits from Button.  In the custom button constructor it sets its own text
to a value returned from the static method on 'PluginHelper.Helper'.  This
works fine at run time, but trying to view a form containing this button in
the designer doesn't work.

The problem seems to be that at design time, the implementation class can't
be cast back to it's grandparent, while at run time it can.

Am I missing something?  The real project is severely crippled because of
this.  There is a lot of custom UI that make use of a plugin-style framework
like this.  I can't use the designer now!