-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dotnet watch file-watching has regressed in 9.0 #44912
Comments
Seeing additional issues with hot reload: dotnet watch ❌ [UI (net9.0)] Change failed to apply (error code: '00-01-00-00-00'). Further changes won't be applied to this process. Always on the second change to a CSS file. Works fine in .NET8 |
Not just CSS but every change in .razor files, after the second edit. While the second edit still gets applied, no further changes are applied starting from the third edit due to "Further changes won’t be applied to this process." This makes dotnet watch (hot-reload) essentially useless in .NET 9 😕
|
same here. .NET 8 (MVC) was stable and working but 9 does wired things with the Hot Reload... |
Seeing the same thing on WSL2 Ubuntu - I noticed if I edit the file with nvim it indicates the file was deleted, but if I edit it with nano, it recognizes it as a change. I was able to work around the deleted file issue by switching to file polling: DOTNET_USE_POLLING_FILE_WATCHER=1 dotnet watch However, I still run into the "Change failed to apply" with subsequent changes. |
worked for me on Win11 with an ASP.NET 9 MVC Webapp and VS 2022. |
I am seeing the File deleted issue very frequently with .razor file changes. This is a ".net hosted" Blazor WASM app with a Server & API project, a Client project, and razor components split out into a separate Razor Component Library. |
Fixed by #45097 |
Describe the bug
I am using "dotnet watch" to launch and watch an extremely simple asp.net application which, for the purposes of this bug report, simply serves up a static index.html file. I have a browser open on that page, and I edit the file in VS (17.12.0).
The app targets .NET 8.0 - The machine has both 8.0 and 9.0 SDKs installed, and the version of dotnet watch which runs is determined by a global.json file.
With the 8.0 SDK, if I make a simple modification to index.html, dotnet watch displays the following:
The browser is automatically refreshed, and the update is immediately visible.
With the 9.0 SDK, if I make the same kind of modification, in the same editor, I see the following output from dotnet watch:
The browser is refreshed, but it's intermittent if the modification is visible without needing a second, manual, browser refresh (i.e. there's a race here, presumably the browser is refreshed too early).
I assume that the intermediate files are part of some kind of "safe save" process which VS uses, and dnw was previously smart enough (or dumb enough!) to ignore these, but is now picking them up and confusing itself.
I know from working on other dev-tool file-watchers that editors will always find ways to confuse them, but I think it's reasonable to expect that "dotnet watch" is not confused by Visual Studio, particularly when it used to work OK. There is only one "breaking change" release note for dnw in 9.0, and it doesn't apply here.
Reproduction
Additional Info
.NET 8.0 --verbose startup output:
.NET 9.0 --verbose startup info
Further technical details
dotnet --info
The text was updated successfully, but these errors were encountered: