aspnetcore: Hot Reload nearly always fails, with Blazor WebAssembly and "dotnet watch"

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

Please get Hot Reload to work reliably and consistently with Blazor WebAssembly, especially with changes to .razor files. This feature seems so buggy when it should “just work”. It seems to work much better with non-Blazor server-side changes, e.g. to a Web API, but that’s not where much productivity benefit would result.

When using dotnet watch on my Server project, with verbose logging , I get watch : Hot reload capabilities: . (not even Baseline) and, on a change, No hot reload changes to apply. (when there are). This is with .NET 7.0.0 and SDK 7.0.100 on a solution that was created with .NET 6 and recently upgraded to 7.

Starting...
dotnet watch 🔥 Hot reload capabilities: .
dotnet watch ⌚ File changed: .\MySoln\Client\Shared\MainLayout.razor.
dotnet watch ⌚ No deltas modified. Applying changes to clear diagnostics.
dotnet watch ⌚ Received 1 from browser in [Count: 1, MessageType: Binary, EndOfMessage: True].
dotnet watch ⌚ No hot reload changes to apply.
dotnet watch 🔥 Hot reload change handled in 4092.6926ms.

When running from VS (with or without debugging), I get similar output: image, or sometimes instead “Your debugged process might be corrupted and restarting it is recommended nearly always.”

The most relevant issue seems to be https://github.com/dotnet/aspnetcore/issues/40587, but there must be much more to that one that isn’t working right.

See also:

Seems like there are a lot of others struggling too but not commenting in GitHub issues, e.g.

Expected Behavior

  • dotnet watch hot reload should just work. I don’t want to see “No hot reload changes to apply.”
  • If it isn’t working and thus I get “watch : Hot reload capabilities: .”, I’d like to see output that tells me why in the verbose output (indeed, perhaps even in warnings).

.NET Version

7.0.0

Anything else?

dotnet --info

.NET SDK: Version: 7.0.100 Commit: e12b7af219

Runtime Environment: OS Name: Windows OS Version: 10.0.19044 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\7.0.100\

Host: Version: 7.0.0 Architecture: x64 Commit: d099f075e4

.NET SDKs installed: 5.0.408 [C:\Program Files\dotnet\sdk] 6.0.403 [C:\Program Files\dotnet\sdk] 7.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 7.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.NETCore.App 7.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 3.1.25 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 6.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 6.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] Microsoft.WindowsDesktop.App 7.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found: x86 [C:\Program Files (x86)\dotnet] registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables: Not set

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 29
  • Comments: 53 (17 by maintainers)

Most upvoted comments

Hot Reload is just terrible.

I feel bad criticising any of this because in the end it’s a ‘free’ framework that most of us haven’t helped to develop, but…

There is absolutely no point in allowing and/or promoting the existence of hot reload in its current state. It is rubbish, useless, pointless. Every little change (and sometimes no change at all) requires a rebuild. It isn’t ‘hot reload’ AT ALL.

We have been working with Blazor for three years now, but are seriously contemplating switching everything to React solely because of this issue. The development experience is beyond painful - it would be better to switch the feature off and set the expectation that you always have to recompile. It’s the “waiting to see if it works, knowing it probably won’t” that kills all motivation and enthusiasm.

Thanks for investigating…I must say, I think this should be targeted for a more urgent fix release for .NET 7, as it was supposed to be working in .NET 6.

Seems like there are a lot of others struggling too but not commenting in GitHub issues, e.g.

I’ll add these to the original issue.

Also, the top autocompletion suggestions at Google.com reflects what people are searching on. I’m sure you could get similar stats internally from Bing, but this tells me it is a great many people, not just a few dozen, who are having this issue. image image image

@lonix1 I believe @marek-safar is referring to work we have done for .NET 8 that enables more hot reload capabilities for Blazor WebAssembly apps so that they are on par with what CoreCLR supports. This means that some cases that previously required a rebuild should now work with hot reload. However, this work doesn’t address cases where hot reload fails due to unknown errors or doesn’t recognize that a change needs to be applied. These later cases are bugs that we expect to patch as soon as we can track down and address the underlying issues.

