Net Core 6 Blazor Server Hot Reload is Slow for Big Projects

[lucianparvu]

Hi,

I have a project Blazor Server with ~ 180 .razor Files (186 Files, 55 Folder)

If all folder structure is in the same project the hot reload takes ~ 15 seconds , more than build time ( 10 seconds ) .

If we split the .razor files on Libraries , we get the next Results

Main App (Only Host.razor) : (Reference to Shared Library, Front Library,Admin Library )
– Hot Reload for all tests after 1 seconds

Shared Library (21 Files, 1 Folder) : Layout, Shared Components, etc
– Add p: Hot Reload after 2-3 seconds
– Add style to p : Hot Reload after after 2-3 seconds
– Counter Example with ++ : Hot Reload after 1 seconds

Front Library (54 Files, 15 Folders) (Reference to Shared Library)
– Add p: Hot Reload after 20 seconds
– Add style to p : Hot Reload after after 4 seconds
– Counter Example with ++ : Hot Reload after 3 seconds

Admin Library (106 Files, 36 Folders) (Reference to Shared Library)
– Add p: Hot Reload after 12 seconds
– Add style to p : Hot Reload after after 8 seconds
– Counter Example with ++ : Hot Reload after 8 seconds

I am suspecting maybe we have something from old Projects because we have upgraded from 2.2 to 3.1 ( Blazor ) to 5,etc

We have tried to remove html from Some razor Files specially Layout and seems to work quickly if there is just some simple html lines.

How can we improve ? It depends on File nr and complexity ? or depends on references ? How can we structure the project ?

PS: The issue is posted based on disscussion : https://devblogs.microsoft.com/aspnet/asp-net-core-updates-in-net-6-preview-3/comment-page-3/#comment-3245

[pranavkm]

I am suspecting maybe we have something from old Projects because we have upgraded from 2.2 to 3.1 ( Blazor ) to 5,etc

To confirm, is the project you’re running a .NET 6 preview project?

[lucianparvu]

Yes, right now I have installed Visual Studio Preview and Net Core 6 Preview.

Please find the Project Description

 
<Project Sdk="Microsoft.NET.Sdk.Web">		 
	<PropertyGroup> 	 	 
	 <TargetFramework>net6.0</TargetFramework> 		 
		<ServerGarbageCollection>false</ServerGarbageCollection> 			
	</PropertyGroup>		
	<ItemGroup>	 
		<PackageReference Include="AspNet.Security.OAuth.Apple" Version="5.0.4" /> 		 
		<PackageReference Include="Microsoft.AspNetCore.Authentication.Google" Version="6.0.0-preview.3.*" />
		<PackageReference Include="Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore" Version="6.0.0-preview.3.*" />
		<PackageReference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore" Version="6.0.0-preview.3.*" />
		<PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation" Version="6.0.0-preview.3.*" />
		<PackageReference Include="Microsoft.AspNetCore.Identity.UI" Version="6.0.0-preview.3.*" />
		<PackageReference Include="Microsoft.AspNetCore.SignalR.Client" Version="6.0.0-preview.3.*" />
		<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="6.0.0-preview.3.*" />
		<PackageReference Include="Microsoft.AspNetCore.Authentication.Facebook" Version="6.0.0-preview.3.*" />
		<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="6.0.0-preview.3.*">
			<PrivateAssets>all</PrivateAssets>
			<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
		</PackageReference>
		<PackageReference Include="BlazorDateRangePicker" Version="3.5.0" />
		<PackageReference Include="Blazored.LocalStorage" Version="3.0.0" />
		<PackageReference Include="Blazored.SessionStorage" Version="1.0.13" />
		<PackageReference Include="BlazorInputFile" Version="0.2.0" />
		<PackageReference Include="Bower" Version="1.3.11" />
		<PackageReference Include="ChartJs.Blazor" Version="1.1.0" />
		<PackageReference Include="EPPlus" Version="5.6.2" />	
		<PackageReference Include="Microsoft.AspNetCore.Http.Abstractions" Version="2.2.0" />	
		<PackageReference Include="Microsoft.AspNetCore.WebUtilities" Version="2.2.0" />
		<PackageReference Include="Hangfire" Version="1.7.22" />
		<PackageReference Include="MailKit" Version="2.11.1" />	 
		<PackageReference Include="SixLabors.ImageSharp" Version="1.0.3" />
	</ItemGroup>
	<ItemGroup>
	  <ProjectReference Include="..\BLL\BLL.csproj" />
	  <ProjectReference Include="..\DAL\DAL.csproj" />
	  <ProjectReference Include="..\SL\SL.csproj" />
	</ItemGroup>
	<ItemGroup>
	  <None Update="AuthKey_9G5GG557T4.p8">
	    <CopyToOutputDirectory>Always</CopyToOutputDirectory>
	  </None>
	</ItemGroup>
	<ProjectExtensions><VisualStudio><UserProperties wwwroot_4lib_4bootstrap_4dist_4css_4bootstrap_1min_1css_1map__JsonSchema="" /></VisualStudio></ProjectExtensions>
