Removing RazorCompileOnBuild & RazorCompileOnPublish

Questions
1

As per Umbraco documentation and other reports on here, to get the site running we now need to remove these two rows from the csproj file:

<RazorCompileOnBuild>false</RazorCompileOnBuild>
<RazorCompileOnPublish>false</RazorCompileOnPublish>

Fine. That gets the site running.

However, what I have seen happening is that changes to cshtml now do not appear unless you either stop/start your project or use the Hot Reload button in Visual Studio. This didn’t happen in previous editions of Umbraco, 13 and before as I haven’t really played with 14-16 with any anger.

Previous editions of Umbraco had:

image

in the csproj file and we never removed these values even though the comment says to remove it. And changing cshtml on the fly resulted in the change being rendered instantly, no hot reloading buttons required.

So I just need to understand is this a change, having to remove the lines in the csproj, via Umbraco or is this a change because of .NET 10, where any changes in cshtml files need the Hot Reload button to be pressed?

I personally don’t mind it :slight_smile: it’s hardly a big issue, but we have a few front end developers that never touch .cs files and therefore don’t know about hot reloading, and they mostly work in VS Code so I want to get on top of understanding the change so our bosses can be informed and low level developers can be trained.

1 Like
2

The difference is that you are now pre compiling the razor files when building the application. The obvious benefit is that everything gets checked compile time so you don’t run into any issues runtime.

The downside when developging is - as you already found out - that you can’t just update your razor views and see the result. You need to reuse the hot reload button to ‘restart’ the changes and get the view compiled.

The reason for this change is that Umbraco by default no longer supports backoffice editing of the razor views, because that is not possible when precompiling the views. I think precompiling razor views is a good thing and improves quality. In case you do want to be able to edit razor view in the backoffice, you just have to install an Umbraco package (something. Backoffice I think) and then you can disable the pre compilation options again and work with that.

1 Like
3

Umbraco.Cms.DevelopmentMode.Backoffice

but also dotnet watch is also something to investigate, whilst developing

1 Like
4

If a developer is doing their job they test their changes when they make then :smiley: but that’s me being cheeky.

Thank you, and good to know there is a package that could revert us to how we all previously work. Cheers for the understanding :slight_smile:

5

Hmmm actually this has got me thinking:

I would ask a question of Umbraco on this point : not being able to edit razor views in the back office is 100% the best change you can make. People editing templates on live sites have been a bain of my life for many many a year, and I was the worst for editing them :smiley:

But why does this removal of functionality of editing a cshtml in the back office via a code editor mean that all cshtml files need to be compiled? (unless you install another package…)
And why does the site break when those two settings are left in the csproj file?
I might be picking at things here, but U17 is a big change for us (no right clicks is still causing me a hell of a lot of issues and the UI is SUPER slow when connecting to a remote database…) and so we just need to be sure it is 100% the right move for us right now or should we wait until U17.5 and things are more “stable”.

6

Umbraco just being led by MS here…

.NET 10 and Razor: Please clarify what you mean by “Razor runtime compilation is obsolete” · Issue #64338 · dotnet/aspnetcore

So actually Kudos to Umbraco for giving us the package to restore it if wanted.

There were/still are ways and means to allow a competent html editor to use umbraco backoffice to manage templates (without the need to know all the technical ins and outs of local setups and CI/CD deployments, indeed I chose html editor specifically over frontend developer)

An Azure App_Service can be set up to also host a local azure git, so whilst you are away and the client is altering templates, modifications are tracked, and if you return to the project later you can simply merge those modifications and continue on.. I know not as robust as a full best practice n-tier, pr reviewed, ci/cd.. but some simple clients just want that, set me up and point me in the direction but don’t make me into a developer to do some rudimentary html changes in a template :slight_smile:

So I’m not completely on board with template editing shouldn’t be allowed, we could say the same for css/js shouldn’t be editable either in the back-office it should be compiled in the build-process too…

But then we’re ripping out swathes of editability from the back-office, and turning it into the run of the mill cms products that force a certain way of working, that it stands head and shoulders over for having that extensive editability in the backoffice. :slight_smile:

