Unable to delete File (dll) after unloading context.

[FrankDoersam]

Hello,

i could not delete a dll after unloading it.

Could you please fix this bug.

Code:

class SimpleUnloadableAssemblyLoadContext : AssemblyLoadContext
{
public SimpleUnloadableAssemblyLoadContext()
: base(isCollectible: true)
{
}

    protected override Assembly Load(AssemblyName assemblyName) => null;
}

class Program
{
    private static void ExecuteAssembly(Assembly assembly)
    {
        MethodInfo entry = assembly.EntryPoint;
        foreach (Type type in assembly.GetTypes())
        {
            Console.WriteLine(type.FullName);
        }
        Console.WriteLine("ok");

    }

    static void Main(string[] args)
    {
        AssemblyLoadContext tt = new SimpleUnloadableAssemblyLoadContext();
        tt.LoadFromAssemblyPath(@"C:\Lokale Daten\AppDomainUnload\ConsoleApp1\bin\Debug\netcoreapp3.0\Plugin\Plugin1.dll");

        tt.Unload();
        Console.ReadKey();
    }

    private static void Context_Unloading(AssemblyLoadContext obj)
    {
        Console.WriteLine("Unloading");
    }
}

Thanks in advance.
Yours sincerely
Frank Dörsam

[jkotas]

Answered in https://github.com/dotnet/corefx/issues/19773#issuecomment-435888506

We should make sure to include this in the documentation for assembly unloading at https://docs.microsoft.com/en-us/

[janvorli]

Closing this issue as we have already published a doc on unloading at https://docs.microsoft.com/en-us/dotnet/standard/assembly/unloadability-howto

[masums]

Unfortunately Microsoft's example project also unable to delete dll after unloading.
https://github.com/dotnet/samples/tree/master/core/tutorials/Unloading
I have tested this example project. Deleted plugins after Console.WriteLine().
Throws exception. I have added following lines

            Console.WriteLine($"Unload success: {!hostAlcWeakRef.IsAlive}");
            File.Delete(pluginFullPath);

[NMSAzulX]

I had the same problem and I'm going to do more tests tonight.

[NMSAzulX]

@masums @FrankDoersam I solved this problem using stream loading.Maybe it can solve your problem.

if (!DynamicDlls.ContainsKey(path))
{
        using (FileStream stream = new FileStream(path, FileMode.Open))
        {
              var assembly = LoadFromStream(stream);
              var types = assembly.GetTypes();

              for (int i = 0; i < types.Length; i++)
              {
                   ClassMapping[types[i].Name] = assembly;
              }
        }
}

It's ok.
But before you unload it, you have to clear the dictionary.
DynamicDlls.Clear(); (Note: Don't do it in the 'Main' method.)

[masums]

Thank you for your suggestion. But how it will load its dependencies. And will we be able to delete them also after unload?

…

On Wed, Aug 21, 2019 at 7:15 AM 东北亚 · 丧坤 ***@***.***> wrote: @masums <https://github.com/masums> @FrankDoersam <https://github.com/FrankDoersam> I solved this problem using stream loading.Maybe it can solve your problem. if (!DynamicDlls.ContainsKey(path)) { using (FileStream stream = new FileStream(path, FileMode.Open)) { var assembly = LoadFromStream(stream); var types = assembly.GetTypes(); for (int i = 0; i < types.Length; i++) { ClassMapping[types[i].Name] = assembly; } } } It's ok. But before you unload it, you have to clear the dictionary. DynamicDlls.Clear(); (Note: Don't do it in the 'Main' method.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/dotnet/coreclr/issues/20806?email_source=notifications&email_token=AANTGWFDC2563EBZ6XRK2HLQFSJK7A5CNFSM4GB2WXQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4YDXPA#issuecomment-523254716>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANTGWDQ2W2KBDV7SVAQDS3QFSJK7ANCNFSM4GB2WXQQ> .

[NMSAzulX]

@masums Maybe using AssemblyDependencyResolver.
Although I don't know how to use it yet, I'm just referring to the official example.

I have a project based on roslyn. I use DependencyContext.Default.CompileLibraries to get all dependencies when I compile dynamically.

[NMSAzulX]

@masums Unwittingly, I found a solution to this.

In the constructor

if (arg == "Default")
{
     Default.Resolving += Default_Resolving;
}

In the class

//Default will 
private Assembly Default_Resolving(AssemblyLoadContext arg1, AssemblyName arg2)
{
   return Load(arg2);
}

protected override Assembly Load(AssemblyName assemblyName)
{
    string assemblyPath = _resolver.ResolveAssemblyToPath(assemblyName);
    if (assemblyPath != null)
    {
         return Handler(assemblyPath);
    }

    return null;
}

@janvorli I'm a little confused. If I use the Resolving event instead of implementing the Load method, it will also work. Load and Resolving have the same functionality?

[janvorli]

@vitek-karas can you please answer the question about Resolving event vs Load method?

[janvorli]

Unfortunately Microsoft's example project also unable to delete dll after unloading.

@masums I am sorry, I've missed your comment on this here. It should work, so let me try to figure out what's wrong.

[NMSAzulX]

@janvorli I have an issue. I learned SOS debugging and printed out some information, but I don't know if it's useful? https://github.com/dotnet/coreclr/issues/26386

[vitek-karas]

• AssemblyLoadContext.Load method is the first thing called during the resolution. So this gives you the ability to resolve all assembly requests in the load context. Only once this returns null, the control goes to the default load context as a fallback. So this allows you to load a different version of a given assembly than the one in the default context.
• AssemblyLoadContext.Resolving event is fired when all other attempts for resolution failed - it's basically the last chance (almost). So in this case if the assembly exists in the default load context it would not get to the event handler at all.

The AssemblyDependencyResolver is typically used in the Load method (to allow overrides of the default context). But obviously it depends on your scenario.

Another difference is that the Resolving event can be handled even on the default load context (you can add your event handler to AssemblyLoadContext.Default.Resolving. It is not possible to override the Load method on the default context though (this is intentional - it would be really easy to completely break everything if that method had a bug in it).

@NMSAzulX loading from memory should work, but there is a downside - it will not work with Ready2Run images (assemblies precompiled via crossgen). That might be OK in your scenario though. It's also obviously slower as you're making a copy (loading from file just memory maps the file which is typically faster and consumes less memory).

[NMSAzulX]

@janvorli @vitek-karas Thank you very much.Will there be any documents coming out?

[vitek-karas]

Documentation about the AssemblyLoadContext and the actual order in which things happen is here: https://docs.microsoft.com/en-us/dotnet/core/dependency-loading/loading-managed

[NMSAzulX]

@vitek-karas OK .

[masums]

Today I have tested https://github.com/dotnet/samples/tree/master/core/tutorials/Unloading this code again. Now it is working with the new release of .Net core 3.0.100. Delete is working for unloaded dll. May be It will also work for me if I update the framework version.