Skip to content
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 run infinite loop not honoring exclude/remove config #27775

Closed
johan-v-r opened this issue Nov 12, 2020 · 7 comments
Closed

dotnet watch run infinite loop not honoring exclude/remove config #27775

johan-v-r opened this issue Nov 12, 2020 · 7 comments
Labels
affected-very-few This issue impacts very few customers area-commandlinetools Includes: Command line tools, dotnet-dev-certs, dotnet-user-jwts, and OpenAPI bug This issue describes a behavior which is not expected - a bug. feature-dotnetwatch This issue is related to the dotnet-watch command-line tool (now external) investigate severity-blocking This label is used by an internal tool
Milestone

Comments

@johan-v-r
Copy link

Describe the bug

2 issues that seem related:

  1. Exclude/Remove watched files (configured in csproj) not honored.
  2. Saving scss files in different folders cause the watch to rebuild infinitely.

It looks like the build creates the css file, which is then watched and the cycle continues.

To Reproduce

Repro project available here: https://github.com/johan-v-r/Blazor-Wasm-Watch-Repro

Further technical details

VS 2019 16.8.0 with .NET 5.0.100

Able to replicate on 3 different Windows 10 machines, and just with CLI & notepad

@mkArtakMSFT mkArtakMSFT added area-commandlinetools Includes: Command line tools, dotnet-dev-certs, dotnet-user-jwts, and OpenAPI feature-dotnetwatch This issue is related to the dotnet-watch command-line tool (now external) labels Nov 12, 2020
@mkArtakMSFT mkArtakMSFT added affected-very-few This issue impacts very few customers enhancement This issue represents an ask for new feature or an enhancement to an existing one severity-blocking This label is used by an internal tool labels Nov 12, 2020 — with ASP.NET Core Issue Ranking
@mkArtakMSFT mkArtakMSFT added investigate and removed enhancement This issue represents an ask for new feature or an enhancement to an existing one labels Nov 12, 2020
@mkArtakMSFT mkArtakMSFT added this to the Next sprint planning milestone Nov 12, 2020
@ghost
Copy link

ghost commented Nov 12, 2020

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

@mkArtakMSFT mkArtakMSFT added severity-blocking This label is used by an internal tool and removed severity-blocking This label is used by an internal tool labels Nov 12, 2020
@javiercn javiercn added the bug This issue describes a behavior which is not expected - a bug. label Feb 19, 2021 — with ASP.NET Core Issue Ranking
@dwerner80
Copy link

Any updates on this? I'd love to use dotnet watch with component-scoped .scss files but this bug makes it impossible because I can't include **/*/*.scss files and exclude **/*/*.css files from the watcher.

I have a similar scenario as OP, but I'm using a gulp pipeline using gulp-sass that runs during build and generates .css files, and I don't want those generated files picked up by the watcher. Currently, they get picked up, so I end up in this same infinite loop.

@zaneclaes
Copy link

zaneclaes commented Apr 20, 2021

This is affecting more users than it may appear. The problem is not constrained to *.scss files. I use two entirely different code-gen tools for my GraphQL client and server. Each of them are sufficient to trigger this bug, i.e., cause dotnet watch to be unusable due to infinite restart loops.

@leolin16
Copy link

leolin16 commented May 3, 2021

Please forgive me that I'm still a newbie to the dotnet world, but I've been able to reproduce this issue in several use cases here(currently found in one Blazor project & one MVC API project both via dotnet version 6.0.0-preview.3.21201.13):

  • when I wanted to generate pictures under wwwroot of a REST API project during dotnet watch run, <Watch Exclude... and <Watch Remove... in csproj didn't have effects and infinite build loop introduced.
  • when I wanted to use scss and put the scss-to-css generation task in the pre-build event, the generated/re-generated *.css.map has caused dotnet watch build or dotnet watch run(without "hotReloadProfile": "blazorwasm" set in launchSettings.json) to fail into infinite building loop, although <Watch Exclude... and <Watch Remove... in csproj has been tried.

It seems that two stackoverflow links are related to this.

  1. https://stackoverflow.com/questions/65376352/how-to-exclude-certain-file-types-from-dotnet-watch-run
  2. https://stackoverflow.com/questions/65775540/net-watch-exclude-files-does-not-compile

May I ask is there any further update regarding whether in the next milestone this issue will be fixed? or any possibility prediction for this issue to be fixed in the up-coming official release of dotnet 6 on November this year(2021) if not earlier?
Thanks team, if possible investigation/evaluation/consideration could be provided.

@McNerdius
Copy link

this did the job for me: #31141 (comment)

@GravlLift
Copy link

GravlLift commented Jun 2, 2021

None of the suggestions here helped me, but I was able to figure out what's causing my css files to be included despite my protests using dotnet watch --list. With a bit of experimenting, I was able to conclude that all of the files from the None build group were being watched, and I was able to finally ignore them for good with:

  <ItemGroup>
    <None Update="**/*.razor.css" Watch="false" />
  </ItemGroup>

Apparently dotnet includes a lot of groups of files in the watch by default.

Unfortunately, this only partially solved my particular problem, as the build process is somehow ignoring the changes my pre-build target is making to the files. :/

Edit: Fixed that too. Make sure your sass build step targets before Blazor's css target ResolveScopedCssInputs rather than just before Build.

<Target Name="SassCompile" BeforeTargets="ResolveScopedCssInputs">

@johan-v-r
Copy link
Author

Thanks @GravlLift this did the trick! My config to watch scss and exclude css is now:

<ItemGroup>
	<!-- extends watching group to include *.scss files & remove *.css -->
	<Watch Include="**/*.scss" />
	<None Update="**/*.css" Watch="false" />		
</ItemGroup>

@dotnet dotnet locked as resolved and limited conversation to collaborators Jul 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affected-very-few This issue impacts very few customers area-commandlinetools Includes: Command line tools, dotnet-dev-certs, dotnet-user-jwts, and OpenAPI bug This issue describes a behavior which is not expected - a bug. feature-dotnetwatch This issue is related to the dotnet-watch command-line tool (now external) investigate severity-blocking This label is used by an internal tool
Projects
None yet
Development

No branches or pull requests

8 participants