Problem of Unloading Managed C++ DLL...
-
I am having problem to delete a Managed C++ DLL that was used in a pure C# DLL even in the following scenario. 1. Launch the application. This applicatio has its own default applicaiton domain. 2. Create a new Application Domain. 3. Load the Pure C# DLL in the new applicaiton domain. This C# DLL uses managed C++ DLL. 4. Create a Proxy object using CreateInstanceAndUnwrap for the wrapper object which is a wrapper for the class used from the pure C# DLL. This wrapper object is exported from a seperate DLL. DLL Configuration:- Wrapper for C# DLL, C# DLL, Managed C++ DLL. The wrapper C# is used so that the main C# will not be loaded into the default application domain when creating a Proxy object using the menthod CreateInstanceAndUnwrap. The application domain talks with only the wrapper DLL. If we do not have wrapper class, then the main C# DLL will also be loaded into the default application. The sideeffect of this is that, even when the new application is unloaded, we will not be able to delete the main C# DLL. Wrapper is just a call frowader to the C# DLL class. 5. Give the class name exported from C# DLL to the wrapper object and ask it to create an instance of the class. The wrapper class creates the the class and initializes its membet to it, so that it can forward call requests. 6. From the default application domain, call a method on the wrapper object. This call on the wrapper object calls the method on the C# class. This C# class uses a function exported from a managed C++ DLL. 7. After executing the methods, unload the new application domain. 8. Now try to delete C# DLL, Mananged C++ DLL. I was able to delete C# DLL, but not MC++ DLL. After further investigation I found that the Visual Studio "Output" window has the following two lines:- 'Application.exe': Loaded 'C:\DLL1\Debug\MCPP.dll', Symbols loaded.----> LOADING FIRST TIME 'Application.exe' (Managed): Loaded 'C:\DLL1\Debug\MCPP.dll', Symbols loaded. ----> LOADING SECOND TIME When the method on C# class is getting executed, the output log file contains the above two lines. The .NET framework is loading it twice. Once as Native C++ DLL, second time as Managed DLL. Does any one know how to delete the MC++ DLL.
-
I am having problem to delete a Managed C++ DLL that was used in a pure C# DLL even in the following scenario. 1. Launch the application. This applicatio has its own default applicaiton domain. 2. Create a new Application Domain. 3. Load the Pure C# DLL in the new applicaiton domain. This C# DLL uses managed C++ DLL. 4. Create a Proxy object using CreateInstanceAndUnwrap for the wrapper object which is a wrapper for the class used from the pure C# DLL. This wrapper object is exported from a seperate DLL. DLL Configuration:- Wrapper for C# DLL, C# DLL, Managed C++ DLL. The wrapper C# is used so that the main C# will not be loaded into the default application domain when creating a Proxy object using the menthod CreateInstanceAndUnwrap. The application domain talks with only the wrapper DLL. If we do not have wrapper class, then the main C# DLL will also be loaded into the default application. The sideeffect of this is that, even when the new application is unloaded, we will not be able to delete the main C# DLL. Wrapper is just a call frowader to the C# DLL class. 5. Give the class name exported from C# DLL to the wrapper object and ask it to create an instance of the class. The wrapper class creates the the class and initializes its membet to it, so that it can forward call requests. 6. From the default application domain, call a method on the wrapper object. This call on the wrapper object calls the method on the C# class. This C# class uses a function exported from a managed C++ DLL. 7. After executing the methods, unload the new application domain. 8. Now try to delete C# DLL, Mananged C++ DLL. I was able to delete C# DLL, but not MC++ DLL. After further investigation I found that the Visual Studio "Output" window has the following two lines:- 'Application.exe': Loaded 'C:\DLL1\Debug\MCPP.dll', Symbols loaded.----> LOADING FIRST TIME 'Application.exe' (Managed): Loaded 'C:\DLL1\Debug\MCPP.dll', Symbols loaded. ----> LOADING SECOND TIME When the method on C# class is getting executed, the output log file contains the above two lines. The .NET framework is loading it twice. Once as Native C++ DLL, second time as Managed DLL. Does any one know how to delete the MC++ DLL.
chandrap wrote:
3. Load the Pure C# DLL in the new applicaiton domain. This C# DLL uses managed C++ DLL.
Where is this done from? Shouldn't the wrapper be doing this in the new appdomain?
chandrap wrote:
I was able to delete C# DLL,
It seems to me you shouldn't be able to do that. I'm missing something. Isn't the C# DLL loaded in both appdomains (in steps 3 and 5)?
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
chandrap wrote:
3. Load the Pure C# DLL in the new applicaiton domain. This C# DLL uses managed C++ DLL.
Where is this done from? Shouldn't the wrapper be doing this in the new appdomain?
chandrap wrote:
I was able to delete C# DLL,
It seems to me you shouldn't be able to do that. I'm missing something. Isn't the C# DLL loaded in both appdomains (in steps 3 and 5)?
Mark Salsbery Microsoft MVP - Visual C++ :java:
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.
-
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.
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
-
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.
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:
-
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:
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.
-
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.
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:
-
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:
-
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.
: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:
-
: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:
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.
-
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.
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:
-
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.
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.
-
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.
Makes sense :) Good job tracking it down and thanks for the update. Cheers, Mark
Mark Salsbery Microsoft MVP - Visual C++ :java: