unload assembly - AppDomain.Unload does not work as expected

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi

On reading the several posts I found that the only way to unload an assembly is placing it in seperate AppDomain and unload this AppDomain

My scenario
I have an assembly wrapping a third party legacy DLL. This DLL is very picky about re-initialisation. The official advise from the vendor is "Restart your app". Since I can't afford this (server app), I'm looking for a complete unload and thus to "trick" legacy DLL and fake a fresh start

BUT: Although AppDomain.Unload works (no exception), neither the .NET wrapper assembly nor the legacy DLL are really freed and kicked out of memory
I have the following indications
- the files are still locked (not my concern here
- "static" variables in the .NET wrapper assembly still hold their "old" values from the last star
- the legacy DLL still holds some internal state (unknown to me), to I can't "fake" a fresh star

What am I doing wrong ? Is there any way to completely kick this legacy DLL out of memory

Thanx in advanc

Dier
 
I haven't actually tried to do what you are doing but there's some general
observations I can make.

The problem with win32 DLLs is that the rules they follow are different from
..net rules. A legacy win32 DLL does not know anything about .net, managed
environments, etc. A Win32 dll gets loaded into the process space of the
application and stays there until it is explicitly unloaded or the process
terminates. Simply unloading an AppDomain wont do this for you.

You could try writing a managed C++ wrapper or use P/Invoke to explicitly
load and unload the DLL for you using the Win32 LoadLibrary/FreeLibrary APIs
before and after you use the 3rd party assembly. But if you call into a 3rd
party assembly that also loads the DLL it's hard to predict how things will
actually work in practice. I'd still load it into a separate appdomain but
then try to free the DLL after you unload the appdomain.

Convincing the authors to rewrite the assembly/DLL may be worth a try.


Dierk Droth said:
Hi,

On reading the several posts I found that the only way to unload an
Click to expand...
assembly is placing it in seperate AppDomain and unload this AppDomain.
My scenario:
I have an assembly wrapping a third party legacy DLL. This DLL is very
Click to expand...
picky about re-initialisation. The official advise from the vendor is
"Restart your app". Since I can't afford this (server app), I'm looking for
a complete unload and thus to "trick" legacy DLL and fake a fresh start.
BUT: Although AppDomain.Unload works (no exception), neither the .NET
Click to expand...
wrapper assembly nor the legacy DLL are really freed and kicked out of
memory.
 
Hi Dave

Thanx for your reply

I actually use P/Invoke implitely via the DllImport attributes. But the problem really is freeing the legacy DLL like calling "FreeLibrary"

Problem: How can I obtain the DLL handle to call FreeLibrary ? Or is there any other way to "free" the library

Regard

Dier
 
Back
Top