[Breaking change]: Removal of `BackOfficeDevelopment` runtime mode and `InModelsBuilder` models builder mode due to deprecation of Razor runtime compilation support in .NET

[AndyButland]

Description

Microsoft have released an announcement notifying that Razor run-time compilation is obsolete. They call out that "Razor run-time compilation doesn't get support for new features and should no longer be used" and that it is "not recommended for production scenarios".

The focus for scenarios supported by this feature is on hot reload.

As the feature is now obsolete, we have to anticipate that it will be removed in a future major release of .NET, which at the earliest will be .NET 11 that will align with Umbraco 19.

Features in Umbraco that rely on this are the BackOfficeDevelopment runtime mode template editor and the in-memory models builder mode.

We expect to remove these features from Umbraco as of Umbraco 19, as they will no longer be supported by the underlying .NET framework.

Version

Umbraco 19+

Previous behavior

The InMemoryAuto models builder mode and the BackofficeDevelopment runtime mode are available.

New behavior

The InMemoryAuto models builder mode and the BackofficeDevelopment runtime mode will not be available Backoffice editing of templates will only be available in development environments where dotnet watch is being used.

Type of breaking change

• Binary incompatible: Existing binaries may encounter a breaking change in behavior, such as failure to load/execute or different run-time behavior.
• Source incompatible: Source code may encounter a breaking change in behavior when targeting the new runtime/component/SDK, such as compile errors or different run-time behavior.

Reason for change

This change is necessary to follow developments in the underlying .NET platform and ensuring Umbraco can continue to run on the latest as we move forward.

Recommended action

We recommend editing template files as .cshtml views via the source code editor of your choice and publishing them along with the rest of the Umbraco project into the hosting environment. Using dotnet watch in a local development environment will allow use of hot reload.

When using Models Builder it will be necessary to use one of the other modes that involve generating models as source code files and compiling them along with the Umbraco project.

[KevinJump]

The current behavior that the template editor gives is the creation of the template as a database entry, which is then used in content types and content to identify the template to be used by a page.

Would this be a suitable time to also remove this and migrate to the template name being stored against content types and content so there is no database entry required for templates?

[skttl]

The current behavior that the template editor gives is the creation of the template as a database entry, which is then used in content types and content to identify the template to be used by a page.

Would this be a suitable time to also remove this and migrate to the template name being stored against content types and content so there is no database entry required for templates?

Would be awesome if this could make it possible to organize templates into folders eg. Views/Site1/Frontpage.cshtml.

[OwainJ]

The current behavior that the template editor gives is the creation of the template as a database entry, which is then used in content types and content to identify the template to be used by a page.
Would this be a suitable time to also remove this and migrate to the template name being stored against content types and content so there is no database entry required for templates?

Would be awesome if this could make it possible to organize templates into folders eg. Views/Site1/Frontpage.cshtml.

+1 from me for both of these suggestions!

[nul800sebastiaan]

As far as I know there is no real need these days to have the templates in the database, I think they only really store an alias that is then never used. So agreed with all of the above as well!

Additionally, we have an ugly remnant still lingering around from good old ASP.NET Masterpages and that is that we keep referring to a "Master" template.

This has not been a "thing" in ASP.NET MVC for like a decade, this needs to refer to a Layout instead.

Anyway, just wanted to note that, keeps popping into my head every now and then and I keep forgetting to write it down.

Ps. I really hope that MS changes their mind and we can still keep some kind of run-time compilation around, this will impact a lot of people in the Umbraco eco-system and just make things harder than they need to be for first-timers 😢

[rsnpettrov]

The current behavior that the template editor gives is the creation of the template as a database entry, which is then used in content types and content to identify the template to be used by a page.
Would this be a suitable time to also remove this and migrate to the template name being stored against content types and content so there is no database entry required for templates?

Would be awesome if this could make it possible to organize templates into folders eg. Views/Site1/Frontpage.cshtml.

And probably not only in Views. In a multisite project, we decided to group all files for each Page and Component together — including .cs, .cshtml, .js, and .scss. Since it's not just views anymore, we moved them out of the Views folder and used this structure:

/Sites
├─ /SiteA
│ ├─ /Components
│ │ └─ /ComponentA (cshtml, cs, js, scss, etc.)
│ └─ /Pages
│ └─ /PageA (cshtml, cs, js, scss, etc.)
└─ /SiteB
├─ /Components
└─ /Pages

I’ve always been bothered that Umbraco doesn’t recognize templates in the Backoffice when you place them outside the default location.

Overall, I like having everything grouped together, but this setup required several customizations — mainly custom view path handling and multi-site extensions for site resolution — which added unnecessary complexity. I might give up on it for that reason.

I know this comment is a bit out of context, but I wanted to share it since people started discussing this — maybe it adds some value 😄