It still remains a draw to me, umbraco having a touch point at all levels, and not the you need enterprise processes to deliver and manage a brochureware spa site, no matter how much it inconveniences the developer. :face_with_peeking_eye:

1 Like
7

I never ever want this :smiley:

Thank you for all the information. Truly super helpful.

1 Like
8

To be clear, this isn’t doing what you think it is…

<RazorCompileOnBuild>false</RazorCompileOnBuild>
<RazorCompileOnPublish>false</RazorCompileOnPublish>

This turns off the default behaviour in ASP.NET Core, which is to compile Razor to DLLs on build and publish. Runtime Compilation itself is enabled as long as the Umbraco.Cms.DevelopmentMode.Backoffice DLL is referenced - so you can totally have both pre-compilation and Runtime Compilation on the same project at the same time .

The purpose of these lines in Umbraco is to turn of pre-compilation because it’s not supported by the in-memory ModelsBuilder - hence the comment.

If you’re not using In Memory models, this can (and should) go as it will save your web server having to compile a new DLL for every razor file the first time it’s requested (and again after every restart!).

This is the big thing. MS are abandoning Runtime Compilation - there are already some Razor features that only work precompiled.

Apart from that, Runtime Compilation is bad for performance - I did some tests on a site late last year and we were seeing about 20% perf improvement simply by not having the dependency on Umbraco.Cms.DevelopmentMode.Backoffice. Basically, it’s constantly reading from disk to check if it needs to recompile, which is non-trivial in Azure Web Apps (and that’s whether or not you have pre-compilation enabled, that behaviour comes simply from loading the DLL :cry:)

dotnet watch should work properly with Runtime Compilation gone, and might fit in better with front-ender’s expectations.

Failing that, there’s nothing to say you can’t modify your csproj to include Umbraco.Cms.DevelopmentMode.Backoffice only in development.

1 Like
9

If we did want to maintain this in another guise… has anyone looked at RazorLight / RazorEngine.NetCore?

Claude rudimentary gave something like… (but could be event driven)

public class TemplateEditorController : UmbracoApiController
{
    [HttpPost]
    public async Task<IActionResult> SaveTemplate(string fileName, string content)
    {
        var path = Path.Combine(_templatePath, fileName);
        await File.WriteAllTextAsync(path, content);
        
        // Invalidate compiled cache
        _razorLightEngine.Handler.Cache.Remove(fileName);
        
        return Ok();
    }
}

which seems to avoid filewatchers, whilst allowing for razorlight recompilation of views/partial/view components in production?

ps hoping dotnet watch plays nicely with large sets of models builder file regeneration (it didn’t previously). :crossed_fingers:

10

One for another thread methinks, at the risk of hijacking this one.

In the case of the scenario described above , where C# files aren’t being touched - this shouldn’t be a problem.

11

Thank you for response Jason. Lot’s of great information :slight_smile:

I have always thought it stopped .NET (core and standard)/Visual Studio compiling the razor files on Build/Publish so that we wouldn’t get errors in partials that were legacy or errors from some terrible html/cshtml :smiley:

We never removed them in any site that I can see them in, and we never use InMemory so that’s why I am today confused that we need to explicitly remove the two rows from the csproj file. To me that says there is now 3 values for each entry : true, false and null - a null value or the non existence of a value should be the same as false when you have a boolean, imho.

However this is a very interesting point and something I will test with some of our newer sites which we use swap slots with (although they all start very fast but we use swap slots due to issues with Examine files locking…).

But again I would ask, when these rows are set to false, why is that any different to not being in the csproj file? If their non existence in the file means that a new DLL is not created o start up, then surely being set to false ie “do not compile”, should that not result in the same behaviour? But as you rightly said, I may not be understanding what they are actually doing :smiley:

12

Well TBF, that’s kind of the same thing. Models using InMemory models can’t compile, and neither could some early netcore packages :grimacing: - before everyone saw the light and moved to Razor Class Libraries.

They default to true (and always have done in .NET Core). So Umbraco needs to explicitly set them to false and include a reference to Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation (which it does in Umbraco.Cms.DevelopmentMode.Backoffice, as well as turning it on) for the OOTB install which uses In-Memory models.