tags:

views:

461

answers:

2

We have a .Net application from which a C++ COM component is being instantiated. We load the COM component from a child form window. There is a common resource that is being edited by the .Net application, which inturn is being used by the COM dll to start up.

When the following sequence of steps are performed:
1. Instantiate COM component in the new child window The COM component is instantiated, and is used by the child form , and after being used, it is being set to NULL , hoping that the COM component would be unloaded.
2. Keep child window open, and then edit the resource
3. Now, go and "refresh" the form, to create a new COM instance, to see the refelection of the changed resource - but the resource is not refreshed.

We also used Marshal.ReleaseComObject method, but to no success. Please advice.

A: 

COM object and DLL are two different things, even if one resides in another. Certain hacks are possible, but much better solution is to rewrite this part in a more sensible way which doesn't rely on DLL unloading.

ima
+3  A: 

Once a DLL is loaded into a .Net AppDomain, it is not possble to force a DLL to be unloaded. It's an unfortunate limitation of the CLR. If you absolutely need the DLL to unload you can do the following.

  1. Create a new AppDomain
  2. Load the DLL into the new DLL
  3. Do the work in the new AppDomain
  4. Unload the new AppDomain

If a DLL is only loaded in one AppDomain, unloading the AppDomain will unload the DLL as well. So this will get the DLL unloaded. However it is a pretty heavyweight answer.

JaredPar