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

[release/8.0-preview4] [wasm] GenerateWasmBootJson - close file handles #85482

Merged

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Apr 27, 2023

Backport of #85480 to release/8.0-preview4

/cc @lewing @radical

Customer Impact

Blazor hosted templates will fail to publish during the nested build process.

Expected to fix the failures found in dotnet/aspnetcore#47540 (comment) .

Background

The hypothesis is that the following operations happen in order:

  1. GenerateBlazorBootExtensionJson calls File.Create to create obj/Release/net8.0/blazor.publish.boot-extension.json, and the file handle is closed
  2. GenerateWasmBootJson opens the same file with File.OpenRead but does not close it
  3. GenerateBlazorBootExtensionJson runs again as part of the nested build, but fails because (2) left the file open
The "GenerateBlazorBootExtensionJson" task failed unexpectedly. [/datadisks/disk1/work/B95509FE/w/998E08AE/e/Templates/BaseFolder/AspNet.hhjg2t3oatk0/Client/AspNet.hhjg2t3oatk0.Client.csproj]
System.IO.IOException: The process cannot access the file '/datadisks/disk1/work/B95509FE/w/998E08AE/e/Templates/BaseFolder/AspNet.hhjg2t3oatk0/Client/obj/Release/net8.0/blazor.publish.boot-extension.json' because it is being used by another process. [/datadisks/disk1/work/B95509FE/w/998E08AE/e/Templates/BaseFolder/AspNet.hhjg2t3oatk0/Client/AspNet.hhjg2t3oatk0.Client.csproj]
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Init(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Int64& fileLength, UnixFileMode& filePermissions) [/datadisks/disk1/work/B95509FE/w/998E08AE/e/Templates/BaseFolder/AspNet.hhjg2t3oatk0/Client/AspNet.hhjg2t3oatk0.Client.csproj]
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, UnixFileMode openPermissions, Int64& fileLength, UnixFileMode& filePermissions, Func`4 createOpenException) [/datadisks/disk1/work/B95509FE/w/998E08AE/e/Templates/BaseFolder/AspNet.hhjg2t3oatk0/Client/AspNet.hhjg2t3oatk0.Client.csproj]
   at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode) [/datadisks/disk1/work/B95509FE/w/998E08AE/e/Templates/BaseFolder/AspNet.hhjg2t3oatk0/Client/AspNet.hhjg2t3oatk0.Client.csproj]
   at System.IO.File.Create(String path) [/datadisks/disk1/work/B95509FE/w/998E08AE/e/Templates/BaseFolder/AspNet.hhjg2t3oatk0/Client/AspNet.hhjg2t3oatk0.Client.csproj]
   at Microsoft.NET.Sdk.BlazorWebAssembly.GenerateBlazorBootExtensionJson.Execute() [/datadisks/disk1/work/B95509FE/w/998E08AE/e/Templates/BaseFolder/AspNet.hhjg2t3oatk0/Client/AspNet.hhjg2t3oatk0.Client.csproj]
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [/datadisks/disk1/work/B95509FE/w/998E08AE/e/Templates/BaseFolder/AspNet.hhjg2t3oatk0/Client/AspNet.hhjg2t3oatk0.Client.csproj]
   at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [/datadisks/disk1/work/B95509FE/w/998E08AE/e/Templates/BaseFolder/AspNet.hhjg2t3oatk0/Client/AspNet.hhjg2t3oatk0.Client.csproj]

Testing

Automated and manual verification that the change is correct and doesn't regress working scenarios.

Risk

Very low, the change is very small and tested

Close files opened with `File.OpenRead` by utilizing the `using`
pattern.
@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Apr 27, 2023
@lewing lewing added Servicing-consider Issue for next servicing release review area-Build-mono and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Apr 27, 2023
@lewing lewing added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Apr 28, 2023
@lewing
Copy link
Member

lewing commented Apr 28, 2023

@carlossanlop the failures look fine and this is wasm only, please merge asap

@carlossanlop carlossanlop merged commit 37d789b into release/8.0-preview4 Apr 28, 2023
@carlossanlop carlossanlop deleted the backport/pr-85480-to-release/8.0-preview4 branch April 28, 2023 01:02
@ghost ghost locked as resolved and limited conversation to collaborators May 28, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Build-mono Servicing-approved Approved for servicing release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants