[browser][coreCLR] Assembly.LoadFrom("xxx.dll") doesn't hit external_assembly_probe #122972
Description
In browser/wasm we download DLLs from server during startup. This is done because dotnet API for loading assemblies is synchronous and browser fetch is asynchronous. And so we could not fetch assembly from server lazily on-demand (in single thread).
So there is application manifest that contains list of all known assemblies. We install them into linear memory, but we do not place them into virtual file system (VFS). Because that would consume additional memory of the browser tab. We don't really have memory mapping that normal OS has. VFS is bunch of JS objects, which don't live in WASM linear memory.
The normal behavior of Assembly.LoadFrom("xxx.dll") is to look up the file on disk and memory map it into dotnet process.
Mono on WASM intercepts LoadFrom via mono_dl_open and if the file is already in memory, we would return that.
On CoreCLR, there is external_assembly_probe that we use to load files into memory, but it is not called for Assembly.LoadFrom. Should we call external_assembly_probe for Assembly.LoadFrom ?
Xharness on WASM is using that Mono/WASM behavior and possibly other Blazor applications, we don't know.