dotnet watch hot reloads for all non-code files - potential infinite reload loop

[seangwright]

Describe the bug

I'm running dotnet watch in the directory of an ASP.NET Core 8.0 application using the .NET 9 SDK.

My app generates non-code files in the ~\App_Data directory as part of a background process (this includes binary, xml, json, and other non code files). When this happens, dotnet watch records the files being created or modified and will even hot reload

For example

dotnet watch ⌚ Files added: .\App_Data\LuceneSearch\QANDA_SEARCH\i-g0000059-p_False\write.lock, .\App_Data\LuceneSearch\QANDA_SEARCH\i-g0000059-p_False_taxonomy\write.lock
dotnet watch ⌚ Files added: .\App_Data\LuceneSearch\QANDA_SEARCH\i-g0000059-p_False\write.lock, .\App_Data\LuceneSearch\QANDA_SEARCH\i-g0000059-p_False_taxonomy\write.lock
dotnet watch ⌚ No hot reload changes to apply.

I have tried ignoring specific files but none of the recommendations work. Even if they did work, there's no reason I should have to explicitly ignore some .txt files in App_Data to keep my app from reloading.

To Reproduce

1. Clone https://github.com/seangwright/dotnet-watch-dotnet-sdk9-bug
2. Run dotnet watch
3. See home page load in browser
4. See infinite number of .txt files created in App_Data\Test because dotnet watch keeps reloading the page

Exceptions (if any)

dotnet watch should not process files that have nothing to do with rebuilding or hot-reloading my .NET application.

Further technical details

.NET SDK:
 Version:           9.0.100
 Commit:            59db016f11
 Workload version:  9.0.100-manifests.c6f19616
 MSBuild version:   17.12.7+5b8665660

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22631
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.100\

.NET workloads installed:
 [aspire]
   Installation Source: VS 17.12.35506.116
   Manifest Version:    8.2.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
   Install Type:              Msi

Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.0
  Architecture: x64
  Commit:       9d5a6a9aa4

.NET SDKs installed:
  8.0.404 [C:\Program Files\dotnet\sdk]
  9.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.36 [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.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.36 [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.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.36 [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.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.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

global.json file:
  E:\workspace\dotnet\ASPNETMVC8_NET9SDK\global.json

This bug negatively impacts any project that generates files in the project during runtime - ASPNET Core apps with client assets, files uploaded/imported to the file system, log files, ect...

[hopsoftsro]

I had similar issue to exclude some directory from dotnet watch but it didn't work

[patrikholcak]

This is frustrating, particularly with webpack hot reload + emit files, where every time you save a js file, it emits hot reload chunk + json, which are added to the watch. It really slows down the reload after a couple of file changes and hogs CPU 😬

[seangwright]

I'm still not using .NET 9, 3 months after its release, because of this issue.
Because the issue is untriaged, I can't identify which .NET SDK update would include a potential fix for it.

I tried 9.0.102, which did not resolve the problem.

[Santas]

I'm considering every day if it is not worth it to downgrade back to .NET 8 every time the dotnet watch has some issue.

[seangwright]

4 months after release and I'm still using .NET 8 because of this issue.

[tmat]

Starting with 9.0.200 dotnet-watch ignores files in output directories (bin, obj) and in directories starting with ..

Further customization of ignored files is tracked by issue #45539.

should not process files that have nothing to do with rebuilding or hot-reloading my .NET application.

We do not know whether other files that are being added have anything to do with building until we evaluate the project.
If the evaluation determines the files have no effect on the compilation "No hot reload changes to apply." is reported as shown in your output example. This message means the change had no effect.

[seangwright]

The issue is dotnet watch now watches a lot more than it used to.

It feels much more like opt-out configuration is required than opt-in.

Since the opt-out configuration does not work today I cannot use dotnet watch in .NET 9.

[tmat]

@seangwright I'm not sure I understand why dotnet-watch reporting "No hot reload changes to apply" is a blocker. Could you elaborate?

[willdean]

@seangwright I'm not sure I understand why dotnet-watch reporting "No hot reload changes to apply" is a blocker. Could you elaborate?

I can't speak for the OP, but dotnet watch in 9.0 is
A. Much slower than it used to be
and
B. Outputs a lot more messages about noticing changes in irrelevant files than it used to.

Of course, 'A' might not be related to 'B' but to those of us outside the black box it seems reasonable to feel that there might be a connection.