Using SassCompiler in a multitarget build causes file contention on Windows

[mikes-gh]

Would you accept a PR to use a Mutex around the compilation process here

AspNetCore.SassCompiler/AspNetCore.SassCompiler.Tasks/CompileSass.cs

Line 273 in 6e063ee

private (bool Success, string Output, string Error) GenerateCss(string arguments)

We have a large multi-project solution and some of our users are having problems with file contention.
Multiple builds occurring around the same time due to transitive project references to the same library.

Error running sass compiler: Error reading wwwroot\MudBlazor.min.css: Cannot open file

[mikes-gh]

This was solved by using a newer version where --update is working.

[mikes-gh]

Update the problem is still there
It appears to only occur on Windows, macOS and Linux don't have the problem since their file locking mechanisms are different.

MudBlazor/MudBlazor#10439

Here is what I think is happening we initiate a multitargeted build of our library.

1. The MSBuild builds MudBlazor.csproj in parallel net8 and net9
2. Whoever gets there first (let's say net9.0) starts the Compile Sass Task which in turn starts the dartsass executable.
3. net8.0 starts the Compile Sass Task and is unable to read MudBlazor.min.css. I think it is trying to do an up to date check in dartsass.

See the logs here

MudBlazor/MudBlazor#10439 (review)

 MudBlazor.SourceGenerator succeeded (0.3s) → MudBlazor.SourceGenerator\bin\Debug\netstandard2.0\MudBlazor.SourceGenerator.dll
  MudBlazor.Analyzers succeeded (0.5s) → MudBlazor.Analyzers\bin\Debug\netstandard2.0\MudBlazor.Analyzers.dll
  MudBlazor.Examples.Data succeeded (0.6s) → MudBlazor.Examples.Data\bin\Debug\net9.0\MudBlazor.Examples.Data.dll
  MudBlazor net9.0 succeeded (16.7s) → MudBlazor\bin\Debug\net9.0\MudBlazor.dll
    C:\Users\danie\.nuget\packages\aspnetcore.sasscompiler\1.82.0\build\AspNetCore.SassCompiler.targets(16,5): error : Error running sass compiler: Error reading wwwroot\MudBlazor.min.css: Cannot open file.

Obviously the library (nor dartsass) was not designed to be thread safe.
To save me forking the project (which I dont want to do) I would like to contribute a fix.
The fix would be fairly simple with a global mutex being placed around the relavent file access.
This would effectively serialize SassCompiler between threads/processes.

Multi-targeting is a common stratery for library components. It would be nice to support this out the box.

I hope you will allow me to work on this. However, I can't wait too long so I may have to fork and publish

[mikes-gh]

@sleeuwen

[adiessl]

Is the following summary of the problem correct?

MudBlazor is a multi target framework project. AspNetCore.SassCompiler is configured using a sasscompiler.json file. During the build process both the net8 and the net9 are simultaneously compiling SCSS to CSS and want to write the result to the file MudBlazor.min.css. If that happens in parallel, one of the two Dart Sass processes is unable to access the output file and the error Error running sass compiler: Error reading wwwroot\MudBlazor.min.css: Cannot open file. occurs.

If so, I am not sure this can be considered a problem of this library. And introducing a Mutex feels like a hack to me. If you look at where MSBuild is placing the MudBlazor.dlls, you'll notice that one is created in the folder MudBlazor\bin\Debug\net8.0\MudBlazor.dll and one in MudBlazor\bin\Debug\net9.0\MudBlazor.dll – maybe something similar should be done with the CSS files?

[mikes-gh]

It is placed in the source directory because the target <ResolveProjectStaticWebAssets> is where it expects it to be. Can you elaborate please. Also, for project references they are not going to look at bin directories are only going to check the intermediate output directory (obj). Feel like what you are suggesting is going against the normal MSBuild target execution cycle.

[mikes-gh]

The main point being is that MudBlazor.min.css is an input to MSBuild. Skipping that by placing it in output directorys bypasses a whole load of necessary processing.

[adiessl]

Sure, the normal MSBuild pipeline should not have to be altered. Ideally the SCSS compilation should only happen once per project, not for every target framework. I found the following post about basically the same problem, maybe something like this could be implemented? https://lizzy-gallagher.github.io/msbuild-run-target-once-per-project/

…

On Fri, 13 Dec 2024, 22:46 Mike Surcouf, ***@***.***> wrote: The main point being is that MudBlazor.min.css is an input to MSBuild. Skipping that by placing it in output directorys bypasses a whole load of necessary processing. — Reply to this email directly, view it on GitHub <#209 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKBDNYAZL6GHZOOHB3IME2D2FNITZAVCNFSM6AAAAABSCGKDOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBSGQZTENZVGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[mikes-gh]

Thanks for the reply I already looked at that. It doesn't work for project references though dotnet/msbuild#2781. It's common to build libraries through a project reference. In addition, with MSBuild parallel build proceses and a multi project solution it's conceivable that multiple projects could be building the library at the same time. I have spent a lot of time investigating this, but I am still open to an obvious solution.

[mikes-gh]

My naive attempt to solve it was changing it to BeforeTargets="DispatchToInnerBuilds". It works great, while we have only one project, but if we try to build solution, which contains project, referencing us, our build could be executed from ResolveReference target of other project, which will start inner-loop build for our project - DispatchToInnerBuilds will be executed in parallel in this case, so we run compilation now before we was able to generate source.

[mikes-gh]

In addition despite the above which wont work Sasscompiler already specifies its targets

see

AspNetCore.SassCompiler/AspNetCore.SassCompiler/build/AspNetCore.SassCompiler.targets

Line 15 in 1fdd305

<Target Name="Compile Sass" BeforeTargets="Build;ResolveScopedCssInputs;BundleMinify;ResolveProjectStaticWebAssets" Condition="'$(DesignTimeBuild)' != 'true'">

[adiessl]

I cloned the MudBlazor repo locally and executed dotnet build from the command line multiple times in the src folder in order to get the build failure stemming from the concurrent access of the generated CSS file – unfortunately that never occurred, the builds always ran through without problems.

The binlog I generated along with the build clearly shows, however, that the SCSS compilation happens two times, once per target framework:

I then implemented the solution from the blog post by @Lizzy-Gallagher I linked above (https://lizzy-gallagher.github.io/msbuild-run-target-once-per-project/), build a beta version of the NuGet package AspNetCore.SassCompiler locally and used this in the MudBlazor solution. Building it then showed the following output in the binlog, indicating that the SCSS compilation is now only done once for MudBlazor.csproj:

I also tried this beta version against one of our solutions which is using AspNetCore.SassCompiler (only targeting net8) and everything still worked as before there.

Therefore I will open a PR with my changes as I think they should hopefully cover the majority (if not all) issues caused by multitargeting.

---

Thanks for the reply I already looked at that. It doesn't work for project references though dotnet/msbuild#2781. It's common to build libraries through a project reference. In addition, with MSBuild parallel build proceses and a multi project solution it's conceivable that multiple projects could be building the library at the same time. I have spent a lot of time investigating this, but I am still open to an obvious solution.

If my proposed solution should not work in cases like these, we would need to have a repo where this problem occurs so we can troubleshoot further.