Reflection and file deletion
-
hello, to get information from the dll ie. the methods,types, parameters i use Reflection. at certain times i have to delete this dll which is usually not a problem. the problem is once i've reloaded a dll and performed some reflection on it, that when i go to delete the dll using FileInfo.Delete() i get an Access is Denied exception. so its as if the dll is still being used or a thread that's still alive or.... this one's got me stumped. maybe there's a better way of reflecting the information from the dll or something. here's the code starting with the Reflection: pretty straight forward. so i get the dll pass it into an Assembly and there you go. for what i need to do i think its about the easiest least overhead way. string tempPath = Path.GetTempPath();//Gets the path to the MS tempdir string strMSTempPath = tempPath.Replace(@"\", @"\\"); string strTempName = strNameSpace + ".dll"; Assembly ass = Assembly.LoadFrom(strMSTempPath + strTempName); string strObject = strNameSpace + "." + strServiceName; Type typeDynProxy = ass.GetType(strObject); MethodInfo[] methodArray = typeDynProxy.GetMethods(BindingFlags.Public|BindingFlags.Instance); this is how i delete the dll from the directory. nothing fancy. string tempPath = Path.GetTempPath(); string strTempName = tempDeleteDLL + ".dll"; FileInfo fileInfo = new FileInfo(tempPath + strTempName); fileInfo.Delete(); throws the Exeption as soon as it executes Delete(): "Access to the Path C:\..\..\ is denied." normally i can delete the dll. just not after i run the Reflection code above. any ideas or help would be great. thanks Orion
-
hello, to get information from the dll ie. the methods,types, parameters i use Reflection. at certain times i have to delete this dll which is usually not a problem. the problem is once i've reloaded a dll and performed some reflection on it, that when i go to delete the dll using FileInfo.Delete() i get an Access is Denied exception. so its as if the dll is still being used or a thread that's still alive or.... this one's got me stumped. maybe there's a better way of reflecting the information from the dll or something. here's the code starting with the Reflection: pretty straight forward. so i get the dll pass it into an Assembly and there you go. for what i need to do i think its about the easiest least overhead way. string tempPath = Path.GetTempPath();//Gets the path to the MS tempdir string strMSTempPath = tempPath.Replace(@"\", @"\\"); string strTempName = strNameSpace + ".dll"; Assembly ass = Assembly.LoadFrom(strMSTempPath + strTempName); string strObject = strNameSpace + "." + strServiceName; Type typeDynProxy = ass.GetType(strObject); MethodInfo[] methodArray = typeDynProxy.GetMethods(BindingFlags.Public|BindingFlags.Instance); this is how i delete the dll from the directory. nothing fancy. string tempPath = Path.GetTempPath(); string strTempName = tempDeleteDLL + ".dll"; FileInfo fileInfo = new FileInfo(tempPath + strTempName); fileInfo.Delete(); throws the Exeption as soon as it executes Delete(): "Access to the Path C:\..\..\ is denied." normally i can delete the dll. just not after i run the Reflection code above. any ideas or help would be great. thanks Orion
The problem is that once an assembly is loaded into an AppDomain the assembly isn't unloaded until the AppDomain is unloaded. An AppDomain is a basic unit of execution; its similar to a process in Win32; but in .NET a single process can host multiple AppDomains. So what you need to do is create a new AppDomain, then load the assembly into that; the tricky part is you can't have any reference of that assembly in your current AppDomain, otherwise the assembly gets loaded into it too. I don't have any code laying around for that; but it is something I plan on looking into when I get back from my little vacation :) James Simplicity Rules!
-
The problem is that once an assembly is loaded into an AppDomain the assembly isn't unloaded until the AppDomain is unloaded. An AppDomain is a basic unit of execution; its similar to a process in Win32; but in .NET a single process can host multiple AppDomains. So what you need to do is create a new AppDomain, then load the assembly into that; the tricky part is you can't have any reference of that assembly in your current AppDomain, otherwise the assembly gets loaded into it too. I don't have any code laying around for that; but it is something I plan on looking into when I get back from my little vacation :) James Simplicity Rules!
Thanks James, you guys and this site rules..!! i figured it was a deeper problem. so bear with me i just need to get this straight before i dive in here. its the reference part that's got me. of course :~)) if i get this figured out i'll send you the code. outside of the dll issue, where does the one AppDomain start and end? if i understand it right an application running is made up of many AppDomains (ie. WinForms, Projects..), but the AppDomains are referencing each other within a singular process. OR, is an Application all being combined into a singular AppDomain regardless of whether i create a New AppDomain or not? the way i have it right now i've got a Windows.Form which is referencing a separate class which obviously is doing all the work, and that's all part of the main App running. so, and correct me if i'm wrong, by your explanation, that class and everything it does gets added to the "Calling" AppDomain (WinForm), and by that logic all WinForms/Components what ever, ends up being combined into a singular AppDomain. Do i have that right?? Or do they remain separate at least to some degree. so i'm wondering to what degree i need to keep this New AppDomain "isolated". in the problem i'm having i'm not instantiating the dll or invoking methods, classes or anything like that. i purely need some info from it (it will be later but by that pt i won't have to worry about deleting it). hope i made sense here.. :~)) Thanks. Orion
-
Thanks James, you guys and this site rules..!! i figured it was a deeper problem. so bear with me i just need to get this straight before i dive in here. its the reference part that's got me. of course :~)) if i get this figured out i'll send you the code. outside of the dll issue, where does the one AppDomain start and end? if i understand it right an application running is made up of many AppDomains (ie. WinForms, Projects..), but the AppDomains are referencing each other within a singular process. OR, is an Application all being combined into a singular AppDomain regardless of whether i create a New AppDomain or not? the way i have it right now i've got a Windows.Form which is referencing a separate class which obviously is doing all the work, and that's all part of the main App running. so, and correct me if i'm wrong, by your explanation, that class and everything it does gets added to the "Calling" AppDomain (WinForm), and by that logic all WinForms/Components what ever, ends up being combined into a singular AppDomain. Do i have that right?? Or do they remain separate at least to some degree. so i'm wondering to what degree i need to keep this New AppDomain "isolated". in the problem i'm having i'm not instantiating the dll or invoking methods, classes or anything like that. i purely need some info from it (it will be later but by that pt i won't have to worry about deleting it). hope i made sense here.. :~)) Thanks. Orion
Check out my latest column on AppDomains and dynamic loading: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp05162002.asp
-
Check out my latest column on AppDomains and dynamic loading: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp05162002.asp
Thanks Eric, I will.. :) Orion