Hot Reload of Blazor Server project requires restart reporting attributes in unchanged projects prevent hot reload ENC0033.

[silentdiverchris]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When working on a Blazor Server application, I almost constantly have to stop and rebuild rather than being able to hot reload, even when, for example, doing something as tiny as changing a class in a div element.

[Edit] I say almost constantly; somtimes it works as expected and I can hot reload through a series of small changes, but often VS seems to get into a mood and whatever I change, however minor requires a rebuild and restart.

I get the 'Hot Reload - Changes not supported' dialogue, and on checking the Hot Reload Output pane, there are dozens of reports of ENC0033 saying that deleting an attribute requires restart, in several projects that have not been changed, as I say, even when just making a very small markup alteration to a razor component.

In the example below, I literally just fixed a text typo inside a div in a .razor file in the Hermes.Blazor project and am seeing errors for attributes being deleted in the SharedUI project, and the TestNamedPipes project, neither of which have changed, and no files of either have been opened in the UI since the last full rebuild.

For some reason my screenshot won't upload, but it's just a list of ENC0033 errors about various unchanged projects.

I appreciate this would be very hard to investigate without a copy of my solution, but it's been like this for several updates, I've rather been expecting the problem to go away and take every update when it comes available hoping to see something about hot reload in the issues resolved, but these days the release notes seem to be all about adding something called AI to everything rather than fixing bugs.

Expected Behavior

Hot Reload to be consistently possible for small, localised changes, especially when it's just markup.

Steps To Reproduce

Easy for me to reproduce it here, fresh start of VS, full rebuild of blazor server app, run it, change some markup in a .razor file and hit the hot reload button.

Possibly tricky elsewhere without my specific project files. I can provide evidence / diagnostics if required, no problem to make the errors happen.

Exceptions (if any)

Sometimes it's fine, which isn't not very helpful I'm afraid, but restarting VS alone isn't a fix-all.

.NET Version

10.0.400-preview.0.26322.102

Anything else?

dotnet --info output below;

.NET SDK:
Version: 10.0.400-preview.0.26322.102
Commit: 0cf89a94a1
Workload version: 10.0.400-manifests.11c77abd
MSBuild version: 18.9.0-preview-26322-102+0cf89a94a

Runtime Environment:
OS Name: Windows
OS Version: 10.0.19045
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\10.0.400-preview.0.26322.102\

.NET workloads installed:
[android]
Installation Source: VS 17.14.36511.14, VS 18.9.12009.208
Manifest Version: 36.1.69/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.android\36.1.69\WorkloadManifest.json
Install Type: Msi

[ios]
Installation Source: VS 17.14.36511.14, VS 18.9.12009.208
Manifest Version: 26.5.10301/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.ios\26.5.10301\WorkloadManifest.json
Install Type: Msi

[maccatalyst]
Installation Source: VS 17.14.36511.14, VS 18.9.12009.208
Manifest Version: 26.5.10301/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.maccatalyst\26.5.10301\WorkloadManifest.json
Install Type: Msi

[maui-windows]
Installation Source: VS 17.14.36511.14, VS 18.9.12009.208
Manifest Version: 10.0.20/10.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.maui\10.0.20\WorkloadManifest.json
Install Type: Msi

Configured to use workload sets when installing new manifests.
No workload sets are installed. Run "dotnet workload restore" to install a workload set.

Host:
Version: 10.0.10
Architecture: x64
Commit: f7d90799ce

.NET SDKs installed:
6.0.428 [C:\Program Files\dotnet\sdk]
7.0.102 [C:\Program Files\dotnet\sdk]
7.0.120 [C:\Program Files\dotnet\sdk]
7.0.400 [C:\Program Files\dotnet\sdk]
8.0.100-preview.7.23376.3 [C:\Program Files\dotnet\sdk]
9.0.119 [C:\Program Files\dotnet\sdk]
9.0.305 [C:\Program Files\dotnet\sdk]
10.0.400-preview.0.26322.102 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.0-preview.7.23375.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.28 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.18 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.21 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.0-preview.7.23375.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.0-rc.2.23479.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.28 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.0-preview.7.24405.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.18 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.0-rc.1.25451.107 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.21 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.0-preview.7.23376.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.28 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.18 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.0-rc.1.25451.107 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[javiercn]

@silentdiverchris thanks for contacting us.

Definitely strange that something like a markup change would cause something like that. I don't think we can do anything with the current information. I would suggest two approaches. Either try to replicate the same change on a vanilla project from the template (keep adding things from your project until you are able to reproduce it) or remove elements from your solution until you no longer reproduce it. I can think that you might have something like a source generator or something like that which might be interferring?

