johan-v-r / LibSassBuilder

Sass builder for .NET projects
MIT License
99 stars 14 forks source link

LibSassBuilder stops building in Visual Studio when the project's considered to be 'up-to-date'. #16

Closed mooski closed 3 years ago

mooski commented 3 years ago

I find that LibSassBuilder sometimes intermittently randomly stops building in Visual Studio. I can't figure out the exact trigger for this - sometimes it seems to work fine, but frequently it just stops working. So there are a million different ways to reproduce this, and I only hope that you can reproduce it in the same way that's causing me so many problems, but this particular set of steps seems to reproduce it consistently - I can only apologise for how convoluted this seems but this is the simplest CONSISTENT set of repro steps I've managed:

Visual Studio 2019, version 16.9.0. LibSassBuilder 1.6.1.

  1. Create a new C# console application in Visual Studio - choose .NET 5.0 as the target framework.
  2. In Solution Explorer, right-click on the project, choose Add > New Item, and add a new SCSS style sheet, e.g. StyleSheet1.scss.
  3. Add the LibSassBuilder NuGet package to the project.
  4. Build the solution, and note that the CSS gets generated correctly.
  5. Modify the SCSS then build the solution again; note that the CSS gets generated correctly again. So far so good.
  6. Rght-click on the project in Solution Explorer and choose 'Edit Project File', then modify the project file in some way - e.g. add a blank line, then save the file.
  7. Modify the SCSS file again.
  8. Build the solution, and note that the CSS gets generated correctly.
  9. Without making any more changes, build the solution again.
  10. Modify the SCSS file again.
  11. Build the solution, and note that the CSS does NOT get generated.

What's interesting here is that the build log message has now changed to '1 up-to-date'. Since we're not changing any code - only SCSS files - perhaps this makes sense??? But what I can't understand is why it seemed to behave differently earlier in the process and we could just change SCSS files and still trigger a build.

johan-v-r commented 3 years ago

Unfortunately again this seems like a VS related issue.
I could replicate this issue without LibSassBuilder in a new console app with the following config:

<ItemGroup>
    <!-- extends watching group - https://docs.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch?view=aspnetcore-5.0#customize-files-list-to-watch -->
    <Watch Include="**\*.scss" Exclude="**\*.css" />
</ItemGroup>

It is really annoying yes, I have no idea why this happens, so if you do find more info please let me know!

As an alternative you could use dotnet watch run which seems to rebuild every time.

JelleHissink commented 3 years ago

For me adding this to the project file helped, it bypasses VS up-to-date checks. Msbuild is almost as fast.

<PropertyGroup>
    <DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
</PropertyGroup>
mooski commented 3 years ago

Thanks again @johan-v-r and @JelleHissink

I even saw the comment about DisableFastUpToDateCheck in the readme when I first started looking at this project, but didn't fully understand it so skipped straight over it. Now I've experienced it for myself I think I have a better understanding of why this exists! For me this solution is fine because like you say it barely adds any time on to builds anyway.

So thanks for pointing me back in the right directions and apologies for wasting your time. I'm happy if you want to close this issue.

JelleHissink commented 3 years ago

Haha, no worries, I just wrote the comment in the readme a while ago.

I think it should be expressed more clearly in the readme then, you should not have needed to file an issue in the first place.

We could even have switched DisableFastUpToDateCheck on in the package by default, however I feel that is not the correct solution either.

JelleHissink commented 3 years ago

:-) you got me thinking!!!!

https://github.com/dotnet/project-system/blob/main/docs/up-to-date-check.md

I'll try to see if I can find time to try that.

mooski commented 3 years ago

That certainly looks interesting, and if it's possible to implement a solution which means that we don't need to use this workaround that of course that would be great :-)

JelleHissink commented 3 years ago

Is it just me... after fixing #15 (1.6.2) I cannot reproduce this? I am using visual studio 16.10.0 Preview 1.0.

Could you please check for me if I'm dreaming...

mooski commented 3 years ago

I agree @JelleHissink - I can't reproduce this since upgrading to 1.6.2 - either in my Blazor project or a console project using the repro steps above.

I guess this is good news!

JelleHissink commented 3 years ago

Thanks for the feedback!

I suspect informing VS about the filetype is already enough to get it on the designtime watch list :-)

We could close this issue for now, at least there is a pointer to a solution if it would ever become an issue again.

It might also be possible to remove the whole and DisableFastUpToDateCheck comments from the Readme as that should now be covered by this package.

mooski commented 3 years ago

No problem, I'm glad it seems to be sorted.

I'll keep an eye out for any problems while I work with it over the coming days.

Thanks for all your help.

JelleHissink commented 3 years ago

Always happy... and if there are any issues or wishes, feel free to report them

johan-v-r commented 3 years ago

Magic! Could be a nice first-issue to help update the docs if you'd like to contribute @mooski 😃

mooski commented 3 years ago

Sure, I'd love to @johan-v-r - but now this issue has fixed itself I believe the only thing that needs doing is to remove the DisableFastUpToDateCheck section?