.NET 10 and Razor: Please clarify what you mean by "Razor runtime compilation is obsolete"

[PoseidonEnergy]

@BrennanConroy

I read this announcement about Razor runtime compilation now being obsolete: aspnet/Announcements#522

I then noticed in .NET 10, in a basic MVC application with Razor views, if you pass an options delegate to AddRazorRuntimeCompilation() in Program.cs, you will be shown a warning:

mvcBuilder.AddRazorRuntimeCompilation(delegate (MvcRazorRuntimeCompilationOptions options) { });
// ASPDEPR003: Razor runtime compilation is obsolete and is not recommended for production scenarios.
// For production scenarios, use the default build time compilation. For development scenarios, use
// Hot Reload instead. For more information, visit https://aka.ms/aspnet/deprecate/003.

However, when you pass no argument to the method, it does not show a warning:

mvcBuilder.AddRazorRuntimeCompilation(); // no "obsolete" warning here

So, is it just the first overload that's being obsoleted? Or, when you say "Razor runtime compilation is obsolete", does that mean that in the future we MUST use dotnet watch to run our MVC application, and classic Razor runtime compilation is being removed completely?

This is a problem for me, since in my development workflow, I do not want my entire application to get rebuilt every time I make a change to a Razor page. When I am running my application, and I make a change to a Razor page, I only want the Razor subsystem to recompile, not my entire application. I also do not want the web page to reload.

• When I make a change to a .cs file, I don't want anything to happen. I will manually rebuild and restart the localhost server when I am done making changes.
• When I make a change to a .cshtml file, I only want the Razor subsystem to recompile, but only when I manually reload my page in the browser. Right now, with the Razor runtime recompilation, this works great--the Razor subsystem only recompiles my views when application tries to access one of them, for example when I reload the page (like a lazy-recompile).

Lastly, when I develop, I do not run my MVC application using Visual Studio, nor do I use the dotnet CLI. I run a separate instance of IIS Express that points to my application's DLL using a shortcut target:

Target: C:\Windows\System32\cmd.exe /c (set LAUNCHER_PATH=dotnet&&set LAUNCHER_ARGS=.\bin\Release\net10.0\MyProject.dll&&"C:\iisexpress\iisexpress.exe" /path:"C:\projects\example.com\MyProject" /port:8081 /trace:error)

This works great for me, because I can create a little icon on my desktop that runs my development server with a console window, with just a single mouse click. The current Razor runtime compilation feature works well with this setup.

In conclusion, what exactly is being removed from .NET regarding Razor runtime compilation, and will we be forced to use the dotnet watch command in the future if we want anything resembling Razor runtime recompilation? If we are forced to use the dotnet watch command going forward, how can I modify my shortcut target shown above to accommodate that?

[danroth27]

when you pass no argument to the method [AddRazorRuntimeCompilation], it does not show a warning

@BrennanConroy @joperezr Is this an oversight in how we marked the related Razor runtime compilation APIs as obsolete? Do we need to mark all the class members as obsolete as well?

[BrennanConroy]

Ugh, that's annoying. We need to mark the specific extension methods obsolete as well.

[danroth27]

@PoseidonEnergy As announced in aspnet/Announcements#522, the entire Razor runtime compilation feature has been marked as obsolete in .NET 10 with the intent to remove it in a future .NET release. The recommended alternative is to use Hot Reload, which is supported using Visual Studio and using dotnet watch. With Hot Reload, you don't need to rebuild the app with every Razor change. The change part of the app will be applied to the running app while it is still running.

With dotnet watch, changes are applied to the running app using Hot Reload whenever files are changed. With Visual Studio you can control when changes get applied to the applied to the app or apply changes when the file is saved. The page will automatically refresh once the change is applied.

For Hot Reload to work, you do need VS or dotnet watch to handle launching the process. Instead of launching, IIS Express from the command line, we recommend creating a launch profile in launchSettings.json that runs IIS Express. You should be able to then launch the server from VS or using dotnet watch and have Hot Reload work. Please give this setup a try and let us know if it works for you!

[danroth27]

Ugh, that's annoying. We need to mark the specific extension methods obsolete as well.

Ah, ok. @joperezr Let's get a separate issue opened to track marking the obsolete class members as obsolete..

[ChrisVanDijk]

Obsoleting Razor Runtime Compilation is very unfortunate. Many people use it to load Razor views (reports, mail templates etc.) from a database or elsewhere via a custom IFileProvider or from a string.

They want you to use Hot Reload (which in my case finally works without problems for Blazor, 👍for the team!), but that way you can't compile views at runtime.

Another way is to clone the runtime compilation source, remove the obsolete attributes, and hope that there will be no breaking changes in future .NET versions that we cannot fix without cloning the entire runtime.

[PoseidonEnergy]

The closest I could get to my original setup using dotnet watch run in a shortcut target is this:

Target: cmd /c"(set DOTNET_WATCH_SUPPRESS_BROWSER_REFRESH=1)&&(set DOTNET_WATCH_SUPPRESS_LAUNCH_BROWSER=1)&&dotnet watch run --verbose --project "C:\projects\example.com\MyProject\MyProject.csproj""

which uses the following launchSettings.json:

{
  "profiles": {
    "Default": {
      "commandName": "Project",
      "launchBrowser": false,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "dotnetRunMessages": true,
      "distributionName": "",
      "applicationUrl": "http://localhost:8081"
    }
  }
}

This works well for the most part.

However, there are two drawbacks to this compared to my old development setup:

1. I am required to have a launchSettings.json file in the project folder with the port number. I can't specify the port number on the command line (as far as I can tell) like I previously could. Can you guys change the dotnet CLI to not require a launchSettings.json? If there is none found, can't it just use a default development profile, and let me specify the port number on the command line?
2. The command dotnet watch run builds the application as soon as I run it. I would prefer if the application did not get built every time I run that command. Can this be given a command line argument to disable the initial build behavior?

[joperezr]

Ugh, that's annoying. We need to mark the specific extension methods obsolete as well.

Ah, ok. @joperezr Let's get a separate issue opened to track marking the obsolete class members as obsolete..

#64372

[danroth27]

The command dotnet watch run builds the application as soon as I run it. I would prefer if the application did not get built every time I run that command. Can this be given a command line argument to disable the initial build behavior?

Try --no-build.