Blazor WASM 3.1 to Net5: Publish failed

[Gambero81]

I have migrated a blazor wasm application hosted in asp.net core from Net core 3.1 to Net 5 following the steps described in https://docs.microsoft.com/it-it/aspnet/core/migration/31-to-50?view=aspnetcore-5.0&tabs=visual-studio.

All work well except when i try to publish.

The publish process fail with this output:

The process cannot access the file 'C:\ARTCreditService\ARTCreditService.Client\obj\Release\net5.0\compress\WxGTI0fM.br' because it is being used by another process.
   at System.IO.FileStream.ValidateFileHandle(SafeFileHandle fileHandle)
   at System.IO.FileStream.CreateFileOpenHandle(FileMode mode, FileShare share, FileOptions options)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at System.IO.FileStream..ctor(String path, FileMode mode)
   at Microsoft.NET.Sdk.BlazorWebAssembly.Tools.BrotliCompressCommand.<ExecuteCoreAsync>b__16_0(Int32 i)
   at System.Threading.Tasks.Parallel.<>c__DisplayClass19_0`1.<ForWorker>b__1(RangeWorker& currentWorker, Int32 timeout, Boolean& replicationDelegateYieldedBeforeCompletion)
--- End of stack trace from previous location ---
   at System.Threading.Tasks.Parallel.<>c__DisplayClass19_0`1.<ForWorker>b__1(RangeWorker& currentWorker, Int32 timeout, Boolean& replicationDelegateYieldedBeforeCompletion)
   at System.Threading.Tasks.TaskReplicator.Replica`1.ExecuteAction(Boolean& yieldedBeforeCompletion)
   at System.Threading.Tasks.TaskReplicator.Replica.Execute()
C:\Program Files\dotnet\sdk\5.0.101\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\Microsoft.NET.Sdk.BlazorWebAssembly.Current.targets(564,5): Error MSB6006: "dotnet.exe" exited with code 1.

If i rollback to .net core 3.1 the publish process work well

What's wrong?

Thanks

[mkArtakMSFT]

Thanks for contacting us. We can't investigate issues custom projects. If you can share a reliably reproducable minimal app to demonstrate the problem, we can investigate then. Otherwise we recommend asking this in StackOverflow to get faster resolution.

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.

[Gambero81]

Hi, i manage to reply the issue with a sample code as soon as possible.

Thanks

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.

[dazinator]

It would be great if Microsoft would provide an incentive - some sort of reward scheme for anyone that provides a minimal repro's that is then used and accepted as identifying a valid bug (i.e it has provided value). (Similar to how whitehat hackers can be rewarded for finding and proving security holes). It takes many hours to work through producing some repro's and I feel it's slightly unfair to burden the community with this for things that do turn out to be providing value. The framework may be free / open source, but it does provide strategic value to MS. When a bug occurs on a given environment, there should be other ways to provide you with useful information such as MSBuild logs, stack trace, etc that can be used to reproduce or identify if there is a legitimate issue - enough at least not to auto-dismiss the issue. I'm going to timebox a day trying to create a minimal repro project - if I can't then I'll be at a loss, and our upgrade path from 3.1 to 5 will remain blocked until some good Samaritan can produce something of the level you require.

[dazinator]

Note for this issue, I note from the logs that the brotli compress task seemingly processes the particular file twice:

For example, the app.css file gets processed twice here to produce ht+9vXXP.br

 Done executing task "MakeDir".
       Using "BrotliCompress" task from assembly "C:\hostedtoolcache\windows\dotnet\sdk\5.0.102\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\..\tasks\net5.0\Microsoft.NET.Sdk.BlazorWebAssembly.Tasks.dll".
       Task "BrotliCompress"
         C:\hostedtoolcache\windows\dotnet\dotnet.exe "C:\hostedtoolcache\windows\dotnet\sdk\5.0.102\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\..\tools\net5.0\Microsoft.NET.Sdk.BlazorWebAssembly.Tools.dll" brotli
         -s
         D:\a\1\s\src\Foo.Client\wwwroot\appsettings.Development.json
         -o
         D:\a\1\s\src\Foo.Client\obj\Release\net5.0\compress\kMn0BpPF.br
         -s
         D:\a\1\s\src\Foo.Client\wwwroot\appsettings.json
         -o
         D:\a\1\s\src\Foo.Client\obj\Release\net5.0\compress\mnsMCpbd.br
         -s
         D:\a\1\s\src\Foo.Client\wwwroot\css\app.css
         -o
         D:\a\1\s\src\Foo.Client\obj\Release\net5.0\compress\ht+9vXXP.br
         -s
         D:\a\1\s\src\Foo.Client\wwwroot\css\app.css
         -o
         D:\a\1\s\src\Foo.Client\obj\Release\net5.0\compress\ht+9vXXP.br
         -s
         D:\a\1\s\src\Foo.Client\wwwroot\css\app.min.css

Later on where the build fails its because of a lock on this file ht+9vXXP.br

 The process cannot access the file 'D:\a\1\s\src\Foo.Client\obj\Release\net5.0\compress\ht+9vXXP.br' because it is being used by another process.
            at System.IO.FileStream.ValidateFileHandle(SafeFileHandle fileHandle)
            at System.IO.FileStream.CreateFileOpenHandle(FileMode mode, FileShare share, FileOptions options)
            at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
            at System.IO.FileStream..ctor(String path, FileMode mode)
            at Microsoft.NET.Sdk.BlazorWebAssembly.Tools.BrotliCompressCommand.<ExecuteCoreAsync>b__16_0(Int32 i)
            at System.Threading.Tasks.Parallel.<>c__DisplayClass19_0`1.<ForWorker>b__1(RangeWorker& currentWorker, Int32 timeout, Boolean& replicationDelegateYieldedBeforeCompletion)
         --- End of stack trace from previous location ---
            at System.Threading.Tasks.Parallel.<>c__DisplayClass19_0`1.<ForWorker>b__1(RangeWorker& currentWorker, Int32 timeout, Boolean& replicationDelegateYieldedBeforeCompletion)
            at System.Threading.Tasks.TaskReplicator.Replica`1.ExecuteAction(Boolean& yieldedBeforeCompletion)
            at System.Threading.Tasks.TaskReplicator.Replica.Execute()
   4:5>C:\hostedtoolcache\windows\dotnet\sdk\5.0.102\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\Microsoft.NET.Sdk.BlazorWebAssembly.Current.targets(564,5): error MSB6006: "C:\hostedtoolcache\windows\dotnet" exited with code 1. [D:\a\1\s\src\Foo.Client\Foo.Client.csproj]
       Done executing task "BrotliCompress" -- FAILED.

