Looking for the advantages of loading DLLs dynamically as opposed to letting your application load the DLLs by default.
+1
A:
Loading Shared Objects dynamically is the mechanism for allowing plugins ad hoc to running applications. Without plugins a modular application would have to be put together at link-time or compile-time (look at the code of nginx).
Hassan Syed
2010-02-10 11:19:50
+1
A:
Your question is about C#/.NET so in this world dynamic DLL loading requires advanced programming skills. This could compensate all the potential benefits of dynamic DLL loading. You would simply have to write a lot 'low level' code.
In C++/Win32 I often have to load a DLL dynamically when this DLL has some new API function which is not available on older operating systems. In this case I need to ensure the availability of this API at runtime. I cannot just link against this DLL because it will cause application loading errors on legacy operating systems.
As mentioned, you could also have some benefits in a plugin-based environment. In this case you would have more control on your resources if loading DLLs dynamically. Essentially COM is a good example of dynamic DLL handing.
Kerido
2010-02-10 11:32:38
+2
A:
One advantage is for supporting a plugin architecture.
Suppose for example you want to write a service that performs different types of tasks on a scheduled basis. What those tasks are doing, isn't actually relevant to your core service which is just there to kick them off at the right time. And, it's more than likely you want to add support to do other types of tasks in the future (or another developer might want to). In that scenario, by implementing a plugin approach, it allows you to drop in more (compatible by interface) dlls which can be coded independently of the core service. So, adding in support for a new task does not require a new build/deployment of the whole service. If a particular task needs to change, just that dll needs to be redeployed and then automatically picked up.
It also requires other developers to not be concerned with the service themselves, they just need to know what interface to implement so it can be picked up.
AdaTheDev
2010-02-10 11:34:03
What if your system is a non-plugin architecture type system. What other advantages would their be?
James
2010-02-10 11:48:16
The only times I've done it is within a plugin architecture tbh. I can't think of another reason why else I would consider it otherwise. Maybe some sort of security purpose - i.e. only load dlls that give the functionality a certain user is allowed access to. But tbh I'm not even sure that would be a valid approach to take over just controlling other ways in code!
AdaTheDev
2010-02-10 12:05:37
What about performance? Does it matter that you have a DLL loaded when in actual fact you would only be using it rarely?
James
2010-02-10 12:10:36
It would only use a bit more memory to have it loaded. If you load it dynamically at the time of use, and then unloaded straight after, then I think that will be a bigger performance overhead - it has the extra steps to perform each time it's used (even if only rarely) - though I have no hard stats to quantify performance.
AdaTheDev
2010-02-10 12:23:39
Seems to be the only advantage by the looks of it...Thanks.
James
2010-02-18 12:51:57
+1
A:
We use this architecture for our processing applications to handle differences that our different customers require. Each DLL has a similar structure and implements the same interface and entry method "Process()". We have an XML file that defines which class to load based on the customer and whether there are more methods besides process that needs to be called. Performance should not be an issue until your transaction count gets very high.
chamiltongt
2010-02-10 12:28:05
+1
A:
If you only load the DLLs you need then the startuptime of the application should be faster.
Arve
2010-02-10 12:28:40