Alc dyn

[pinzart90]

Type.GetType() changed loading behavior : (also GetTypes?) only searches in the default load context and calling assembly's load context for already loaded assemblies. When assemblies are loaded into custom AssemblyLoadContexts, Type.GetType() cannot find types from those assemblies, so it will probably hit the AppDomain/AppLoadCOntext AssemblyLoaded events.

• this might be a problem with types that live in custom alcs (like from packages - Python)?
• might be a problem with types from other host app addins (loaded in custom alcs)?
• not a problem if the following assemblies/types are in the calling assembly's alc?
• might be a problem with DynamoCore if DynamoCore assemblies are loaded in a custom/shared alc.
• might be a problem with types from the Host app (if it is not in the default alc)

Package nodes becoming dummy nodes?
Python type system issues?
Serialization/deserialization issues?
Dynamic type resolution failures in Dynamo VM?
The solution is to implement AssemblyLoadContext-aware type resolution that searches across all load contexts, not just the default one?

WPF xaml parser will load referenced dlls randomly (first one in app domain assemblies), even if from another alc.
Incompatible Dynamo versions loaded in separate ALCs will cause an issue. Also other dependencies that are referenced from XAML ?

How to write tests for ALC behavior?

[mjkkirschner]

hah - just started looking at this as well - code looks pretty similar.
mjkkirschner@35ba318?w=1

I was going to explore:
https://learn.microsoft.com/en-us/dotnet/api/system.runtime.loader.assemblyloadcontext.entercontextualreflection?view=net-9.0#system-runtime-loader-assemblyloadcontext-entercontextualreflection

to deal with the Type.GetType() and other loading like xaml where ALC is implicit or ambiguous.