none
Release/Unload Assembly? RRS feed

  • Question

  • I dont know if this is the right place to question this. But anyways..

    I inject a bootstrap dll into a process. Where I load the CLR and runs a .NET application. When the application returns I unload my DLL.
    However, the c# application is still running within my process.  How do unload this assembly / module? 
    This is hot it looks.

    My C# application looks like this. Not anything fancy at all. But it still is active within my targeted process after ive run it :(
    [code]
    namespace Main
    {
        public class Initializer
        {
            public static int Init(string arg)
            {
                return 1;
            }
        }
    }
    [/code]
    Saturday, September 26, 2009 1:54 PM

Answers

  • Unloading assemblies requires unloading an AppDomain.  Your injection code would have to create a secondary one.  Injecting the CLR into a process is a questionable practice btw, at least until .NET 4.0 becomes available.  Not only will this fail to work when the process already has the CLR loaded, you'll also screw up the process when it wants to load the CLR itself at some later time.

    Hans Passant.
    Saturday, September 26, 2009 4:17 PM
    Moderator
  • > Unloading assemblies requires unloading an AppDomain.

    In the .NET Framework, this is unfortunate but true.

    <soapbox>
    There is a lot of hype about dynamic languages, but I'd sure like to see a more dynamic runtime that could load and unload any kind of assembly seamlessly.  This would take a major overhaul of the CLR.  For example, the memory management/GC would need to be smarter to deal with unloading methods that are on a stack, converting objects from old layouts to new layouts, etc.  But in a managed environment like .NET, these things do not seem insurmountable.  The result would be the perfection of Edit and Continue, "hot" code replacement, and plug-ins.  (Keep in mind that historically many environments including some very old ones have provided hot code replacement.  This is similar to virtual machines, which are now catching on big time in the Windows world, though VMs were used with great success way back in the 70's on mainframes!)  It's wishful thinking, I know, but wouldn't it be great if .NET 5.0? (6.0?) was engineered to support these things?
    </soapbox>

    Saturday, September 26, 2009 6:48 PM

All replies

  • Take a different approach.  Read all the bytes of the assembly using File.ReadAllBytes, then load the assembly using the overload of Assembly.Load that takes a byte array. This way the file will be unlocked immediately after reading the contents.  You'll be using an in-memory version of the file instead of an on-disk version.
    Coding Light - Illuminated Ideas and Algorithms in Software
    Coding Light WikiLinkedInForumsBrowser
    • Proposed as answer by Skkra Thursday, March 4, 2010 1:38 PM
    Saturday, September 26, 2009 4:02 PM
    Moderator
  • Unloading assemblies requires unloading an AppDomain.  Your injection code would have to create a secondary one.  Injecting the CLR into a process is a questionable practice btw, at least until .NET 4.0 becomes available.  Not only will this fail to work when the process already has the CLR loaded, you'll also screw up the process when it wants to load the CLR itself at some later time.

    Hans Passant.
    Saturday, September 26, 2009 4:17 PM
    Moderator
  • > Unloading assemblies requires unloading an AppDomain.

    In the .NET Framework, this is unfortunate but true.

    <soapbox>
    There is a lot of hype about dynamic languages, but I'd sure like to see a more dynamic runtime that could load and unload any kind of assembly seamlessly.  This would take a major overhaul of the CLR.  For example, the memory management/GC would need to be smarter to deal with unloading methods that are on a stack, converting objects from old layouts to new layouts, etc.  But in a managed environment like .NET, these things do not seem insurmountable.  The result would be the perfection of Edit and Continue, "hot" code replacement, and plug-ins.  (Keep in mind that historically many environments including some very old ones have provided hot code replacement.  This is similar to virtual machines, which are now catching on big time in the Windows world, though VMs were used with great success way back in the 70's on mainframes!)  It's wishful thinking, I know, but wouldn't it be great if .NET 5.0? (6.0?) was engineered to support these things?
    </soapbox>

    Saturday, September 26, 2009 6:48 PM
  • Hi
    The problem is that here the assembly is already loaded. Even if I load it with File.ReadAllBytes I will only load another copy of my assembly. And the file will still be used.

    I load my assembly from a bootstrap DLL written in C++.  And when I use
    hr = pClrHost->ExecuteInDefaultAppDomain(
    I cant use the File.ReadAllByte stuff. here.. And later on its too late? :(
    Monday, September 28, 2009 4:23 PM
  • Well, don't use ExecuteInDefaultAppDomain(), that loads the assembly in the primary AD.  Use ICorRuntimeHost::CreateDomain(), then _AppDomain::ExecuteAssembly().

    Hans Passant.
    Monday, September 28, 2009 5:37 PM
    Moderator
  • Hi Marcus,
          I am not very sure about your requirement. Are you looking for something as below?
    http://social.msdn.microsoft.com/Forums/en-US/clr/thread/7127b294-d87e-4aac-a001-bf36a7dd3e5f 

    Thanks
    PKR
    Tuesday, September 29, 2009 10:53 AM
  • Hi Marcus,

    http://blogs.msdn.com/suzcook/archive/2003/07/08/57211.aspx

    Try loading the assembly in an appdomain and unloading the appdomain.
    The above link could help you
    Wednesday, September 30, 2009 8:47 AM
  • have you tried shadowcopying an assembly?
    http://msdn.microsoft.com/en-us/library/ms404279.aspx

    Cheers
    Manju
    Wednesday, September 30, 2009 9:11 AM