Unloadable Control

  • Thread starter Thread starter Ethan Post
  • Start date Start date
E

Ethan Post

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
 
Ethan said:
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?
Click to expand...

What exactly do you wish to achieve by unloading the code
of the control? Do you use so many different controls that
the code itself causes a resource problem?

Or may your problem not simply be solved by removing
and/or disposing the used *instances* of the controls?
 
There's actually a lot of code behind these controls (more like applets),
and they may only be used for short periods of time, while the exe would be
open much longer. Disposing of the instances is already done.

I have several alternative ways of doing what I want to do, or I can even
just live with it and let unused dlls remain loaded. But if there is a way
to do it, I'd like to do that. I have a feeling it can't be done.
 
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)
 
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
 
Back
Top