Unloading native dll from a C# appdomain

Jul 8, 2009 at 9:29 AM


I wanted to know what is the best practice to unload native c++ dll from a new C# appdomain.

I see that when I am loading a managed dll that uses native dll to a new appdomain, when I unload the appdomain only the managed dll is unloaded and the native dll is still in memory. I have managed to unload the native dll by calling to FreeLibrary on the dll handle.

When I try creating a C++\CLI dll and load it into a new appdomain I encounter the same problem but worser since I can see that the native/managed dll is now loaded to the new appdomain and the default appdomain as well and when I unload the new appdomain, the c++\cli stays in memory for both the managed and the native parts (I attached with a debugger as managed / native and saw that the dll appearstwice one for native and one for managed)


Jul 10, 2009 at 5:45 PM

If the dll is loaded into the process because managed code interop the code in the dll, clr does not provide a method to unload it. It could be very dangerous for clr to do this because there might be other code (even native code) which depends on that dll. If you do assure that dll is not used any more, calling a windows API like FreeLibrary may be easiest way to unload the dll.

Ijw is a combination of managed and native binaries. Therefore, for each ijw  Visual Studio debugger shows the managed and native items. You can tell whether they are same by checking the address of them.

You also mentioned that ijw dll still in the process after appdomain is unloaded. My experiment didn’t show me this observation. Can you describe your scenario like how to load the ijw dll and invoke the method inside it? Note that if the default appdomain keeps a reference of the object whose type is defined in ijw the ijw need stay in the default domain.

Jul 12, 2009 at 8:15 AM

Hi Yongtai,

Thanks for your fast answer.

I am calling a native dll using the P/Invoke signature and I am the only one who is using the native dll so according to your answer it sounds that FreeLibrary is an accepted way to unload the dll. It was working for me fine but I wasn't sure it is the right way to unload it.

Anyway the solution above was done since I failed to do it using ijw. I will describe what I have done and tell me if something is wrong:

1. I have created a managed dll which defines the interface that was implemented in ijw dll.
2. I have created the ijw dll which implement the interface.
3. In a wcf service I added a refference to the managed dll that contains the interface.
4. Inside one of the wcf service methods I have created new appdoamin and created the managed type from the ijw dll by reference in the wcf service process (w3wp.exe). The reference pointer is from type of the interface so no need for the default appdomain to load the ijw dll.
5. When I looked at modules I can see the ijw dll appears in both the default appdomain and the new appdomain I have created.
6. after unloading the new appdomain the dll still appears in the w3wp process at the default appdomain.

Do you have an idea what cause this behaviour? is it the fact that it runs under IIS causing the CLR to behave differently then in a console process?