dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.17k stars 9.93k forks source link

Microsoft.AspNetCore.Mvc.Testing 6.0.0 has concurrency issues on filesystem #38808

Open lippinio opened 2 years ago

lippinio commented 2 years ago

Describe the bug

After Upgrading to Microsoft.AspNetCore.Mvc.Testing 6.0.0 we are encountering concurrency issus on dotnet publish tasks. Below you find a minimal repo to reproduce the issue. The setup is following. We have a testhelper project that references the Microsoft.AspNetCore.Mvc.Testing 6.0.0 Nuget. Two projects referencing the testhelpers. So the two testprojects have implicit references to Microsoft.AspNetCore.Mvc.Testing. On publish the following issue seen under Exceptions. The issue is not persistant and happens only in some cases. Around 25 % of the publishes. So the minimal repo contains a runner script that loops over the given buildsteps in a Dockerfile.

To Reproduce

Prerequisites: Docker and Shell

Clone Repo https://github.com/lippinio/concurrency chmod +x runner.sh Run runner.sh

Exception

` > [6/6] RUN dotnet publish ./concurrency.sln --configuration Release --no-build --output ./out:

10 0.504 Microsoft (R) Build Engine version 17.0.0+c9eb9dd64 for .NET

10 0.504 Copyright (C) Microsoft Corporation. All rights reserved.

10 0.504

10 1.439 testhelpers -> /app/out/

10 1.854 /root/.nuget/packages/microsoft.aspnetcore.mvc.testing/6.0.0/build/net6.0/Microsoft.AspNetCore.Mvc.Testing.targets(57,5): error MSB4018: The "GenerateMvcTestManifestTask" task failed unexpectedly. [/app/tests1/tests1.csproj]

10 1.854 /root/.nuget/packages/microsoft.aspnetcore.mvc.testing/6.0.0/build/net6.0/Microsoft.AspNetCore.Mvc.Testing.targets(57,5): error MSB4018: System.IO.IOException: The process cannot access the file '/app/out/MvcTestingAppManifest.json' because it is being used by another process. [/app/tests1/tests1.csproj]

10 1.854 /root/.nuget/packages/microsoft.aspnetcore.mvc.testing/6.0.0/build/net6.0/Microsoft.AspNetCore.Mvc.Testing.targets(57,5): error MSB4018: at Microsoft.Win32.SafeHandles.SafeFileHandle.Init(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize) [/app/tests1/tests1.csproj]

10 1.854 /root/.nuget/packages/microsoft.aspnetcore.mvc.testing/6.0.0/build/net6.0/Microsoft.AspNetCore.Mvc.Testing.targets(57,5): error MSB4018: at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize) [/app/tests1/tests1.csproj]

10 1.854 /root/.nuget/packages/microsoft.aspnetcore.mvc.testing/6.0.0/build/net6.0/Microsoft.AspNetCore.Mvc.Testing.targets(57,5): error MSB4018: at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize) [/app/tests1/tests1.csproj]

10 1.854 /root/.nuget/packages/microsoft.aspnetcore.mvc.testing/6.0.0/build/net6.0/Microsoft.AspNetCore.Mvc.Testing.targets(57,5): error MSB4018: at Microsoft.AspNetCore.Mvc.Testing.Tasks.GenerateMvcTestManifestTask.Execute() [/app/tests1/tests1.csproj]

10 1.854 /root/.nuget/packages/microsoft.aspnetcore.mvc.testing/6.0.0/build/net6.0/Microsoft.AspNetCore.Mvc.Testing.targets(57,5): error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [/app/tests1/tests1.csproj]

10 1.854 /root/.nuget/packages/microsoft.aspnetcore.mvc.testing/6.0.0/build/net6.0/Microsoft.AspNetCore.Mvc.Testing.targets(57,5): error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [/app/tests1/tests1.csproj]

`

ghost commented 2 years ago

Thanks for contacting us. We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

ghost commented 1 year ago

Thanks for contacting us. We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

chklauser commented 1 year ago

We are affected by this bug. It randomly causes CI builds to fail. (Maybe 10% of all builds). This is annoying because each instance requires manual assessment and intervention.

I am pretty firmly of the opinion that this is an issue of the ASP.NET testing framework (hard-coded path that conflicts if you have multiple ASP.NET applications and corresponding test projects in the same solution).

I find it reasonable to use this approach (hard-coded path) as a default so that simple solutions (single ASP.NET application) "just work". But the framework should also offer a mechanism/escape hatch to scale to multiple ASP.NET applications in a single solution.

mycarrysun commented 3 weeks ago

We're getting this on tons of our builds as well. Works on retry about 50% of the time.