Calling an assembly when needed and not part of the application?

I have an exe that is my "shell" i then have a windows control that holds a small gui. When i run a certain form in my application i want to call the dll control and display the contents of the control. Right now it works fine. But right now i am adding the dll reference to my application. Is there a way for me to call a dll thats not a reference in my app and use it in the same way? I want to run a few controls like this but i only want them loaded when they are needed and not from the start. Is this possible and if so, how can i do it or where should i look?
Thanks!
DL:s

http://msdn2.microsoft.com/en-us/library/ky3942xh.aspx

Do make sure you actually need this before using it. The CLR doesn't actually load assemblies until they're used, even if you reference them directly, so if you're doing this purely for performance, it's not necessary.

That is very interesting news, Sven.

Users of the CAB always ask how to "unload" modules (DLLs).
Amazingly no one has pointed out the fact that it doesn't add any value to do so whatsoever. Once again, great info.

...or did I read this right?

If your looking for more info on this the term is "Late Binding" (when you include an assembly as a refrence is called "Early Binding")

JohnAskew wrote:

That is very interesting news, Sven.

Users of the CAB always ask how to "unload" modules (DLLs).
Amazingly no one has pointed out the fact that it doesn't add any value to do so whatsoever. Once again, great info.

...or did I read this right?

What I'm saying is that if you load an assembly manually using Assembly.Load instead of adding it as a reference just to prevent it loading at application startup it's not necessary, because a referenced assembly doesn't load until it's used (for example, I have an app that uses Managed DirectX (directly references its assemblies), if you run it on a system without the MDX runtime, it'll work fine up to the point I try to use anything from those assemblies, only then is an exception thrown.

As for unloading assemblies, that's impossible in .Net without unloading the entire AppDomain, regardless of whether you referenced the assembly during compilation or loaded it manually.

darklotus wrote:

I have an exe that is my "shell" i then have a windows control that holds a small gui. When i run a certain form in my application i want to call the dll control and display the contents of the control. Right now it works fine. But right now i am adding the dll reference to my application. Is there a way for me to call a dll thats not a reference in my app and use it in the same way? I want to run a few controls like this but i only want them loaded when they are needed and not from the start. Is this possible and if so, how can i do it or where should i look?
Thanks!
DL:s

by the way are you refering to the dll directly ??

you may want to (based on what I see in your post) look at / think of using an interface as your "ref"

if you describe an interface with a few methods and have the main app only "say" that it will load an assembly that provides IHavePlugin
for example then you can create different dll's and your app can pick from them at runtime.

in other words a plugin system.

like for example different drawing modules:

GDI
MDX
OGL
Avalon
HTML

and you could let the user pick which one you draw with.

just an example to get you thinking perhaps....

JohnAskew wrote:

That is very interesting news, Sven.
    Amazingly no one has pointed out the fact that it doesn't add any value to do so whatsoever. Once again, great info.

    This is a really generalization, actually dynamically loading assemblies are quite useful in the applications which need to support addins or plugins.


Sheva

footballism wrote:



JohnAskew wrote: That is very interesting news, Sven.     Amazingly no one has pointed out the fact that it doesn't add any value to do so whatsoever. Once again, great info.

    This is a really generalization, actually dynamically loading assemblies are quite useful in the applications which need to support addins or plugins.

Of course, but that's a situation where you don't know in advance what assembly you're going to load, so naturally you have to load them dynamically.

What I was saying was that if you're loading assemblies that you do know about in advance (at compile time) purely for performance reasons (that's at least what it sounded like the OP wanted to do to me) it's not necessary.

The idea of huge applications with many assemblies loaded at run-time causes programmers to believe they need to unload them to make room for others, else run out of memory. This traditional thinking is not applicable for .NET, and can't be done. The GC is overlooked, imho. On another forum, this question arises and hasn't been addressed in a thorough fashion. It will now... 

There are situations where you dynamically generate assemblies (the Regex classes can for example). If you can't unload those you have a memory leak pure and simple. That might not bike you very quickly in the case of the regex classes, but there are more advanced server scenarios where it is a big problem. With .NET you have to chose between loading all assemblies into the main AppDomain and potentially leaking memory, or load them into different AppDomains and suffer cross-domain communication overhead (depends on how 'chatty' the API is).

And no, it's not impossible to unload assemblies, it's just nobody on the CLR team thought it was worth doing. Sun's JVM has been able to garbage collect generated code for a long time.

rhm wrote:

There are situations where you dynamically generate assemblies (the Regex classes can for example). If you can't unload those you have a memory leak pure and simple.

Lightweight code generation.

Thanks for all the helpful posts. I have solved my problem with help from this. Thanks Again.

AndyC wrote:



rhm wrote: There are situations where you dynamically generate assemblies (the Regex classes can for example). If you can't unload those you have a memory leak pure and simple.

Lightweight code generation.

Yes, I think we've been through this before. It's useful for some things, but not lots of others. I see it as further evidence that the CLR team are admitting that not being able to unload code is a problem while trying to put off implementing assembly unloading for as long as possible.

About lightweight code generation: is it possible to store a dynamic method in any way (database, file system) and later retrieve it back for execution?

TommyCarlier wrote:

About lightweight code generation: is it possible to store a dynamic method in any way (database, file system) and later retrieve it back for execution?

Dynamic code generation only requires source text... etc, etc....

Check out this great article by Rich Strahl on dynamic code.

If you use LCG you can emit IL-Code on the fly to create a static method that only lives for the life of the application. If you need to cache the results between executions of the application, then create a dynamic assembly using AssemblyBuilder and then write that assembly to disk. Then you can load that assembly each time the app is successively executed.