Howto Unload a Dll Programaticlly from your app?
-
This is my Problem: I have two projects open. Project #1 is the server App. It loads a list of Dll from a Configuration file. I load a DLL into my application on startup and can call procedures from it. I want to be able to have the Server App unload the Dll. Project #2 I will modify the DLL ,Save it , and then have the Server App reload the Dll and use it. I can't seem to unload a DLL without closing the Server app. I have everything else working fine. Anyone have any ideas? :confused:
-
This is my Problem: I have two projects open. Project #1 is the server App. It loads a list of Dll from a Configuration file. I load a DLL into my application on startup and can call procedures from it. I want to be able to have the Server App unload the Dll. Project #2 I will modify the DLL ,Save it , and then have the Server App reload the Dll and use it. I can't seem to unload a DLL without closing the Server app. I have everything else working fine. Anyone have any ideas? :confused:
This is a problem that comes up a lot. The short answer is: you can't. The long answer is that this is managed code - the CLR manages everything for you and there's very little you can do about it. As far as "Project #2" goes, you should look at System.CodeDOM and the System.Reflection.Emit namespaces. Using those you could "easily" read-in a template "DLL", modified it, then emit an assembly either in memory (loaded into the current AppDomain) or in memory AND on disk (thus saving it for future use). Several libraries - even the .NET Framework use this technique for non-persisted assemblies, but persisting it is as simple as using a different Enum value in the very same method! Good luck!
Reminiscent of my younger years... 10 LOAD "SCISSORS" 20 RUN
-
This is a problem that comes up a lot. The short answer is: you can't. The long answer is that this is managed code - the CLR manages everything for you and there's very little you can do about it. As far as "Project #2" goes, you should look at System.CodeDOM and the System.Reflection.Emit namespaces. Using those you could "easily" read-in a template "DLL", modified it, then emit an assembly either in memory (loaded into the current AppDomain) or in memory AND on disk (thus saving it for future use). Several libraries - even the .NET Framework use this technique for non-persisted assemblies, but persisting it is as simple as using a different Enum value in the very same method! Good luck!
Reminiscent of my younger years... 10 LOAD "SCISSORS" 20 RUN
Thanks for your assistant. I will research the namespaces you suggested. This is my overall project. I want to create a server app that runs all the time. I want the server to load plugins and run them on set intervals and on specified events. I wanted to create the plugins in VS.net and copy the dll to the plugin location. I also have researched the CodeDom namespace and can actually create the plugins from the Server app and compile/load/Run them but for this to function correctly, I should give the end user the ability to modify the source code of the plugin and recompile/load/run without restarting the server app. If the System.Reflection.Emit will create dynamic assemblies in memory then this may work better than saving them to a dll and loading them for each use. This is my attempt at creating an app with scripting embedded in it. Thanks again for your help ======================================= When your in school all you want is to get out in the real world. Now that I'm in the real world all I want is to go back to school.
-
Thanks for your assistant. I will research the namespaces you suggested. This is my overall project. I want to create a server app that runs all the time. I want the server to load plugins and run them on set intervals and on specified events. I wanted to create the plugins in VS.net and copy the dll to the plugin location. I also have researched the CodeDom namespace and can actually create the plugins from the Server app and compile/load/Run them but for this to function correctly, I should give the end user the ability to modify the source code of the plugin and recompile/load/run without restarting the server app. If the System.Reflection.Emit will create dynamic assemblies in memory then this may work better than saving them to a dll and loading them for each use. This is my attempt at creating an app with scripting embedded in it. Thanks again for your help ======================================= When your in school all you want is to get out in the real world. Now that I'm in the real world all I want is to go back to school.
Actually, if scripting capabilities are what you're looking for, this issue is already solved. You can use the assembly emit stuff to parse, compile, and load script. There are even ways to interop with Windows Script, allowing any scripted language (JScript, VBScript, PerlScript, etc.) to work, so long as you supply the script engine with the objects, methods, properties, and events it can walk and use. See MSDN for more information.
Reminiscent of my younger years... 10 LOAD "SCISSORS" 20 RUN
-
Actually, if scripting capabilities are what you're looking for, this issue is already solved. You can use the assembly emit stuff to parse, compile, and load script. There are even ways to interop with Windows Script, allowing any scripted language (JScript, VBScript, PerlScript, etc.) to work, so long as you supply the script engine with the objects, methods, properties, and events it can walk and use. See MSDN for more information.
Reminiscent of my younger years... 10 LOAD "SCISSORS" 20 RUN
Heath Stewart wrote: 10 LOAD "SCISSORS" 20 RUN :laugh::laugh::laugh:
"Ask not for whom the bell tolls;
It tolls for thee..." -
Actually, if scripting capabilities are what you're looking for, this issue is already solved. You can use the assembly emit stuff to parse, compile, and load script. There are even ways to interop with Windows Script, allowing any scripted language (JScript, VBScript, PerlScript, etc.) to work, so long as you supply the script engine with the objects, methods, properties, and events it can walk and use. See MSDN for more information.
Reminiscent of my younger years... 10 LOAD "SCISSORS" 20 RUN
I tried to modify my code to generate the assembly in memory instead of creating the dll on disk. and I get an error. An unhandled exception of type 'System.IO.FileNotFoundException' occurred in mscorlib.dll Additional information: Could not find file "C:\DOCUME~1\GDUDLE~1.MBI\LOCALS~1\Temp\cdqmv_u2.dll". Unhandled Exception: System.IO.FileNotFoundException: Could not find file "C:\DOCUME~1\GDUDLE~1.MBI\LOCALS~1\Temp\cdqmv_u2.dll". File name: "C:\DOCUME~1\GDUDLE~1.MBI\LOCALS~1\Temp\cdqmv_u2.dll" does this mean it is still creating and loading from the disk? The filename it is displaying changes each time I run it so I assume it is a temp file. ================================= When i was in school all I wanted was to get out into the real world. Now that I'm in the real world all I want is to go back to school.