Consider adopting IFileProvider abstraction for all file system interactions about dotnetcoreplugins HOT 5 CLOSED

ah ok.

Perhaps a better way forward for me then, is first shadow-copy the plugins from the IFileProvider to some temp physical directory first on startup, and then use dotnetcoreplugins to load them from there as normal. I can then IFileProvider.Watch for changes to plugins in the source at runtime and when they change, Unload the ALC, shadow copy again the new versions, and reload them with dotnetcoreplugins again. Should allow me to host plugins anywhere IFileProvider supports. Should also allow me to update the plugins at the source because they won't be locked by any process due to the addition of the shadow copy before load. I'll close this

from dotnetcoreplugins.

I don't think it's currently possible to do this. APIs this library calls in System.Runtime.Loader.AssemblyLoadContext requires file paths. Introducing a file provider abstraction means I would also need to know whether or not the file provider is physical or not....which IMO defeats the purpose of the abstraction.

from dotnetcoreplugins.

Could the load from stream method be used instead to load the assembly?

https://docs.microsoft.com/en-us/dotnet/api/system.runtime.loader.assemblyloadcontext.loadfromstream?view=netcore-2.2#System_Runtime_Loader_AssemblyLoadContext_LoadFromStream_System_IO_Stream_

I know this wouldn't cater for unmanaged / native libs.

Perhaps another possibility: When the ALC can't find an assembly at an expected path, I think it raises a resolve event to allow you to satisfy the resolution manually - perhaps here could be a good place to query from an IFileProvider?

from dotnetcoreplugins.

LoadFromStream might work, but LoadFromPath is optimized to handle on-disk assemblies better. LoadFromStream requires paging the entire assembly into memory.

And like you mentioned, this is only available for managed assemblies.

from dotnetcoreplugins.

Yeah, that sounds like a better approach.

from dotnetcoreplugins.