AssemblyLoadContext.Unload() not closing assembly file handle in .Net 5.0 Preview 6

[Xalcon]

Description

I'm currently testing the .Net 5.0 Preview 6 with some code that was written for .Net Core 3.1, specifically the AssemblyLoadContext's unloading capabilities.
Unloading assemblies does seem to work in 5.0, but the runtime does not close the file handle - the same code works fine in .net core 3.1.5. A minimal example project can be found here: https://github.com/Xalcon/DotNet5AssemblyContextIssue

The solution can be build with dotnet build. This will create 2 folders, one for each framework inside $(SolutionDir)/Out/Debug/.
The binary DotnetAssemblyUnloading.exe will attempt to load the PluginAssembly.dll from the same directory and execute the EntryPont.Main() function in a new collectable AssemblyLoadContext. Afterwards it will unload the context and attempt to delete the PluginAssembly.dll. This fails with an System.UnauthorizedAccessException since the assembly is still opened by the runtime - even though the assembly context was collected.

Configuration

• Which version of .NET is the code running on? .NET 5.0.0-preview.6.20305.6
• What OS and version, and what distro if applicable? Windows 10 Version 2004 (OS Build 19041.388)
• What is the architecture (x64, x86, ARM, ARM64)? x64
• Do you know whether it is specific to that configuration? I've not tested other systems or configurations.

Regression?

• Did this work in a previous build or release of .NET Core, or from .NET Framework?
  The code is working perfectly fine on the .Net Core 3.1.5 runtime. Unloading closes the file handle, allowing the file to be deleted/replaced with a newer version.

Tagging subscribers to this area: @vitek-karas, @agocke
Notify danmosemsft if you want to be subscribed.

[vitek-karas]

@janvorli I was able to repro this locally (exactly as described above, just make sure you switch to the output as your current directory when running the app). It does look like a regression in 5.0. As far as I can tell the app itself doesn't do anything clearly wrong - and the ALC does get unloaded (at least from the outside it looks like it).

[janvorli]

@vitek-karas I have debugged it and I am confident the problem is not in the unloadability related stuff. The related DomainFile destructor ends up getting called properly. On 3.1, it destroys the last reference to the underlying PEFile and so the handle gets closed. On 5.0 though, the refcount is higher by 1 and so the PEFile remains alive and the handle is never closed.
On 5.0, there are 21 calls to PEFile::AddRef / Release for the PluginAssembly.dll and so it seems there is a missing release for one of them.
To debug it under WinDbg, I did the following:

• Add System.Diagnostics.Debugger.Break() after the Thread.Sleep(1000) in the repro to make sure I don't debug stuff beyond that point.
• Set a breakpoint at AssemblyNative::LoadFromPath and run the app
• After hitting the breakpoint, I've set breakpoints at PEFile::AddRef and PEFile::Release and continued running the app

At each hit of the last two breakpoints, the call stack shows where the reference change was coming from.

One of the differences between 3.1 and 5.0 was that the 5.0 adds the ref in the BinderTracing::AssemblyBindOperation::SetResult, which gets called 3 times, but I have not hit any calls to AssemblyBindOperation destructor that is supposed to release the reference. But if that was the culprit, I'd expect the reference count to be higher by 3 and not by 1 at the point when the PEFile is supposed to get destroyed.
It would be great if someone who understands the binding code better like e.g. @elinor-fung could take a look.

[janvorli]

I have also created a gist with log of stack traces at the PEFile::AddRef / Release: https://gist.github.com/janvorli/c924c053ea0097a62760cbd76129fd34

[elinor-fung]

Thanks @janvorli. I will take a look.