Open lippinio opened 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.
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.
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.
We're getting this on tons of our builds as well. Works on retry about 50% of the time.
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