Tech Off Thread

17 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

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

Back to Forum: Tech Off
  • User profile image
    darklotus

    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

  • User profile image
    JohnAskew
  • User profile image
    Sven Groot

    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.

  • User profile image
    JohnAskew

    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?

  • User profile image
    Deactivated User

    Comment removed at user's request.

  • User profile image
    Sven Groot

    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.

  • User profile image
    figuerres

    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....

  • User profile image
    footballism

    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

  • User profile image
    Sven Groot

    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.

  • User profile image
    JohnAskew

    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... 

  • User profile image
    rhm

    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.

  • User profile image
    AndyC

    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.

  • User profile image
    darklotus

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

  • User profile image
    rhm

    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.

  • User profile image
    TommyCarlier

    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?

  • User profile image
    JohnAskew

    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.

  • User profile image
    codewiz

    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.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.