Memory management while Loading assembly using reflection

Question

All,

I am creating a component that uses composite pattern. The core component uses an XMl Meta data to define the composites (parts). at run time, the core component would use reflection to load the part assembly into the memory and call methods (eg IPart.execute method).

Now my question is

1) will the (dynamic) memory that is occupied by the assembly that is loaded using reflection will be unloaded when i dispose the object or not.

2) if it does not unload and free the memory, is there is any way i can remove it from memory.

The reason of this question is, the component which i am building will be the core of my Business layer of an enterprise application which can be customized heavily.

Thanks Albert Arul Prakash

Answer 1

I've seen people load additional libraries via reflection (we could call these libraries "plugins") in another appdomain. For instance, see this article: http://adrianvintu.com/blogengine/post/Unloadable-plugins.aspx

This way you are protected from "evil" plugins as well as memory can be managed in such appdomain (when the appdomain unloads, the memory is freed up as well)

Answer 2

There are two things that can consume memory in a plugin/module. Grossly speaking, these are code (loading the assembly into your process space consumes memory), and objects (creating an instance of something consumes memory).

will the (dynamic) memory that is occupied by the assembly that is loaded using reflection will be unloaded when i dispose the object or not.

Calling Dispose on IDisposable doesn't do anything to the object as far as memory is concerned. It might free resources that the object uses (eg if you close a file, it will get rid of open file handles), but it won't free the object itself. IDisposable isn't a magic memory-freeing function - it is just a method on an interface that lets an object know that it should get rid of resources that it owns.

To free the object itself, you must get rid of all references to it (possibly set them to null, or let them fall off your program's stack), and the garbage collector must eventually run to reclaim that memory.

if it does not unload and free the memory, is there is any way i can remove it from memory.

If you are only concerned about resources like GUI and file handles, make sure you call Dispose . You should always do this :)

If you are concerned about object memory, just let the GC do its work. Don't pester it to, either. Let it run on its own.

If you are concerned about code memory, you must unload the AppDomain that the code is in. If this is your default AppDomain then you can't unload it without quitting your program. Instead, you should load that plugin in a sub AppDomain that you created at runtime. You can then get the code out of your process space by unloading the sub AppDomain .

See naivists' answer for information on how to use a sub AppDomain .