What is AssemblyLoadContext, and how do plugins work in modern .NET?
Quick Answer
AssemblyLoadContext (ALC) is .NET Core's mechanism for loading assemblies in isolation — the replacement for .NET Framework AppDomains. Each plugin gets its own collectible ALC so it can have its own dependency versions and be unloaded at runtime without restarting the process.
AssemblyLoadContext is how .NET Core isolates loaded assemblies, and it's what took over the isolation and unloading jobs that AppDomains did in .NET Framework — though it dropped the security sandbox part. For a plugin system, the host creates a separate collectible load context for each plugin, so plugin A can depend on version 1 of a library and plugin B on version 2, and the host can unload a plugin at runtime by disposing its context, as long as nothing outside is still holding a reference. The subtlety is that a type loaded in one context isn't the same type in another.
- AppDomains provided isolation + unload + security boundaries; .NET Core kept isolation and unload (via collectible ALCs) but dropped the security-boundary role.
- A plugin host creates an ALC per plugin, resolves the plugin's own dependencies within it, and can dispose it to unload (once no references remain).
- Used by ASP.NET Core hot reload, analyzers, and plugin frameworks.
- Gotchas: type identity is per-ALC (a
Foofrom ALC A ≠Foofrom ALC B), and leaked references prevent unload.