Limitations of AssemblyLoadContext Unloading for Hot‑Swap in .NET 6

Goal: Replace the implementation of a service interface in a running .NET 6 process without restarting the host, by loading a new version into a separate AssemblyLoadContext and unloading the old one.

Constraint: The service interface (IService) must reside in a shared AssemblyLoadContext that stays loaded; any types that need to persist across versions cannot be defined only in the unloadable context. Additionally, unloading an AssemblyLoadContext does not immediately release native resources held by the loaded assemblies, and the timing of unload completion can vary between .NET Core 3.0, .NET 5+, and .NET 6+.

• What mechanisms ensure that all references to the old implementation are released before unloading to avoid MissingMethodException or InvalidCastException?
• How can developers deterministically release native resources associated with assemblies in an unloadable AssemblyLoadContext?
• Are there version‑specific guarantees or recommended testing procedures to confirm that the host process remains stable across successive hot‑swap cycles in .NET 6?