[Discussion] Razor compiler no longer produces a Views assembly

[captainsafia]

Discussion post for the the change made in .NET 6 Preview 3 to remove two-step compilation from the Razor compiler.

[Mike-E-angelo]

Thank you for making a discussion post. 😁 I wanted to share my appreciation for this decision and for all the work being done to improve this part of the razor development process. It is very much appreciated. 🙏

[stefanloerwald]

I'm very happy to see the Blazor team tackle this big effort early on in the development of .NET 6. Thank you so much!

I would love to read the source code, but searching for the source generator wasn't successful (github's search isn't exactly the best). Could you please point me towards the SG code for razor?

Thanks
Stefan

Side note: I suspect the announcement post contains a minor error saying that the new behavior is to generate a dll called AppName.Views.dll, where it probably should say AppName.dll.

[watfordgnf]

@stefanloerwald it looks like https://github.com/dotnet/sdk/tree/main/src/RazorSdk/SourceGenerators has most of the work to take the language from https://github.com/dotnet/aspnetcore/tree/main/src/Razor/Microsoft.AspNetCore.Razor.Language and tie it into a source generator.

[stefanloerwald]

@stefanloerwald it looks like https://github.com/dotnet/sdk/tree/main/src/RazorSdk/SourceGenerators has most of the work to take the language from https://github.com/dotnet/aspnetcore/tree/main/src/Razor/Microsoft.AspNetCore.Razor.Language and tie it into a source generator.

Thank you so much! I didn't think to look in any of the sister repos.

[theCuriousOne]

Does this also means the hot reload for Razor Views will no longer be available/supported?

[captainsafia]

Side note: I suspect the announcement post contains a minor error saying that the new behavior is to generate a dll called AppName.Views.dll, where it probably should say AppName.dll.

Oof! Yes, it does. Shouldn't have written that post so quickly. Too many typos. 😲

Does this also means the hot reload for Razor Views will no longer be available/supported?

So, hot reload is a new feature that we're shipping in .NET 6 Preview 3, the same release that this feature is being shipped alongside so this doesn't really change anything about the way things used to work (e.g. the "no longer" part) since hot reload is new.

In fact, this work helps enable hot-reload scenarios. The hot reload feature that we are shipping works by communicating deltas of IL code to the running application. The running app then applies those deltas to the app as part of the update. The feature currently only supports communicating deltas for a single assembly for the work we did here was necessary to get things working correctly for hot reload.

@stefanloerwald it looks like https://github.com/dotnet/sdk/tree/main/src/RazorSdk/SourceGenerators has most of the work to take the language from https://github.com/dotnet/aspnetcore/tree/main/src/Razor/Microsoft.AspNetCore.Razor.Language and tie it into a source generator.

@stefanloerwald @watfordgnf Thanks for digging up the code. We lifted and shifted the SDKs from the aspnetcore repo to the sdk repo for .NET 6.

A quick note: you might spot that we leverage static members to do some "caching" in the RSG. This is temporary workaround that we will be replacing with the work outlined dotnet/aspnetcore#31244. Depending on when folks come across this thread, I would recommend using the API mentioned in the issue above for your RSG instead of using the temporary workaround we've employed here.

[pranavkm]

@theCuriousOne to add to @captainsafia's comment - starting in preview3, hot reload will be enabled for MVC apps including Razor views. Our goal is to make is compelling enough to replace runtime compilation with hot reload as the default dev workflow by the end of 6.0. At this point, hot reload for .cshtml files is a little crummy - the code that cshtml generates doesn't play very well with hot reload forcing it do a full rebuild more often than we'd like to and we're looking to tackle it.

[drdamour]

@captainsafia i suspect when @theCuriousOne said razor hot reload, really what was beign asked about is razor runtime compilation. https://docs.microsoft.com/en-us/aspnet/core/mvc/views/view-compilation?view=aspnetcore-5.0&tabs=visual-studio#enable-runtime-compilation-in-an-existing-project is that now deprecated in favour of hot reload?

[theCuriousOne]

@drdamour Thank you. I had no idea it was called differently. I know that in .net framework I used to change a razor page -> save the file -> changes are visible in browser (without the need to rebuild project/solution).

[soundaranbu]

Hi @captainsafia , Good day!
I'm working on a library Razor.Templating.Core which helps to render string out of .cshtml files in all kinds of workloads(Web, Console, Worker Service, etc). This library is already being used in many projects which are in production right now.

For apps that targets SDKs other than Microsoft.NET.Sdk.Web, to load the Application Parts, I used to discover the RCL assemblies using RelatedAssemblyAttribute which was added to the main RCL assembly. This was the only work around for me because ApplicationPartAttribute was not added to the main entry assembly for SDKs that don't target the web sdk.

Now with this change RelatedAssemblyAttribute is no longer getting added to the RCL assemblies which removes the only work around to discover the RCL assemblies and the precompiled view assemblies for non-web sdk.
Reference to affected method: https://github.com/soundaranbu/RazorTemplating/blob/e6ff3dbbbc807e075ce7a1173096e941a7e747b4/src/Razor.Templating.Core/RazorViewToStringRendererFactory.cs#L138-L177

My Request:

• Please add a way to discover the RCL assemblies in non-web projects by adding an attribute that tells that this is RCL assembly
• Or add ApplicationPart attribute to the entry assembly of non-web sdk projects as well
• Or if there's a way already, kindly let me know how.

[chrfin]

@soundaranbu If I get this whole thing correctly there is no *.Views.dll anymore and thus no RelatedAssembly. The views are part of the main DLL in .NET 6 any you do not need to load parts from any other assembly anymore - all are in the main DLL.

[soundaranbu]

@soundaranbu If I get this whole thing correctly there is no *.Views.dll anymore and thus no RelatedAssembly.

This is correct.

The views are part of the main DLL in .NET 6 any you do not need to load parts from any other assembly anymore - all are in the main DLL.

This is also correct only when there are no references to external Razor Class Libraries(RCL)

But my library use case is to support razor templating(.cshtml to string) not just for web application but also out of web apps like console, worker service, azure functions, etc).
The way web applications discover application parts is by looking at the ApplicationPartAttribute in the main dll when you add reference to one or more Razor Class Library projects.

Hence, I need a mechanism to discover the application parts for non web apps as the existing mechanism got removed by this change. Please go over my request again

My Request:

• Please add a way to discover the RCL assemblies in non-web projects by adding an attribute that tells that this is RCL assembly
• Or add ApplicationPart attribute to the entry assembly of non-web sdk projects as well
• Or if there's a way already, kindly let me know how.