I found this issue while playing around with using Blazor as a renderer for CMS content. Serverside-blazor has a dependency of a .js-file located as an embedded resource within AspNetCore. Normally, when requesting the url "/_framework/blazor.server.js", the Static file middleware usually mange to provide this file. However, when trying to access this file with CMS set up, the file was no longer to be found.

I managed to narrow down the issue to this.

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapBlazorHub();
                endpoints.MapContent(); //This is the culprit!
            });

So the issue is that when Optimizely registers the routing for content, it overwrites the file providers within the StaticFileOptions instance, without regarding that the change affects the StaticFileMiddleware.

The workaround is simply to override Optimizelys override...

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapBlazorHub();

                var opt = endpoints.ServiceProvider.GetRequiredService<IOptions<StaticFileOptions>>().Value;
                var realprovider = opt.FileProvider;

                endpoints.MapContent(); //Will destroy the correct fileprovider!

                opt.FileProvider = new CompositeFileProvider(realprovider, opt.FileProvider); //Ensure all providers, both original and Episerver ones, are included

            });

This is very ugly and i believe that the PhysicalFileProvider is now mentioned multiple times in the composite tree. It shouldn't affect functionality and as long as there is no collision between Optimizely static files and project-specific static files the fix should do it. However, i think Optimizely needs to get this straighted out. You should not tamper with internal Asp.Net components.