multiple loading of assemblies - does it have any associated problems?
-
I want to keep some of my classes in library files and load them during runtime. I can load the assemblies and everything works fine. However, I don't find any function that will close or unload the assembly after a method is done using the assembly. If the function is called several times, the assembly loading will be done multiple times. Without any function to unload it, can it cause any problem in application some times? I'm now beginning the project so I would like to know the right approach and follow it. I would like to know before I start my project as I do not want to face any problems in the middle of the project. Please help and thanks in advance.
-
I want to keep some of my classes in library files and load them during runtime. I can load the assemblies and everything works fine. However, I don't find any function that will close or unload the assembly after a method is done using the assembly. If the function is called several times, the assembly loading will be done multiple times. Without any function to unload it, can it cause any problem in application some times? I'm now beginning the project so I would like to know the right approach and follow it. I would like to know before I start my project as I do not want to face any problems in the middle of the project. Please help and thanks in advance.
Dan_K wrote:
If the function is called several times, the assembly loading will be done multiple times.
Why? Just add in a boolean that's set when it's loaded the first time, and check it before you load the assembly. That way the logic is executed only once, eliminating the need to know how often the assembly is in memory. FWIW; it's loaded into memory once, and remains there. There's no unloading, unless you put everything in a separate AppDomain.
Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
-
Dan_K wrote:
If the function is called several times, the assembly loading will be done multiple times.
Why? Just add in a boolean that's set when it's loaded the first time, and check it before you load the assembly. That way the logic is executed only once, eliminating the need to know how often the assembly is in memory. FWIW; it's loaded into memory once, and remains there. There's no unloading, unless you put everything in a separate AppDomain.
Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
-
Thanks! But does the AppDomain check whether it has already been loaded so that it does not load again for consecutive calls? I'm using .net framework 4.0.
Dan_K wrote:
But does the AppDomain check whether it has already been loaded so that it does not load again for consecutive calls?
Dunno, you'd have to check the documentation for that. Just add in the check yourself, it's simply a matter of setting and checking a boolean to avoid the question in the first place - I wouldn't waste time on finding out.
Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
-
I want to keep some of my classes in library files and load them during runtime. I can load the assemblies and everything works fine. However, I don't find any function that will close or unload the assembly after a method is done using the assembly. If the function is called several times, the assembly loading will be done multiple times. Without any function to unload it, can it cause any problem in application some times? I'm now beginning the project so I would like to know the right approach and follow it. I would like to know before I start my project as I do not want to face any problems in the middle of the project. Please help and thanks in advance.
Presumably you are referring to reflection in that you are loading the type yourself. Per your basic description you should structure your code such that the assembly, and even the class is only loaded once. Once loaded you create instances from that class.
Dan_K wrote:
I do not want to face any problems in the middle of the project
Better make sure that you do not need to unload it while the app is running since that is a different problem.
-
I want to keep some of my classes in library files and load them during runtime. I can load the assemblies and everything works fine. However, I don't find any function that will close or unload the assembly after a method is done using the assembly. If the function is called several times, the assembly loading will be done multiple times. Without any function to unload it, can it cause any problem in application some times? I'm now beginning the project so I would like to know the right approach and follow it. I would like to know before I start my project as I do not want to face any problems in the middle of the project. Please help and thanks in advance.
Dan_K wrote:
If the function is called several times, the assembly loading will be done multiple times
An assembly is only ever loaded once. There is no such thing as unloading it unless 1) you tear down the entire process into which it was loaded or 2) it was loaded into an AppDomain and you tear down the AppDomain. Really, by trying to load and unload assemblies, you're creating FAR more complexity for your application. What if you unloaded an assembly that your code still needed?? BOOM! Exception! Good luck with this.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
I want to keep some of my classes in library files and load them during runtime. I can load the assemblies and everything works fine. However, I don't find any function that will close or unload the assembly after a method is done using the assembly. If the function is called several times, the assembly loading will be done multiple times. Without any function to unload it, can it cause any problem in application some times? I'm now beginning the project so I would like to know the right approach and follow it. I would like to know before I start my project as I do not want to face any problems in the middle of the project. Please help and thanks in advance.
If you have the need for unloading assemblies then you have to load them in a dedicated AppDomain you will create first. The advantages is that you can kill the newly created AppDomain (unloading assemblies) and other advantage is that if one assembly you load is "rotten" then you are not damaging the primary AppDomain. The drawback is the only basic option to communicate between appdomain is remoting. If you are looking for some kind of plug-in mechanism then have a look at ms Managed Extensibility Framework (MEF). You'll find good articles on CP about it.
-
I want to keep some of my classes in library files and load them during runtime. I can load the assemblies and everything works fine. However, I don't find any function that will close or unload the assembly after a method is done using the assembly. If the function is called several times, the assembly loading will be done multiple times. Without any function to unload it, can it cause any problem in application some times? I'm now beginning the project so I would like to know the right approach and follow it. I would like to know before I start my project as I do not want to face any problems in the middle of the project. Please help and thanks in advance.
Do you really need to 'load them at runtime' (i.e. dynamically using Assembly.Load)? You only need to do that if you want a plugin based architecture. Simply linking to the DLLs at compile time should be sufficient in most cases. If you do, you should implement some sort of lazy loading wrapper which loads an assembly only if it needs it. Though I think Assembly.Load probably already does that for you internally (don't quote me on that though). You can only unload assemblies if they're loaded into separate AppDomains, which has serious implications for communication between modules.
-
If you have the need for unloading assemblies then you have to load them in a dedicated AppDomain you will create first. The advantages is that you can kill the newly created AppDomain (unloading assemblies) and other advantage is that if one assembly you load is "rotten" then you are not damaging the primary AppDomain. The drawback is the only basic option to communicate between appdomain is remoting. If you are looking for some kind of plug-in mechanism then have a look at ms Managed Extensibility Framework (MEF). You'll find good articles on CP about it.