@tmat might have some additional ideas as to how to pinpoint this, or maybe we could improve logging otherwise to print the type/attribute that is causing the issue for the future, to be able to have some sort of hint

[silentdiverchris]

Hi, thanks for a swift response, incomplete reply here.

Firstly, no source generator, all totally hand crafted by this human.

Yep I guess, a minumum project to reproduce would be almost the only way to give you a chance of seeing it in your environment. To be honest I was rather hoping it was a fairly common thing, and that the dev team or somebody else would have the same problem and do the hard work for me, or it'd just get fixed as a result of some other changes or whatever but searching for similar problems hereabouts I get the impression it's just me, so I'll have to put the effort in, fair enough.

I'll get some detailed diags from the error window and provide some more info in the next day or two, just in case any of that helps, it'd be good to try to avoid building up or whittling down to get to something I could send to you, but if that's what it takes...

[willdean]

I was rather hoping it was a fairly common thing,

Well, it's the kind of thing I see a lot too, if that makes you feel better.

It always feels like there is somewhat of a reality distortion field when it comes to Hot Reload - on the outside there are apparently lots of us who think their day is going unusually well if we can get 30 minutes out of it before it fails and needs a VS restart, and on the inside there are people closing issues on the (genuinely held, I am not casting aspersions on their character) idea that the last point release really did get it all fixed-up and in the very unlikely event that some of us still have rare problems we can open a new issue.

Anyway, issue dotnet/aspnetcore#64373 (closed, but don't let that mislead) contains instructions on how to use an environment variable to turn on very detailed hot-reload logging in VS, I think these logs are useful to MS if you report problems.

[silentdiverchris]

Thanks for the pointer, can't believe I didn't find that issue with various searches on hot reload and the like, but it's given me a warm feeling like I'm part of a community now I read all the similar experiences to my own - a bit like joining a heammoroids support group perhaps.

Have grabbed the command to set the hot reload log location, cheers.

My first hot reload after that worked just fine, and while I'd be more than happy with a 'turn on diagnostics and the problem goes away' solution, looking at the generated diags it certainly seems detailed, and even has before and after intermediate code stuff, should be handy, great.

[willdean]

As someone who's had that environment variable set for months, I have to let you know that it is not sufficient to stop the problems, sorry.

My ultimate ambition is to have a bell ring in Satya Nadella's office every time someone has to restart VS because hot-reload has failed.

[silentdiverchris]

If it helps here is a snippet from HotReloadLog\Session.log for a hot reload fail on just hitting continue on a breakpoint.

The solution had just completely rebuilt following previous fail to hot reload on a previous breakpoint exactly as per intial report, no code changes at all during the run, purely hitting breakpoint, floating mouse over to check a variable value and pressing continue, and the 'Hot Reload - Changes not supported' popup appears.

Lots more in the log but I thought this section was worth highlighting as it's saying that AssemblyInfo.cs was deleted, in a project that hasn't been altered in literally months. Actually, one exception, I update the assembly version number in all projects when I change it, so that means an assemblyinfo.cs change in all projects in the solution but I've not incremented the version for a few days.

Details

Project summary for 'C:\Hermes\Source\Hermes.UnitTest\Hermes.UnitTest.csproj': InvalidChanges Found 0 potentially changed, 2 deleted document(s) in project 'C:\Hermes\Source\Hermes.Authenticator\Hermes.Authenticator.csproj' Document changed, added, or deleted: 'C:\Hermes\Source\Hermes.Authenticator\obj\Debug\net10.0-windows7.0\Hermes.Authenticator.AssemblyInfo.cs' Document changed, added, or deleted: 'C:\Hermes\Source\Hermes.Authenticator\obj\Debug\net10.0-windows7.0\.NETCoreApp,Version=v10.0.AssemblyAttributes.cs'

The AssemblyInfo.cs has changed/deleted in several other projects in the solution too

Another section is saying that DataCompare.GlobalUsings.g.cs has been deleted, that's purely a project to contain a SQL data compare .dcmp file, again, unchanged for a long time.

So in at least 2 cases the 'InvalidChanges' is provoked by AssemblyInfo and AssemblyAttributes files in unchanged projects, not actual .cs or .razor etc source code files - so I guess the question is, should Assembly* files be triggering the fail to hot reload / should they not be deleted / should they have been ignored / is there something about my solution that's rebuilding them when it shouldn't etc ?

Details

Found 0 potentially changed, 3 deleted document(s) in project 'C:\Hermes\Source\DataCompare\DataCompare.csproj' Document changed, added, or deleted: 'C:\Hermes\Source\DataCompare\obj\Debug\net10.0\DataCompare.GlobalUsings.g.cs' Document changed, added, or deleted: 'C:\Hermes\Source\DataCompare\obj\Debug\net10.0\DataCompare.AssemblyInfo.cs' Document changed, added, or deleted: 'C:\Hermes\Source\DataCompare\obj\Debug\net10.0\.NETCoreApp,Version=v10.0.AssemblyAttributes.cs' Project summary for 'C:\Hermes\Source\DataCompare\DataCompare.csproj': InvalidChanges Solution update 1.3 status: Ready