</Project> 

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[oiBio]

I also can confirm this.
i just tested hotreload on our large project (~ 180 *.razor files) and a simple change also needs about 10-15 seconds.
i did not look any futher into this, we are waiting for a better user experiance on visual studio (dotnet watch run is meh)

we also migrated the project from the first blazor preview to net6

[lucianparvu]

:) Maybe Microsoft team can do something, we need to use it in development until Net 6 ships .

[pranavkm]

Thanks for the issue report. Right now, the source generator for Razor has a stop-gap caching solution in place which works poorly in large apps. That's cause hot reload to perform more work than necessary resulting in the poor performance.

We think some new compiler features that we plan to use by 6.0-preview6 as well as some tactical perf improvements we're also landing in the same release should improve things.

That said, in my demo app with about 200 files, I was seeing ~1 second update times. The time is primarily influenced by the time taken to parse Razor code, so it's entirely possible that 10-15 second delays you are seeing is result of a more sophisticated app. But if you're willing to share you app, I could make sure that's the root cause here and not something more nefarious. A GitHub repo works great, but if are willing to share your apps privately, we can work out something for that too.

[lucianparvu]

Yes, after more tests it depends more on razor complexity . Maybe we can refactor, but we need to know what thinks we should refactor .

We can give access to a virtual machine with Visual Studio in Azure Cloud in private. How can i contact you in private ? My Email Address: [email protected] ( Works on Teams too for chat ).

[pranavkm]

We can give access to a virtual machine with Visual Studio in Azure Cloud in private

It might be a bit tricky to do work on a VM without my tools installed. That said, we've started work on the compiler feature that should speed things up here and expect to be done with it in our preview6 release. How about we have you try it out as soon that's checked in? We'd be happy to investigate further if you continue seeing slow results with that change.

FYI @captainsafia

[lucianparvu]

Thank's it is ok .

[pranavkm]