For me is always No hot reload changes to apply 😦

Should we make a separate issue about Blazor server projects having problems with “dotnet watch run”? The problem that @szalapski reported is remarkably like what we see when we use “dotnet watch” with blazor server.

@dragnilar I think we can track both the Blazor WebAssembly and Blazor Server hot reload isseus with dotnet watch here. They do appear to be similar and the release vehicle for the fix would be the same. @tmat @phil-allen-msft Chime in if you prefer otherwise.

I am throwing my hat in the ring. This problem has been plaguing me for months. Blazor WASM .NET7 in VS 20222 Version 17.5.3. Often getting the “No hot reload changes to apply.”. The problem happens both in dotnet watch and using VS.

I can’t get hot reload to work with the base Blazor WASM .NET 7 project in VS…

@jmleep This issue is specifically tracking hot reload issues with Blazor WebAssembly and dotnet watch. If you’re hitting issues in VS please create VS feedback ticket using the Report a Problem feature and we’ll take a look. Reporting VS problems from within VS is helpful because a bunch of relevant logs and diagnostic info get automatically captured.

Not just Blazor, I have a pretty vanilla project (.NET 7, Razor Pages) where either this issue occurs: Stack Overflow: Razor Runtime Compilation breaks Hot Reload and therefore debugging in ASP.NET, or hitting Alt+F10 (i.e. Hot Reload) while debugging simply states “No changes were detected” after editing .cshtml files.

Same here with .NET6 Blazor Server. It works randomly.

it was not fixed. I wish someone would have tested it with the provided example before deeming it “likely fixed”. The test is very easy.

Here’s the minimal example, the same one that was provided in https://github.com/dotnet/aspnetcore/issues/45519, now upgraded to use SDK 7.0.302

szalapski/HotReloadIssue45519Demo

Clone this and run

dotnet watch --verbose --project ./TradeCars/Server

The site should start up. You’ll see Hot reload capabilities: . which portends the failure. Edit anything in Index.razor to watch hot reload fail.

As requested, I have piggybacked on the same issue in 7.0.302 at #47836

When will 7.0.3xx SDK be released?

Likely fixed by https://github.com/dotnet/sdk/pull/31015. Please file a new issue if the problem persists in .NET 7.0.3xx

We landed another wave of Hot Reload improvements in .NET 8 P1 that ships with Visual Studio 2022 v17.6 Preview 2. It’d be great to hear if you still experience recompilation instead of hot-reloads in this version.

That error dialog is not my screenshot.

Whoops, my bad. Fixed in my comment.

If you add a new property it’s gonna need to recompile.

Hmm ok. So under what scenarios should Hot Reload works on Razor Web Assembly?

@dodyg @Stuart88 With Blazor WebAssembly the runtime is much more limited with it’s hot reload capabilities. It can basically only do method body replacement for a limited set of cases. We are working on expanding the set of edits supported, which is tracked here: https://github.com/dotnet/runtime/issues/57365. You can look at the tracking issue to get an idea of what is current supported and what we’re working on adding.

Even so the VS error dialog @dodyg is seeing looks wrong. It says there is a compilation error when there isn’t one being reported in the output window. If you make an edit that isn’t supported by hot reload and you need to rebuild then it should show a different dialog saying precisely that. @Stuart88 Could you please create a VS feedback ticket for that error using the Report a Problem tool in VS? We should investigate what’s going on there. It would be great if you could see if the same error dialog is shown with the 17.6 previews.

I can’t get hot reload to work with the base Blazor WASM .NET 7 project in VS…

We are also having this problem with a Blazor Server project, like @pixelpandaIO.

The problem started with .NET 6 and it persists with .NET 7.

I did a few quick tests with 7.0.101 and VS 17.4.3:

  • .NET 6 + Blazor WebAssembly hosted + dotnet watch => ✅ Work
  • .NET 7 + Blazor WebAssembly standalone + dotnet watch => ✅ Works
  • .NET 7 + Blazor WebAssembly hosted + Visual Studio => ✅ Works
  • .NET 7 + Blazor WebAssembly hosted + dotnet watch => ❌ Broken ☹️