So what's special about that file?

The file looks like this in my project:

It's produced as a result of compiling the parent scss file, and its a nested file.

@Gambero81 - could you look at your logs and see if the file its complaining about is nested like mine? Do you use web compiler to compile scss files?

I noted for that file I have this entry in the project - and I am not entirely sure why:

    <ItemGroup>
        <_ContentIncludedByDefault Remove="wwwroot\css\app.css" />
    </ItemGroup>

[Gambero81]

Hi @dazinator i can confirm i use webcompiler as you to compile scss!

Where i can find the publish log with process details?

Thanks

[dazinator]

@Gambero81 do the dotnet publish command with -v detailed argument to get more verbose output.

@mkArtakMSFT I not put the time in to produce a reliable minimal repro for this issue - however removing this project entry - for some reason has fixed the issue on the CI server:

   <ItemGroup>
        <_ContentIncludedByDefault Remove="wwwroot\css\app.css" />
    </ItemGroup>

The factors involved to produce it seem to be:

1. Have a blazor hosted wasm project with the above entry for its css file.

2. Have the following project entries:

   <ItemGroup Label="ReproAttempt">
   <PackageReference Include="BuildWebCompiler" Version="1.12.405" Condition="$(DefineConstants.Contains(DEBUG))" />
   </ItemGroup>
   
   <ItemGroup>
   <_ContentIncludedByDefault Remove="wwwroot\css\app.css" />
   </ItemGroup>

Add a compilerconfig file to the client project, used to pre-process / compile the scss file:

Then do a dotnet publish -c Release on the solution. I was able to repro the error like this just once, when I had a fairly large volume of CSS to preprocess in that file. Subsequent attempts failed to reproduce so take this all with a pinch of salt.. needs to be narrowed down further.

[dazinator]

Also sometimes, doing the publish command with -v detailed actually seems to slow processing down enough that the lock issue on the file doesn't happen - and the publish succeeds. This happened for a while and made it very difficult to reproduce the issue and get information about what was going on. Luckily our CI server (Azure Devops Pipelines) was consistently slow enough that it we could reproduce it there with -v detailed.

[dazinator]

I'll create seperate issues for findings I am sure of.

[dazinator]

@mkArtakMSFT The bug here seems to be due to this: https://github.com/dotnet/aspnetcore/issues/29529 causing a duplicate entry for the Brotli task to process, in combination with the fact that it processes those entries in parallel - if one of the parallel tasks doesn't release its lock on the file in time, then you'll see this issue:

The process cannot access the file 'D:\a\1\s\src\Foo.Client\obj\Release\net5.0\compress\ht+9vXXP.br' because it is being used by another process. at System.IO.FileStream.ValidateFileHandle(SafeFileHandle fileHandle) at System.IO.FileStream.CreateFileOpenHandle(FileMode mode, FileShare share, FileOptions options) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options) at System.IO.FileStream..ctor(String path, FileMode mode) at Microsoft.NET.Sdk.BlazorWebAssembly.Tools.BrotliCompressCommand.b16_0(Int32 i) at System.Threading.Tasks.Parallel.<>c__DisplayClass19_0`1.b1(RangeWorker& currentWorker, Int32 timeout, Boolean& replicationDelegateYieldedBeforeCompletion) --- End of stack trace from previous location --- at System.Threading.Tasks.Parallel.<>c__DisplayClass19_01.<ForWorker>b__1(RangeWorker& currentWorker, Int32 timeout, Boolean& replicationDelegateYieldedBeforeCompletion) at System.Threading.Tasks.TaskReplicator.Replica1.ExecuteAction(Boolean& yieldedBeforeCompletion) at System.Threading.Tasks.TaskReplicator.Replica.Execute()

4:5>C:\hostedtoolcache\windows\dotnet\sdk\5.0.102\Sdks\Microsoft.NET.Sdk.BlazorWebAssembly\targets\Microsoft.NET.Sdk.BlazorWebAssembly.Current.targets(564,5): error MSB6006: "C:\hostedtoolcache\windows\dotnet" exited with code 1. [D:\a\1\s\src\Foo.Client\Foo.Client.csproj] Done executing task "BrotliCompress" -- FAILED.

As this issue is closed, I'll move the findings to the new issue I have linked.

[Gambero81]

@dazinator i can confirm the same issue, also for me deleting the below elements seem to fix the issue! Thanks for the workaround!

<_ContentIncludedByDefault Remove="wwwroot\css\app.css" />
<_ContentIncludedByDefault Remove="wwwroot\css\app.min.css" />