The good old Assembly.Unload() that doesn't exist

  • Thread starter Thread starter Sam Martin
  • Start date Start date
S

Sam Martin

Morning all,

Right, I've read untold articles now, listening to people bitch about there
being no Unload method for Assembly.
Plenty of people do counter that this is possible by loading the Assemblies
into a seperate AppDomain and closing it when finish, which would suit me
fine.

However, I have been able to find an example.

What i'm trying to do, is from my application, load an assembly(s) itterate
through certain types and then "unload" the assembly(s) thenopen another
assembly(s) and do the same. The type information etc. must be available
from my main application.

How do i do this? surely i cannot get to this information from another
AppDomain?

Any pointers welcome,

TIA
Sam
 
ok, so i think i've answered this one myself too.

what i need to do is create an assembly that does the work i need to to on
the types and attributes of the additional assemblies i need it to.

Before i wanted to load an assembly, look at the types and their attributes
(using reflection), do "stuff" then unload the assembly.

Now i need to create a new assembly that does the "stuff" - i'll call this
the StuffDoer - on the extra assemblies that's loaded with them in a their
own app domain.

The shell application (in it's own app domain) becomes like the "stuff"
manager - StuffManager - that instead of just loading a single assembly,
browing types and attribs via reflection and doing "stuff". Actually
creates a new AppDomain, loads the StuffDoer assembly along with the extra
assembly(s) that are to browsed before "stuff" can be done.

so before, my application loaded an assembly, looked at type and attrib info
via reflection and did stuff with it... but couldn't unload the assmebly.

now, my main app, StuffManager, creates an AppDomain, load the StuffDoer and
additional assmeblies. StuffManager then executes code in the StuffDoer the
does the stuff, then StuffManager closes the new AppDomain and is ready for
a new assembly(s).

Executing the code in the other AppDomain (i.e. executing the StuffDoer)
I haven't done this yet, but found a good article,
http://blogs.msdn.com/suzcook/archive/2003/06/12/57169.aspx
Tells you how to do it there.


HTH anyone facing similar prob

sam
 
Just a caution on using other AppDomains. I believe all method calls
between the domains are serialized. This can give a big performance hit.
We experimented with this because we need an application environment
that runs 24-7-365. We need a way to load and unload plug in code type
objects on the fly as a way for enhancement and bug fixing. We can't
shut it down and restart it. We could find no way to do this with
Microsoft's CLR that had high performance :( We discussed this with
Microsoft and they agreed that they had no solution and say maybe
sometime in the future. Seems a strange oversite since they had Java as
a model. You can do this with custom class loaders in Java.

Leon Lambert
 
Back
Top