Use Precompiled Views for Razor

[bdukes]

Is there a way to use precompiled views for Razor? We have a big process with a lot of custom code, so we're going to look into potentially forking the built-in Razor module to support precompiled views, but wanted to make sure that we weren't missing this featured being available already.

[daveaglick]

Statiq kind of already does it (it just does it behind the scenes in a way that isn't obvious). An attempt is made to cache all the compiled Razor assemblies to disk in the cache\razor folder. In addition some timestamps and hashes are taken to try and avoid recompilation and use the cached assemblies when possible.

It's not foolproof though, and ensuring cache hits was a PITA - it still sometimes thinks it needs to recompile when there's a cached Razor compilation available. You can generally see the cache in action by running with the -l Debug switch:

 [Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine] View lookup cache hit for view '_footer' in controller '(null)'.

And then at the end of execution you should see something like:

[INFO] Cached and saved 15 new Razor assemblies

That said, I'm seeing more misses than I expect just now while running to copy-paste here, so the caching behavior could obviously use more work. Improving that, or even just using it as a starting point would probably be a good place to start.

[bdukes]

I was able to track down how the Razor Compiler looks for pre-compiled views and to feed it our assembly so that it never tried to use any view files in the file system. After calling services.AddRazor(), I call this method, passing in a type from the type that has the views (since this is .NET 3.1 it generates a sidecar assembly with .Views added to the name; in .NET 6, these get added directly to the main assembly, so that piece won't be needed going forward).

    private static IServiceCollection AddCompiledRazorAssembly(IServiceCollection serviceCollection, Type assemblyType)
    {
        if (serviceCollection == null)
        {
            throw new ArgumentNullException(nameof(serviceCollection));
        }

        var mainAssembly = Assembly.GetAssembly(assemblyType ?? throw new ArgumentNullException(nameof(assemblyType)));
        if (mainAssembly == null)
        {
            throw new ArgumentException("Could not get assembly from type", nameof(assemblyType));
        }

        var mainAssemblyPath = mainAssembly.Location;
        var mainAssemblyDir = Path.GetDirectoryName(mainAssemblyPath);
        if (string.IsNullOrEmpty(mainAssemblyDir))
        {
            throw new ArgumentException("Could not get assembly path from type", nameof(assemblyType));
        }

        var mainAssemblyName = Path.GetFileNameWithoutExtension(mainAssemblyPath);
        var path = Path.Combine(mainAssemblyDir, mainAssemblyName + ".Views.dll");
        var viewsAssembly = Assembly.LoadFile(path);

        var partManager = serviceCollection.Where(sd => sd.ServiceType == typeof(ApplicationPartManager))
                                           .Select(sd => sd.ImplementationInstance).Cast<ApplicationPartManager>().Single();
        partManager.ApplicationParts.AddRange(CompiledRazorAssemblyApplicationPartFactory.GetDefaultApplicationParts(viewsAssembly));

        return serviceCollection;
    }

[daveaglick]

That's fantastic, nice work! So this bypasses Statiq entirely and provides the cached views directly to the Razor compiler (so it never even asks Statiq to compile or provide the view)?

in .NET 6, these get added directly to the main assembly, so that piece won't be needed going forward

Keep an eye out for an update before too long - I think Statiq is going to have to move to target .NET 6 sooner rather than later. What I'm not entirely sure about is whether that means the Razor engine is going to update at the same time. It's a pain to reverse engineer everything and each version bump seems to bring new, unexpected surprises so if I can target .NET 6 with Statiq but leave the Razor engine at the version of ASP.NET Core that shipped with .NET Core 3.1, I might do that initially and update the Razor bits later.

[bdukes]

Right, the RuntimeViewCompiler gets a list of CompiledViewDescriptor instances, and when the requested path matches one of those, it doesn't have to find the view file from Statiq's file system.

We definitely appreciate all of the work you've done to get the Razor pieces working, I'm sure there are a lot of tricky scenarios that the out-of-the-box components don't account for.

[bdukes]

It looks like I spoke too soon. After some more testing, while the precompiled views get registered with the compiler, because of how Statiq is presenting the files those precompiled views aren't getting used. We ended up stripping out a bunch of the dynamic compilation pieces from Statiq.Razor to create a version that relies on there being precompiled views. This also made upgrading to .NET 7 (including v7 of the Razor packages) really simple, and we're now seeing our build times cut in half (7 seconds instead of 15). So, while the code that I posted is a part of the solution, it didn't end up being as simple as just that.

[daveaglick]

we're now seeing our build times cut in half

🤯 that's been one of my persistent headaches - no matter how much I try to optimize the Razor portions, it still takes forever. Glad to hear it went way down once you got precompilation working...perhaps it's time I start reopening the Razor blackbox and revisit how that's all working, probably makes sense with a .NET 6 retarget in the works too.