dotnet watch ⌚ File changed: C:\Users\user\Desktop\BlazorApp\Client\Pages\Index.razor.
dotnet watch ⌚ No hot reload changes to apply.

This is being investigated.

@tmat given the repro is provided, I’m assigning this to you to investigate. Thanks!

@MackinnonBuck , here’s the minimal example as requested.

https://github.com/szalapski/HotReloadIssue45519Demo

Clone this and run

dotnet watch --verbose --project ./TradeCars/Server

The site should start up. You’ll see Hot reload capabilities: . which portends the failure. Edit anything in Index.razor to watch hot reload fail.

@danroth27 Yes, but I just tried it again to be sure. Deleted bin and obj in all three projects (Server, Client, Shared), and ran dotnet watch --project on the server project. No change:

Starting...
dotnet watch 🔥 Hot reload capabilities: .
dotnet watch ⌚ File changed: .\MySoln\Client\Shared\MainLayout.razor.
dotnet watch ⌚ No deltas modified. Applying changes to clear diagnostics.
dotnet watch ⌚ Received 1 from browser in [Count: 1, MessageType: Binary, EndOfMessage: True].
dotnet watch ⌚ No hot reload changes to apply.
dotnet watch 🔥 Hot reload change handled in 4092.6926ms.

@MackinnonBuck, I’ll try to get a example project up ASAP.

8.0.100-preview.3.23178.3 also has the fix.

For me, hot reloading works for a very simple new Blazor Server project out of the box, but does not work on the much larger, more complex, real-world project that I worked on.

I tried so many things to try to get hot reloading to work, and what finally allowed it to work was installing version 4.5.0 of the Microsoft.CodeAnalysis.Common Nuget package. Something my project had referenced was implicitly installing version 4.4.0 of this package, and I guess for some reason, that one doesn’t work with hot reloading (?). I hope this helps someone else who might have the same problem.

(I’m using .NET version 7.0.201 by the way)


I almost forgot, this seems to be important too. My launchSettings.json looks like this:

I found that I had to have "launchBrowser": true in order for hot reloading to work, even though I would prefer not to have it launch:

{
  "profiles": {
    "http": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "applicationUrl": "https://localhost:5000",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "Watch": {
      "commandName": "Executable",
      "executablePath": "dotnet",
      "commandLineArgs": "watch",
      "workingDirectory": "$(ProjectDir)",
      "applicationUrl": "https://localhost:5000",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

EDIT: So here I am 5 days later on 3/8/2023, and hot reloading no longer works for me, even with this “fix”. At best it is inconsistent I guess. It is very frustrating not knowing what causes it not to work 😞

FYI to all experiencing this trouble, if I do --no-hot-reload on my dotnet watch command line, at least I get auto-rebuild and auto-reload, which is much better than a broken hot reload.

@danroth27, would love any update you or @tmat might have.

Will take a look.

I’ve managed to get hot reload working for .NET 6 and .NET 7 Blazor WebAssembly using dotnet watch.

I use VS Code DevContainers, and the following command works for me: DOTNET_USE_POLLING_FILE_WATCHER=true dotnet watch --project ./web.csproj

Please note that I use the following base image: mcr.microsoft.com/devcontainers/dotnet:7.0-jammy, which results in dotnet --version 7.0.102.

Targeting .NET 6, DOTNET_USE_POLLING_FILE_WATCHER=true dotnet watch is sufficient for hot reload to work. Targeting .NET 7, DOTNET_USE_POLLING_FILE_WATCHER=true dotnet watch --project ./web.csproj is needed, otherwise dotnet watch ⌚ no hot reload changes to apply. will be returned.

I hope this helps someone else struggling here.

Thanks for sharing this feedback. We are aware that there are a number of issues with hot reload we are trying to address. In order for us to address the issue you’re facing, could you please provide a repro project hosted as a public GitHub repo that demonstrates the problem?