All AssemblyLoadContexts share a file path cache

[RomanSoloweow]

Description

Hi, my application has a plugin architecture and runs on Linux.

I've encountered an issue under the following scenario:

1. Create a new assembly load context: new MyAssemblyLoadContext()
2. Load an assembly: LoadFromAssemblyPath("my.dll")
3. Install a new package
4. Unload() - though it should not matter as contexts are supposed to be independent
5. Create a new assembly load context: new MyAssemblyLoadContext()
6. Load the same assembly again: LoadFromAssemblyPath("my.dll")

The LoadFromAssemblyPath method returns the old version of the assembly, even though the new version is already present on disk.

My context:

internal sealed class PluginLoadContext : AssemblyLoadContext
{
    private readonly AssemblyDependencyResolver _resolver;
 
    public PluginLoadContext(string name, assemblyPath)
        : base(isCollectible: true, name: name)
    {
        _resolver = new AssemblyDependencyResolver(assemblyPath);
    }
 
    protected override Assembly? Load(AssemblyName assemblyName)
    {
        var assemblyPath = _resolver.ResolveAssemblyToPath(assemblyName);
        var assembly = assemblyPath != null ? LoadFromAssemblyPath(assemblyPath) : null;
        return assembly;
    }
}

Reproduction Steps

1. Create a new assembly load context: new MyAssemblyLoadContext()
2. Load an assembly: LoadFromAssemblyPath("my.dll")
3. Install a new package
4. Unload() - though it should not matter as contexts are supposed to be independent
5. Create a new assembly load context: new MyAssemblyLoadContext()
6. Load the same assembly again: LoadFromAssemblyPath("my.dll")

Expected behavior

A new Assembly from the current dll will be loaded

Actual behavior

Returns Assembly loaded by another context

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[RomanSoloweow]

Hi, any news? @vitek-karas @agocke @VSadov

[agocke]

• @elinor-fung

[agocke]

@RomanSoloweow In your example, are the original plugin paths different?

That is, I understand this as having a layout like

/plugin-dir1/mainasm.dll
/plugin-dir1/secondary.dll
/plugin-dir2/mainasm.dll
/plugin-dir2/secondary.dll

And when you're creating PluginLoadContext("plugin1", "/plugin-dir1/mainasm.dll") and PluginLoadContext("plugin2", "/plugin-dir2/mainasm.dll"). And you expect that the context (1) and the context (2) will have different copies of secondary.dll, right?

[RomanSoloweow]

No, i call PluginLoadContext("plugin1", "/plugin-dir1/mainasm.dll"), replace dll and call PluginLoadContext("plugin1", "/plugin-dir1/mainasm.dll") again

And i expect that the context (1) and the context (2) will have different copies of mainasm.dll

[elinor-fung]

@RomanSoloweow would it be possible for you to provide a minimal repro?

3. Install a new package

Is this equivalent to directly replacing the .dll passed to LoadFromAssemblyPath - for example via just a manual copy/overwrite? Or is there more to installing a new package?

I tried a simple version based on the description. Replacing the .dll passed to LoadFromAssemblyPath and loading it in a new ALC returns the new/replaced assembly.

string path = Path.Combine(AppContext.BaseDirectory, "lib.dll");
string v1 = Path.Combine(AppContext.BaseDirectory, "lib-v1.dll");
string v2 = Path.Combine(AppContext.BaseDirectory, "lib-v2.dll");
File.Copy(v1, path, overwrite: true);

WeakReference alc1 = LoadAndUnload("alc1", path);
for (int i = 0; alc1.IsAlive && (i < 10); i++)
{
    GC.Collect();
    GC.WaitForPendingFinalizers();
}

File.Copy(v2, path, overwrite: true);
LoadAndUnload("alc2", path);

[MethodImpl(MethodImplOptions.NoInlining)]
static WeakReference LoadAndUnload(string name, string path)
{
    var alc = new AssemblyLoadContext(name, isCollectible: true);
    Assembly a = alc.LoadFromAssemblyPath(path);
    Console.WriteLine($"""
        {name} : {path}
            {a}
        """);
    WeakReference weakRef = new WeakReference(alc, trackResurrection: true);
    alc.Unload();
    return weakRef;
}

Outputs:

alc1 : C:\issues\112911\app\bin\Debug\net9.0\lib.dll
    lib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
alc2 : C:\issues\112911\app\bin\Debug\net9.0\lib.dll
    lib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null

[jkotas]

.NET assembly loader has a cache of loaded assembly files. This cache is indexed by a path. This cache assumes that the files are not changing on the file system. There may be a small delay between the point where assembly is unloaded (e.g. GC.Collect that collects the collectible assembly returns) and the point where assembly is released from the cache.

Thus, if you load an assembly from a path, unload it, and load a new assembly from the same path immediately after that, you may still get the content of the original assembly if it was not released from the cache.

[RomanSoloweow]

Is it possible to disable this cache or download bypassing the cache?

[jkotas]

You can override the cache by reading the file yourself and then using AssemblyLoadContext.LoadFromStream API to load it. This workaround comes with performance overhead as you may expect.

[agocke]

Separate from the workaround, could we attach this cache to the ALC? It feels like ALC loads should be independent.