Consider adopting IFileProvider abstraction for all file system interactions

Is your feature request related to a problem? Please describe. In various places, system.io namespace is used to check check for folders / files and read files into memory. These means there is no level of indirection for file access.

Describe the solution you’d like I would like to provide an IFileProvider to be used for all file system access (Microsoft.Extensions.FileProviders). The benefit of this, to me, is that there are many different implementations of IFileProvider that could be swapped out as needed. For example, for testing, I could use an InMemory IFileProvider (stage in memory streams for plugins and config files). At application run time, I could use the PhysicalFileProvider from IHostingEnvironment or perhaps provide an AzureBlobStorageFileProvider or 7ZipArchiveFileProvider (there are some IFileProviders that allow you to effectively mount zip archives as a file system which could be useful if you want to download plugins as zip files, and want to keep them compressed).

Describe alternatives you’ve considered Sticking with system.io.

Additional context Add any other context or screenshots about the feature request here.

[dazinator]

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

[natemcmaster]

Yeah, that sounds like a better approach.