---

The -old.cs file content for the above file is below, you asked earlier about code generation tools, and yes, whuile I don't explicitly use anything like that other than an sccs pre-processor, I have a vague memory that the assembly info file is re-generated on a rebuild (might not be the case now) but that's internal to VS so presumably shouldn't be something that another part of VS would fall over ?

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//     Runtime Version:4.0.30319.42000
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

using System;
using System.Reflection;

[assembly: System.Reflection.AssemblyCompanyAttribute("Chris")]
[assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")]
[assembly: System.Reflection.AssemblyDescriptionAttribute("Authenticates computers to run Hermes applications")]
[assembly: System.Reflection.AssemblyFileVersionAttribute("1.7.6.63")]
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.7.6.63+34e978d79b50460a5b8aa4a71f2ecb079bd5d2a5")]
[assembly: System.Reflection.AssemblyProductAttribute("Hermes.Authenticator")]
[assembly: System.Reflection.AssemblyTitleAttribute("Hermes.Authenticator")]
[assembly: System.Reflection.AssemblyVersionAttribute("1.7.6.63")]
[assembly: System.Runtime.Versioning.TargetPlatformAttribute("Windows7.0")]
[assembly: System.Runtime.Versioning.SupportedOSPlatformAttribute("Windows7.0")]

// Generated by the MSBuild WriteCodeFragment class.

[javiercn]

@silentdiverchris thanks for the additional details.

Is this a Maui/Windows app? (from the Windows7.0 TFM)

[silentdiverchris]

@silentdiverchris thanks for the additional details.

Is this a Maui/Windows app? (from the Windows7.0 TFM)

Hi, no/yes - specifically it's a Windows Console app.

The one I'm having trouble hot reloading is a Blazor Server app in the same solution, the Assembly.cs file is from a tiny console app that generates an auth token thing, unchanged for an age (apart from the version number).

I'm mulling the idea of separating out the Blazor Server app into it's own solution to see if that helps, the 2 project dependencies I can reference via local packages. Then at least hot reload can only be stymied by files in the blazor project itself, not the Assembly* files in the other dozen projects.

[javiercn]

The one I'm having trouble hot reloading is a Blazor Server app in the same solution, the Assembly.cs file is from a tiny console app that generates an auth token thing, unchanged for an age (apart from the version number). <- Not sure if something is rewriting the file every time and that's causing it.

You could try adding an incrementality check, but I don't think this is Blazor specific and has to do with something you have wired up on the build. @tmat might have some ideas, but separating stuff into its own solution might be a good path forward

[silentdiverchris]

You could try adding an incrementality check, but I don't think this is Blazor specific and has to do with something you have wired up on the build. @tmat might have some ideas, but separating stuff into its own solution might be a good path forward

Hi, no idea what an incrementality check is, the first 2 pages of matches have it as a marketing term :)

Running the Blazor project in it's own solution of one project seems to make a big difference.

Early days, only half an hour in and perhaps a dozen hot reloads on minor markup changes went smoothly. I'll report back when I've done more than a handful, if it stays like that it's more than worth the faff of having the shared DLLs in a different solution with all the other projects.

has to do with something you have wired up on the build

The only build action is the sass pre-processing, below, and neither the source .scss or the the resulting .css files are mentioned in the hot reload logs at all. No other build actions other than whatever VS does itself (eg the Assembly.cs file getting generated, if that still happens on build, I think it used to).

sass Styles:wwwroot/css Pages:Pages Components:Components --style compressed --load-path=Styles --update

As in my reply above, there are lots of 'Invalid Changes' complaints about Assembly.* files in the hot reload log (before separating out the Blazor project), it might not be the only culprit, but is definitely one of them (am assuming that one or more 'Invalid Change' errors means hot reload isn't possible).

[javiercn]

@silentdiverchris thanks for the additional details.

The fact that breaking it up on a separate solution does the trick, likely means that something happening on the class library is triggering the issue. Not sure exactly what. Incrementality meant to not write the file at all if the contents didn't change. Hot reload watches for file changes to recompile and send deltas, so what I think is happening is something on a class library is being re-written on a build, and that's causing the unsupported change. Obviously, I can't tell without seeing the actual app, but that's where I would look at.

As I said, @tmat probably is the only one that can help. I'm going to move this to the SDK repo which is where dotnet-watch and hot reload issues are tracked