AppDomain.Unload an unmanaged DLLs
-
Hi, I am using an unmanaged DLL in my code and am running into problems because it is difficult to get the structures in the DLL to reset their state properly. If I put the DLL in an AppDomain and unload the AppDomain, will that release the unmanaged DLL? That way, I could just start another AppDomain with the same DLL and have the state reset that way. This would be great, but I am not yet sure if it is possible. Any help is appreciated. Thanks, klk
madness ? this.isSparta = true : this.isSparta = false;
-
Hi, I am using an unmanaged DLL in my code and am running into problems because it is difficult to get the structures in the DLL to reset their state properly. If I put the DLL in an AppDomain and unload the AppDomain, will that release the unmanaged DLL? That way, I could just start another AppDomain with the same DLL and have the state reset that way. This would be great, but I am not yet sure if it is possible. Any help is appreciated. Thanks, klk
madness ? this.isSparta = true : this.isSparta = false;
That sounds like a serious hack solution. I do not recommend doing that. You have not provided enough information about the situation for us to determine what else might be appropriate as a solution.
K.L.K wrote:
it is difficult to get the structures in the DLL to reset their state properly.
You need to explain that in detail otherwise we cannot understand the problem.
led mike
-
That sounds like a serious hack solution. I do not recommend doing that. You have not provided enough information about the situation for us to determine what else might be appropriate as a solution.
K.L.K wrote:
it is difficult to get the structures in the DLL to reset their state properly.
You need to explain that in detail otherwise we cannot understand the problem.
led mike
Hi led mike, Basically, there is a possibility that the dll can be given wrong input, and as a result, can get into a state that is tough to recover from. The dll wasn't designed for this kind of input, but it is a small probability and I don't want the user's application to crash as a result. Thus, if I could simply blow away the AppDomain and bring it up again without the user ever knowing, that would be phenomenal. Is this any clearer? Thanks, klk
madness ? this.isSparta = true : this.isSparta = false;
-
Hi led mike, Basically, there is a possibility that the dll can be given wrong input, and as a result, can get into a state that is tough to recover from. The dll wasn't designed for this kind of input, but it is a small probability and I don't want the user's application to crash as a result. Thus, if I could simply blow away the AppDomain and bring it up again without the user ever knowing, that would be phenomenal. Is this any clearer? Thanks, klk
madness ? this.isSparta = true : this.isSparta = false;
Can you load a native DLL into an AppDomain? I don't believe so. Do you have the DLL code? It would work much better if the DLL is (or is a part of) a managed assembly. If you have the code for the DLL, I would think proper error handling in the DLL is a much better solution. Otherwise, making the DLL a managed assembly will work fine, but you may want to consider the implications - performance, marshaling across the appdomain boundary, etc... Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Hi led mike, Basically, there is a possibility that the dll can be given wrong input, and as a result, can get into a state that is tough to recover from. The dll wasn't designed for this kind of input, but it is a small probability and I don't want the user's application to crash as a result. Thus, if I could simply blow away the AppDomain and bring it up again without the user ever knowing, that would be phenomenal. Is this any clearer? Thanks, klk
madness ? this.isSparta = true : this.isSparta = false;
-
Can you load a native DLL into an AppDomain? I don't believe so. Do you have the DLL code? It would work much better if the DLL is (or is a part of) a managed assembly. If you have the code for the DLL, I would think proper error handling in the DLL is a much better solution. Otherwise, making the DLL a managed assembly will work fine, but you may want to consider the implications - performance, marshaling across the appdomain boundary, etc... Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
Mark Salsbery wrote:
If you have the code for the DLL, I would think proper error handling in the DLL is a much better solution.
Yes. And if you don't have, and since it sounds like it's a pile of garbage, the next thing to consider is replacing it with your own code.
led mike