Consider supporting VirtualPathProvider and associated infrastructure #218
Description
Summary
Consider supporting VirtualPathProvider and associated classes: HostingEnvironment, VirtualFileBase, VirtualFile, and VirtualDirectory.
In ASP.NET Core, support VirtualPathProvider as an IFileProvider to allow StaticFiles to use VirtualPathProviders.
Wrap the WebRootFileProvider as a VirtualPathProvider as the root provider to replace the MapPath based provider.
Consider providing a package to allow using any IFileProvider as a VirtualPathProvider under System.Web to allow using EmbeddedFileProvider in legacy classes during cutover.
Motivation and goals
This would allow migrating existing scenarios with embedded resources or other virtual files to ASP.NET Core using the adapters.
This would be a stepping-stone to allowing creating a compatible version of Microsoft.AspNet.Web.Optimization / System.Web.Optimization which would unlock scenarios for people using this technology.
In scope
Various classes from System.Web.Hosting including
System.Web.Hosting.HostingEnviroment(at least theVirtualPathProviderandRegisterVirtualPathProvidermembers, althoughCache,ApplicationPhysicalPath, andApplicationVirtualPathmap directly to equivalents inHttpRuntimethat are already implemented.)- VirtualFileBase
- VirtualFile
- VirtualDirectory
- VirtualPathProvider
Extension methods for ASP.NET Core to allow registering VirtualPathProviders via DI instead of legacy methods.
A VirtualPathProvider to wrap any IFileProvider (This could actually be used in legacy Framework projects too, but would require an additional reference to Microsoft.Extensions.FileProviders.Abstractions in whichever project it would be in.)
An FileProvider to wrap the VirtualPathProvider chain to allow the StaticFiles middleware to server files from the VirtualPathProviders.
Out of scope
It would be nice to include the IFileProvider VirtualPathProvider under FrameworkServices or in the main adapters, as this would allow migration from custom VPPs to the existing FileProviders, such as Microsoft.Extensions.FileProviders.Embedded but as this would result in additional dependencies, this can be out of scope.
Risks / unknowns
Moving the existing WebRootFileProvider behind a VirtualPathProvider and then wrapping that as a FileProvider would potentially cause a performance issue with StaticFiles, however this would apply to the original ASP.NET Framework application too, and it is likely that any VPP is already pretty optimized and uses appropriate caching mechanisms to ensure its optimal speed. This is of course an interim step, and as a developer would expect to migrate any custom VPPs to IFileProviders or to use an existing out-of-box provider. (This is one reason to include the option to wrap IFileProviders as VirtualPathProviders).
Examples
Example code for VirtualPathProviders can be found at VirtualPathProvider, VirtualFile, and VirtualDirectory
Global.asax.cs code such as
SamplePathProvider sampleProvider = new SamplePathProvider();
System.Web.Hosting.HostingEnvironment.RegisterVirtualPathProvider(sampleProvider);would become
builder.Services.AddSystemWebAdapters()
.AddJsonSessionSerializer(options => ClassLibrary.RemoteServiceUtils.RegisterSessionKeys(options.KnownKeys))
.AddVirtualPathProvider<ClassLibrary.SamplePathProvider>()
.AddVirtualPathProvidersAsStaticFileProvider(options => options.ServeUnknownFileTypes = true)If IHttpHandler and IHttpModule were implemented along with this, it would be possible to migrate the Microsoft.AspNet.Web.Optimization package that is regularly used in ASP.NET Framework applications without completely replacing the bundling system, making it easier to migrate MVC/Razor applications that use the package.
Detailed design
See https://github.com/CZEMacLeod/systemweb-adapters/tree/czemacleod/virtualpathprovider for a rough implementation - this includes enhancements to Caching as required by the example that would probably deal with #26 too.