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

Ensuring Clean Unloading for Hot-Swap Implementation

To replace a service implementation in .NET 6 without restarting the host, you must ensure that the AssemblyLoadContext (ALC) is fully collectible. The primary mechanism to prevent MissingMethodException or InvalidCastException is strict interface isolation. The IService interface must reside in a shared, non-unloadable assembly (typically the default ALC), while the implementation resides in the collectible ALC.

Reference Release Mechanisms

An ALC will not unload if any live references to its types, instances, or static fields remain. To ensure all references are released:

• Avoid Direct Type References: The host must only hold references to the implementation via the IService interface. Never cast to the concrete implementation type in the host.
• Clear Event Subscriptions: Any events in the host that the service implementation subscribed to must be explicitly unsubscribed. A single delegate reference will keep the entire ALC alive.
• Nullify Service Providers: If using a custom service locator or DI container, the reference to the old implementation must be nullified or replaced before calling ALC.Unload().
• Clear Static Caches: Ensure no static collections in the shared context hold instances or Type objects from the unloadable context.

Deterministic Release of Native Resources

Unloading an ALC does not automatically reclaim native resources (unmanaged memory, file handles, or P/Invoke allocations). These must be handled deterministically:

1. Implement IDisposable: The service implementation should implement IDisposable.
2. Explicit Cleanup: The host must call Dispose() on the service instance before initiating the Unload() call.
3. Unmanaged Handlers: If the assembly loads native DLLs via LoadUnmanagedDll, ensure the ALC is configured to handle these, though explicit cleanup of native handles remains the developer's responsibility.

Stability and Verification in .NET 6

While .NET 6 provides a stable ALC implementation, unloading is not instantaneous; it is triggered by the Garbage Collector (GC). To verify stability across successive hot-swap cycles, use the following procedure:

// Verification Pattern
WeakReference alcWeakRef = new WeakReference(myCollectibleAlc);
myCollectibleAlc.Unload();
myCollectibleAlc = null; // Remove strong reference

for (int i = 0; i < 10 && alcWeakRef.IsAlive; i++)
{
    GC.Collect();
    GC.WaitForPendingFinalizers();
}

if (alcWeakRef.IsAlive) 
{
    // ALC is leaking; check for remaining references/delegates
}

For long-term stability, monitor the Private Working Set memory. A linear increase in memory across 50+ swap cycles indicates a leak of either managed types or native resources.

Diagnostic Detail Needed: Are you using any third-party Dependency Injection containers or AOP frameworks (like Castle DynamicProxy) to wrap the service? These often create proxy types that can inadvertently hold references to the implementation context.