[Bug]: ReactiveUI incompatible with .NET Assembly Load Contexts

[guillermooo]

Describe the bug 🐞

It appears that ReactiveUI (RxUI) cannot be used in conjunction with Assembly Load Contexts (ALCs).

Relevant documentation:

• Assembly Load Contexts
• Debugging assembly unloadability

Step to reproduce

• Load ReactiveUI into ALC
• Unload ALC
• Reload ALC

Any .WhenAnyValue() subscriptions will generate a TypeLoadException.

Reproduction repository

https://github.com/guillermooo/rxui-alc

Expected behavior

ReactiveUI should support ALCs correctly.

Screenshots 🖼️

No response

IDE

No response

Operating system

Windows

Version

No response

Device

No response

ReactiveUI Version

All

Additional information ℹ️

I haven't been able to find the root of the issue, but I've explored Type caches such as the one used by ReactiveUI.Reflection.ReallyFindType() and lingering references in Splat's registry without much success so far. But I admit I'm not sure what I should be looking for. I have not tried using WinDbg yet, in spite of being the suggested approach by the .NET documentation linked above.

The only lead I could find to date is that the Splat registry does seem to be pristine when the ALC first loads, and polluted after the ALC is reloaded.

If no fix is found, at least determine that RxUI is incompatible with ALCs due to DLL unloadability issues and document the limitation prominently.

[ChrisPulman]

Thank you for providing a repo showing the issue you are experiencing, I personally have used this with domain level disposal where all dll's are unloaded to clean up, this was using a older version of RxUI so it's possible that there's now a difference somewhere that is blocking the unloading process. Ensuring that every subscription is fully disposed was a key thing from what I recall, anything left active will block the unloading process and fail.

[guillermooo]

@ChrisPulman My understanding is that Application Domains (.NET Framework) forcibly unload assemblies, while ALCs require cooperation to ensure a clean unload. I tried to pare down the repro steps to the absolute minimum and I think disposal of subs is not the issue in the provided repro example. For reference, the rules for ALCs are doumented here.

I think the issue I'm hitting is assembly identity (if that makes any sense), where something in ReactiveUI outlives the ALC and persists after the ALC reload, which doesn't really make much sense to me because then the assembly wasn't unloaded, I suppose, but that's my best explanation at the moment.