Verified this using RC1 bits. For a an app with about 500+ razor files (https://github.com/pranavkm/LargeRazorApp), here's what we get:

• The first edit is about as expensive as a cold start build
• Consecutive edits take about 600ms each and most of that is spent in the compiler / producing the deltas etc. We think that's a good place to be for 6.0.

Raw numbers

Cold start build:

> dotnet build --no-restore
Time Elapsed 00:00:06.71

First edit

watch : File changed: D:\temp\watchapps\LargeRazorApp\Pages\Index.razor. 
watch : Received successful apply from delta applier.
watch : Hot reload of changes succeeded.
watch : Hot reload change handled in 5583.391ms.

Consequent edits:

watch : File changed: D:\temp\watchapps\LargeRazorApp\Pages\Index.razor.
watch : Received successful apply from delta applier.
watch : Hot reload of changes succeeded.
watch : Hot reload change handled in 628.0315ms.

watch : File changed: D:\temp\watchapps\LargeRazorApp\Pages\Counter.razor.
watch : Received successful apply from delta applier.
watch : Hot reload of changes succeeded.
watch : Hot reload change handled in 525.4524ms.

watch : File changed: D:\temp\watchapps\LargeRazorApp\Pages\Index.razor.
watch : Received successful apply from delta applier.
watch : Hot reload of changes succeeded.
watch : Hot reload change handled in 516.9593ms.

@lucianparvu feel free to give hot reload a try using a preview7 or rc1 SDK (https://github.com/dotnet/installer#installers-and-binaries) and let me know if the experience is any better.

[0ptim]

I'm experiencing the same as other people described. In VS 2022 the changes take very long until applied.

▶️ Using dotnet watch run from console improves performance by large.

Would love to use Hot Reload with VS 2022!

Congrats on the .net 6 release! 🎉

[ghost]

For us the same with a large project. When will this be fixed? Thanks.

[CommonLoon102]

Same issue like for the others (large Blazor-Server project). Thanks a lot for the dotnet watch trick! This way Hot Reload is usable.

[DamianEdwards]

Thanks folks, I think we have a repro now (@pranavkm correct me if I'm wrong). We'll update this thread with more details when we have them.

[lucianparvu]

@pranavkm I can't see improvements too , It seems to be same results like in RC1, RC2 in my project.

In my case Visual Studio 2022 build the project in 14 seconds and Visual Studio 2019 in 10 Seconds .

Another Question : Hot Reload will work for Isolated CSS ? I have tested but is not working and needs build .

[CommonLoon102]

Another Question : Hot Reload will work for Isolated CSS ? I have tested but is not working and needs build .

Static CSS (in wwwroot/css) updates as you type. Scoped CSS works on save or hot reload and updates instantly. Except on Windows 7, there it needs a rebuild.

[burtonrodman]

was hoping to replace Razor Runtime Compilation with Hot Reload (because of all the compile warnings about CodeAnalysis version mismatches). i generally use vscode but couldn't get dotnet watch working there quickly. The rest of my team uses Visual Studio, so thought maybe I would just switch.

after updating to VS 2022 17.0.2, Hot Reload works, but I'm seeing 25 - 60 seconds on a Surface Laptop 3 i7/16GB in a Razor Pages project with 279 .cshtml files.

if it would be helpful to submit my project, I can work with my client to get authorization.

[lucianparvu]

@pranavkm do we have any news on this ? When we should see improvements ?

[Mike-E-angelo]

Right now with 17.1.1 preview I am seeing a 40-60 second compile-time on my project for the simplest of changes. This is before hot reload gets involved. So, it would seem that the current Razor build system really struggles with larger projects in general. 😞

[lucianparvu]

Right now with 17.1.1 preview I am seeing a 40-60 second compile-time on my project for the simplest of changes. This is before hot reload gets involved. So, it would seem that the current Razor build system really struggles with larger projects in general. 😞

In my case, i have hot reload after ~ 40 - 1.5 min seconds on every .razor file, everything else ( css, pure C# files ) takes ~1-2 seconds

[Contengo]

Same here - it's actually significantly quicker to stop, edit and run again than to use hot reload, which means we're back where we started. Sigh.

[pranavkm]

For the folks pinging about hot reload being slow in VS, we have a candidate fix available that we will be making available as part of 17.2-previews / 6.0.300 version of .NET SDK. I'll post on this thread again once the SDK changes are in and available as part of a Visual Studio preview release.

@lucianparvu unfortunately we haven't quite gotten to the bottom of the slowness you experienced with dotnet-watch. If you do continue seeing it with VS, it'd great if you could file a VS feedback issue. Feedback issues capture additional diagnostics that should help us narrow down any issues in the source generator / razor compiler that contribute to the slowness.

[KonnectSalon]

Is there any workaround for this?
The Edit and Continue in vs2017 works 100% fine and then we release vs2022 with a 5 hour video telling us how Hot Reload (Edit and Continue) will save the day but it really just makes everything I do now less productive. I cannot even make a small HTML change in a cshtml file without waiting 5 minutes or having to stop and reload. And on that matter only being able to stop once VS2022 says that's OK cause it keeps popping up an error.

With respect, is there any workaround? I can't really wait until 17.2-previews that's just crazy.

[lucianparvu]

@pranavkm

@lucianparvu unfortunately we haven't quite gotten to the bottom of the slowness you experienced with dotnet-watch. If you do continue seeing it with VS, it'd great if you could file a VS feedback issue. Feedback issues capture additional diagnostics that should help us narrow down any issues in the source generator / razor compiler that contribute to the slowness.

I have submitted a VS Feedback with VS record: https://developercommunity2.visualstudio.com/t/Blazor-Net-Core-6-Slow-for-big-Projects/1645384?entry=problem&ref=native&refTime=1643014712342&refUserId=bc8b0145-3228-6f54-b025-ab2ae9ec254a

[Mike-E-angelo]

In my case, Hot Reload still does not work for my solution, using 17.1 Preview 3. I will make an edit and after many many minutes have passed, no edits are observed.

Additionally, when attempting to exit debugging mode, I am met with this dialog:
https://developercommunity.visualstudio.com/t/Unable-to-Stop-Debugging-Code-0x80004005/1580495

Further attempting to close the IDE directly results in the following message:

Following the directions do not work and I am still met with the 0x80004005 exception above.

As I can no longer exit out of debug mode due to this exception dialog, I am now forced to close the IDE from Task Manager.

Not only does this feature still not seem to work, but it also appears to have gotten worse, as before I was able to exit debug mode after several seconds when encountering this exception. Now, it is stuck and I have no choice but to use Task Manager to regain control of my environment.

Any consideration towards addressing this would be greatly appreciated.

[pranavkm]

@KonnectSalon I'm sorry you're having a bad experience with this. There's an option to disable hot reload and keep using EnC until a fix is made available.

@Mike-E-angelo using the VS feedback tool would be the best way to go since your issue sounds specific to the VS debugger.

While I appreciate your continued feedback, they would be much more actionable either as VS feedback issues if they are VS / debugger specific, or as separate issues for us to better track them. I'm going to close this issue for further discussion and post an update to it once a build of VS that resolves the slowness becomes available.

[danroth27]

Ongoing work to address this issue is tracked by dotnet/razor#7626