runtime: AssemblyLoadContext Unload does not release assembly lock on Windows

This is a question about how things are supposed to work, but if my suspicion is right I will file a sample project where I reproduce the issue I am experiencing.

Background

I have a project that downloads zip files with assemblies. These assemblies are then loaded into a custom assembly load context. Later on the ALC will be unloaded and then the Unloading event fires (and all assemblies loaded will be unloaded).

I see no increase in memory when repeating this scenario so I guess that the assemblies are unloaded. A weird thing (not important here) is that the global tool dotnet-counters never decrease the number of assemblies loaded. The count increases for every time I create a new ALC, I thought that unloading would make the count decrease.

The Issue

When the Unloading of a ALC is completed my assumption was that the assemblies would be released/unlocked on windows so that I actually can remove them form the file system. However, this is not the case. If assemblies can be unloaded it would make sense to also let us delete the plugins since we might update the plugins later on and on windows we get exceptions since we cant delete the locked assemblies loaded by the ALC even though the ALC is long gone and the assemblies unloaded from dotnet core.

The be more specific the assemblies are written to a shared docker volume, since we want to persist these assemblies between if the container restarts.

Workaround

I have solved this temporary by only storing a zip with the actual assemblies in the shared volume, and then I load the assemblies inside the container so that windows cant lock them. However, this will probably not work when we later on will use windows containers since my guess is that they will be locked inside the container by windows then.

Environment

Host: Win10 Enterprise 1903 Docker Desktop Base Image: mcr.microsoft.com/dotnet/core/runtime-deps:3.0-alpine Application: dotnet core 3 preview9

The issue only occurs when running containers on windows (Mac/Linux works just fine).

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 1
  • Comments: 26 (11 by maintainers)

Most upvoted comments

@rkuiper1 no worries, it was not a waste of time. I was aware of the other fix, but I wanted to make sure this is not something different.