Ethan
Tue Sep 16 11:34:39 CDT 2003
Very interesting. I didn't know it was related to accessing private
members.
At one point I thought of doing what you described-- have #2 ask #1 to
create the controls. I was thinking #1 could have code to convert an XML
spec into the controls. But I felt like I was reinventing the wheel, and I
didn't wan't to restrict the developer for #2 from the normal way of doing
user controls for something that would only have a small impact. I think
I'll just live with it. The .net framework helps keep the dlls pretty small
anyway.
Thanks Joe
"Joe White" <ip255@hotmail.com> wrote in message
news:3F666BF3.2090305@hotmail.com...
> I had some ideas on this, but didn't want to post until I'd tried a few
> of them (since I've never actually written anything using AppDomains
> before tonight). But I got a test app working this evening, and have
> some info for you.
>
> Basically, what you want to do (create a Control in one AppDomain and
> parent it to a control in another AppDomain) cannot be done directly.
> As soon as you try to add the foreign Control to a parent's Controls
> collection, you get a System.Runtime.Remoting.RemotingException:
> "Remoting cannot find field parent on type System.Windows.Forms.Control".
>
> I googled the Web and newsgroups for this error message. Among the
> handful of search hits was the explanation: "Unfortunately, Remoting
> cannot access private members through context bounderies, which is
> exactly what 'parent' is in this case(inside the Control class)."
> (
http://weblogs.asp.net/rosherove/posts/25319.aspx)
>
> I do have some ideas about how you could accomplish the same thing, but
> they wouldn't be too pretty. Basically, AppDomain2 needs to decide
> which controls to create, but it can't create them directly; instead it
> would need to call a factory object provided by AppDomain1 (with methods
> like CreateButton(), CreateListBox(), CreateUserControl(), etc.), so the
> Controls are actually created in the context of AppDomain1. Then, once
> AppDomain2 has requested creation of these controls, it can hook their
> events and return them to AppDomain1 for display.
>
> So I think it would be doable. A *really* big pain, but doable. How
> badly did you want this feature? (rueful grin)
>
>
> Ethan Post wrote:
> > Is it possible to implement a control that can be loaded into, and later
> > unloaded from current the process when it is no longer needed? I've
been
> > able to do this with other classes by subclassing MarshalByRefObject,
> > putting it in it's own assembly, and loading it into its own AppDomain
> > (which can later be unloaded). But as far as I can tell, this isn't as
easy
> > with a System.Windows.Form.Control descendant (even though they descend
from
> > MarshalByRefObject).
> >
> > The first problem I've run into is that as soon as I try to use the
control
> > (which was created in a different AppDomain), I get a
SerializationException
> > because the ControlCollection class (of the parent) is not a descendant
of
> > MarshalByRefObject (or serializable). Apparantly, controls need to
> > reference that collection in some way, when they are added to the parent
> > (which is in the original AppDomain in this situation).
> >
> > So my question is, is there some way to implement an unloadable control,
> > where all it's code is in an assembly that can be
loaded-into/unloaded-from
> > the process? There may be workarounds, like just making the code behind
the
> > control's events unloadable, and not the control itself. But for my
> > purposes, the control wouldn't be generic enough for something like
that. A
> > good analagy would be a user control for implementing a propery sheet.
> >
> > Any ideas?
> >
> > -Ethan
> >
> >
>