-
Notifications
You must be signed in to change notification settings - Fork 17
Description
I came across a problem when trying to use Vagabond in my project.
In my situation some assemblies were failing to load via Vagabond.
After some digging, I narrowed it down to the runtime being unable to load the said assemblies due to some conflict in the default AssemblyLoadContext. (I could not actually tell what the issue was as all all I get is a FileLoadException from the AssemblyLoadContext)
I noticed in Vagabond Utils that everything uses the currentLoadContext as here
let asm = Assembly.GetExecutingAssembly()
AssemblyLoadContext.GetLoadContext asm
But the current docs tend to suggest that it might be a better idea to load things to a seperate AssemblyLoadContext to get around any conflicts (version issues etc).
I refactored Vagabond to weave in a new AssemblyLoadContext and my project now runs without error, but the implementation smells.
The key idea was to create a new AssemblyLoadContext with each VagabondManager, like this
type VagabondManager internal (config : VagabondConfiguration) =
let ctx = VagaBondLoadContext() :> AssemblyLoadContext
do registerAssemblyResolutionHandler (Some (ctx))
And then I adjusted the tryGetLoadedAssembly and registerAssemblyResolutionHandler functions in Utils to take the AssemblyLoadContext option or use the default if None, Lastly adjusting the VagaBondState to carry round the new AssemblyLoadContext
Just thought I'd kick off a discussion if this looks reasonable, or if other developments have progressed in light of #23 and a better way is known.
Can stick up a repo if it is helpful.