Mvc: Runtime compilation for Razor Pages code-behind

[Code-DJ]

Is there an option to enable runtime-compilation for .cshtml.cs files instead of requiring a pre-compile.

Back-drop: In the webforms WebSite project, you could deploy both .aspx and .aspx.cs to the server without requiring pre-compilation. This meant that there was no need to deploy DLL to the bin folder when you only made changes to your .aspx.cs files during dev. Having to deploy DLLs caused a couple of seconds freeze of the app. If you deploy multiple files during the day, it could cause constant freezes of the entire application instead of just that one file.

While I like the compilation/test steps during development for .cshtml.cs files. I wanted to see if there was a way to avoid pre-compilation for deployment. It's not a big deal, just wanted to find out if there was an option. Thanks!

If it's a bad idea, may be someone can suggest alternatives. I don't have a large enough app using Razor Pages to know if the freezes problem exists here.

[hishamco]

IMHO I frequently used dotnet watch command in the RazorPages projects in DEVELOPEMENT, to accelerate the compilation process, but when I switch to PRODUCTION I prefer to use the pre-compilation, because this will improve the performance

[Bartmax]

@Code-DJ : try to set MvcRazorCompileOnPublish to false on csproj, remove all dlls, from folder and publish. I'm pretty sure that precompilation is optional.

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <MvcRazorCompileOnPublish>false</MvcRazorCompileOnPublish>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
  </ItemGroup>

</Project>

[Code-DJ]

Hi @Bartmax, just tried it. Looks like that MvcRazorCompileOnPublish only controls .cshtml files and not .cshtml.cs. By setting it to true, you don't need to deploy any .cshtml or .cshtml.cs files to the server vs. setting to false you still/only need to deploy .cshtml files.

[Bartmax]

I don't think you can do runtime compilation of .cs files right now. Only for cshtml files.

[davidfowl]

That's correct, there's no runtime compilation of .cs files.

[Code-DJ]

@davidfowl not sure how this works. Should I leave this issue open as a feature request or should I close it? Thanks!

[davidfowl]

We're not going to be adding runtime compilation for C# files.

[Code-DJ]

Follow-up question that I think is related so just reopened this issue:

If I have 5 DLLs for aspnet core and make a change to one of those, is there a writeup or a blog that explains what happens behind the scenes? Does the aspnet core engine only load the new DLL in memory?

Is the new model any different than the way the Full FX does it?

My larger concern with pre-compiled vs runtime-compiled is that if we make deployments of a large project say 1000 razor pages+1000 page models, with pre-compiled, I will simply have to upload the DLLs, what kind of impact will it have on users that are currently using the website.

I am trying to understand both the behind the scenes process as well as gauge the impact on end-user experience.

[davidfowl]

If I have 5 DLLs for aspnet core and make a change to one of those, is there a writeup or a blog that explains what happens behind the scenes? Does the aspnet core engine only load the new DLL in memory?

There's no write up. By default during development, Razor Pages and MVC views are compiled at runtime using roslyn and loaded in memory. Everything else is compiled at design time using MSBuild in the IDE or from the command line when you run dotnet build/run. In .NET Core 2.0 those razor files are all compiled into a single dll at publish time.

Is the new model any different than the way the Full FX does it?

FullFx is overloaded. Do you mean Razor? It's very similar but full framework puts the files on disk (though that's mostly transparent). If you're asking about ASPX, there were 2 different models (remember App_Code?), one that used msbuild and one that ASP.NET to build everything (Web Site projects).

My larger concern with pre-compiled vs runtime-compiled is that if we make deployments of a large project say 1000 razor pages+1000 page models, with pre-compiled, I will simply have to upload the DLLs, what kind of impact will it have on users that are currently using the website.

I am trying to understand both the behind the scenes process as well as gauge the impact on end-user experience.

There's no model for deploying "sources", this isn't like PHP or asp classic. Once you have .cs files, you need to do a full build to get a .dll. Now for the individual views, you can xcopy deploy but sticking all of your logic into views to make deployment easier should be a non goal. C# is a compiled language

[KieranFoot]

Once it is possible to unload Assemblies/Types in DotNet Core 3.0, will you then support runtime compilation of the code behind Razor pages (.cshtml.cs files)?

Sorry to comment on an old thread, just thought it appropriate in this case with the planned feature.

[davidfowl]

What are cshtml.cs files?

[KieranFoot]

@davidfowl I'm refering to the C# code file behind a razor page.

I currently have a virtual filesystem as part of a CMS that is an IFileProvider serving files from a database.
When MVC loads a Razor page, it makes no attempt to compile the code behind it, it just expects it to be their, already compiled.

As I said, I don't think the issue can be resolved until DotNet Core 3.0, due to the lack of Assembly/Type unloading support. After 3.0, there is no reason not to support this.

[davidfowl]

No we’re not doing that and have no plans to in 3.0

[KieranFoot]

You ARE adding the ability to unload Assemblies/Types, which would allow this to be done. Weather this persons issue is on the roadmap for 3.0 or not, it could be done after 3.0.

It seems a shame for this not to be supported, not sure I understand why it's a flat out "No we're not doing this."... Guess people will just implement it themselves.
It's not that hard, I have it working already, but I leak memory as the CoreCLR can't unload my Assemblies/Types.

[davidfowl]

You ARE adding the ability to unload Assemblies/Types, which would allow this to be done.

Yes it would allow us to not reboot the process, that's a tiny percentage of the work. Making the end to end experience fast even with that requires more changes. I'm speaking from experience here as we've attempted this a number of times in the past. Also we only really care about this for development scenarios not for production. It seems like you specifically want this for production scenarios (your CMS scenario). That unloading feature is very useful but may not be a deal breaker as you can just reboot the app after hitting a threshold.

Weather this persons issue is on the roadmap for 3.0 or not, it could be done after 3.0.

Sure its not on the roadmap for 3.0 or post 3.0.

It seems a shame for this not to be supported, not sure I understand why it's a flat out "No we're not doing this."... Guess people will just implement it themselves.
It's not that hard, I have it working already, but I leak memory as the CoreCLR can't unload my Assemblies/Types.

You should open source what you currently have and see if you can build up a community around it. More efforts like these are good for the ecosystem at large and you may find a community of passionate people that need the same thing.