Repository navigation
Restore failing intermittently on build #36255
Description
Restore is failing intermittently
F:\workspace\_work\1\s\.dotnet\sdk\5.0.100-preview.5.20251.2\NuGet.targets(128,5): error : Cannot create a file when that file already exists. [F:\workspace\_work\1\s\src\libraries\restore\binplacePackages\binplacePackages.depproj]
##[error].dotnet\sdk\5.0.100-preview.5.20251.2\NuGet.targets(128,5): error : (NETCORE_ENGINEERING_TELEMETRY=Restore) Cannot create a file when that file already exists.
Looks like a race that is hitting the "Libraries Build Windows_NT allConfigurations x64 Debug" the most often.
Note: if you are looking into this bug make sure to look at all attempts of this leg. About 1/2 of the PRs here retried this failure and it succeeded on retry. Hence looking at the final state of the build will not display this error.
| Build | Kind | Job Name |
|---|---|---|
| 640103 | PR 36242 | Libraries Build Windows_NT allConfigurations x64 Debug |
| 637444 | PR 36150 | Libraries Build Windows_NT allConfigurations x64 Debug |
| 637444 | PR 36150 | Libraries Build Windows_NT allConfigurations x64 Debug |
| 637444 | PR 36150 | Libraries Build Windows_NT allConfigurations x64 Debug |
| 638863 | PR 36098 | Libraries Build Windows_NT allConfigurations x64 Debug |
| 638863 | PR 36098 | Libraries Build Windows_NT allConfigurations x64 Debug |
| 638849 | PR 36175 | Libraries Build Windows_NT allConfigurations x64 Debug |
| 638786 | Rolling | Libraries Build Windows_NT net472 x64 Release |
| 638313 | PR 36098 | Libraries Build Windows_NT allConfigurations x64 Debug |
| 638357 | PR 35366 | Libraries Build Windows_NT allConfigurations x64 Debug |
| 638198 | Rolling | Libraries Build Windows_NT allConfigurations x64 Release |
Activity
safern commentedon May 12, 2020
@ViktorHofer it seems like we have a race condition in allConfigurations. Since you're the "restore" expert and work on a bunch of NuGet features recently, could you take a look at this?
ViktorHofer commentedon May 14, 2020
The binlog shows that the project.assets.json file for one of the depproj's isn't TargetFramwork specific which it should be, hence the race:
cc @ericstj
ViktorHofer commentedon May 14, 2020
OK, this regressed with 43f948b, cc @Anipik
runtime/src/libraries/restore/Directory.Build.props
Line 6 in f53c156
IntermediateOutputPathbeing set in a props file. Even though it isn't recommended that the TargetFramework property is read before the project is load, we currently encode the TargetFramework in theIntermediateOutputPathfor depproj files.I will submit a hot-fix by bringing that property back for depproj files. The long-term fix is to get rid of per configuration restores by getting rid of our depproj files.
Make depproj intermediate output paths unique again
ericstj commentedon May 14, 2020
@ViktorHofer / @Anipik I thought we removed that? Depproj's shouldn't need per-configuration restore. That was really only needed when we were conditioning PackageReferences by Runtime. If we only condition on TargetFramework and then they can have single pass restore just like everything else.
ericstj commentedon May 14, 2020
I'm also supportive of just deleting them :)
ViktorHofer commentedon May 14, 2020
We are still conditioning on runtime in runtime.depproj.
Make depproj intermediate output paths unique again (#36451)
[Automated PR] master -> dev/infrastucture (#37086)