Problem of Unloading Managed C++ DLL...

[chandrap]

Yes you are correct, the Step3 is done in in the new application domain. Not in the default domain. Step5 uses the Step3 loaded assembly reference in the new appDOmain, to create the C# object. Since the C# DLL is only loaded in the new application domain, I was able to delete it.

[chandrap]

Hi After further investigation I found out that the default application domain is also loading the MC++ DLL even though I do not use it anywhere in the default application domain. The only place I use MC++ DLL is in the C#. The C# DLL gets unloaded when I unload the new application domain since it was loaded only in the new application domain. Why is the MC++ DLL getting loaded both in default and new application domain. Thanks Chandra

[Mark Salsbery]

Thanks :) Why do you do step 3, and how do you do it? It seems to me, the wrapper should be doing step 3, but you don't have a wrapper until step 5. What I'm getting at here, is an early binding to the C++ DLL, possibly caused by step 3, where the C++ DLL is getting inadvertently loaded in both domains... Mark

Mark Salsbery Microsoft MVP - Visual C++ :java:

[chandrap]

Thank you for your reply. I create Assembly Manager class inside the new application domain appDomain->CreateInstanceAndUnwrap("Wrapper.dll", "AssemblyMgr") Then ask the wrapper DLL to load. After this step we create the class in step 5 using the following code. Type testClassType = assembly.GetType(className); CSharpClass = (CSharpClass)Activator. CreateInstance(testClassType); Step3 is done to have the assembly loaded once, step 5 is used to create different classes from the same assembly. We do this because we do not know the DLL name at the compile time.

[Mark Salsbery]

Huh? :) I thought the wrapper was in a separate DLL? You need the C# DLL to be able to load the wrapper DLL which needs the C# DLL? It still seems to me the wrapper should be doing the loading of the C# DLL, at which time it can obtain the required class name. Mark

Mark Salsbery Microsoft MVP - Visual C++ :java:

[chandrap]

We use Managed C++ DLL to load the wrapper DLL which is C# DLL. This managed C++ DLL supplies the DLL name, class name to the wrapper DLL. The wrapper DLL loads the C# DLL. Creates the C# Class. The C# DLL uses another managed C++ DLL internally.

[Mark Salsbery]

:omg: How many wrapper classes are there? Which C++ DLL are you unable to delete, and which DLLs reference it and how? The original appdomain shouldn't need anything besides the wrapper DLL. Is the wrapper class derived from MarshalByRefObject?

Mark Salsbery Microsoft MVP - Visual C++ :java:

[chandrap]

I am not able to delete the Managed C++ DLL referenced inside the C# DLL. I checked the loaded assembly list using GetAssemblies. Then I found out the the Managed C++ DLL used in C# DLL is also loaded in the default application domain even though I do not use it anywhere except the C# DLL.

[Mark Salsbery]

We're going in circles now... I still question your step 3: 3. Load the Pure C# DLL in the new applicaiton domain. This C# DLL uses managed C++ DLL. Seems to me that's the place it gets loaded into the "default" app domain. Can you look at the loaded assembly list before and after step 3 to confirm?

Mark Salsbery Microsoft MVP - Visual C++ :java:

[chandrap]

Thank you for your replies. I found the solution to my problem. The problem is because the Managed C++ DLL that has been used in C# DLL refers to native C++ DLLs that have already been loaded in the main application i.e. default application domain. So when the managed C++ DLL is getting loaded via C# DLL, the framework instead of loading the native C++ DLL in the new applicaiton domain, uses the DLLs from the default application domain. This is causing the managed C++ DLL also to be loaded into the default application domain. Because of this reason I was not able to delete the managed C++ DLL.

[Mark Salsbery]

Makes sense :) Good job tracking it down and thanks for the update. Cheers, Mark

Mark Salsbery Microsoft MVP - Visual C++ :java: