runtime: Build errors: install_force has not been created.
The full error:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(231,5): error MSB8065: Custom build for item "F:\workspace\_work\1\s\artifacts\obj\native\netcoreapp5.0-Windows_NT-Release-x86\CMakeFiles\01d9c98fded5d1e41907661a010b2e75\INSTALL_force.rule" succeeded, but specified output "f:\workspace\_work\1\s\artifacts\obj\native\netcoreapp5.0-windows_nt-release-x86\cmakefiles\install_force" has not been created. This may cause incremental build to work incorrectly. [F:\workspace\_work\1\s\artifacts\obj\native\netcoreapp5.0-Windows_NT-Release-x86\install.vcxproj] [F:\workspace\_work\1\s\src\libraries\Native\build-native.proj]
##[error]C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(231,5): error MSB8065: (NETCORE_ENGINEERING_TELEMETRY=Build) Custom build for item "F:\workspace\_work\1\s\artifacts\obj\native\netcoreapp5.0-Windows_NT-Release-x86\CMakeFiles\01d9c98fded5d1e41907661a010b2e75\INSTALL_force.rule" succeeded, but specified output "f:\workspace\_work\1\s\artifacts\obj\native\netcoreapp5.0-windows_nt-release-x86\cmakefiles\install_force" has not been created. This may cause incremental build to work incorrectly. [F:\workspace\_work\1\s\artifacts\obj\native\netcoreapp5.0-Windows_NT-Release-x86\install.vcxproj]
Saw this error in a several runs today: https://dev.azure.com/dnceng/public/_build/results?buildId=537120 https://dev.azure.com/dnceng/public/_build/results?buildId=537213
The symptoms match this old issue #32483, could cmake be downgraded on these machines?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 16 (16 by maintainers)
As @jkotas has said many times before, managing our underlying toolsets in a sane way is important, and not necessarily straightforward to do. Unfortunately the long term work is not currently funded due to other “10’s”, HOWEVER…
@mmitche and I spoke with @shawnro and we agreed that we (the infra team) should do more to proactively test by building key repos when updating toolsets (including Arcade). @jaredpar has been a big proponent of this, and we’re getting that effort going right away.
Merging https://github.com/dotnet/runtime/pull/32853 will fix official builds.
The Windows VS machines don’t actually have the correct version of CMake on them. The warning we’re seeing was introduced during the VS 16.x version cycle. CMake fixed the warning in the CMake generated scripts in 3.15.5. The version of VS on our build machines is > “version which introduced detecting and reporting the warning” but bundles a CMake < “version which fixes the new VS warning”.
We initially fixed this by disabling warnAsError on PR, CI, and official builds in #31909 and #31890 since that was easier than getting a new enough version of CMake globally installed on the build pool.
The VS Preview build pool now has VS versions which bundle a CMake >= “version which fixes the new VS warning”. So, the libraries build moved to the preview pool in #32626 for PR and CI, but accidentally didn’t move to the new pool for the official build. PR #32853 moves the libraries build in the official build to the preview pool.
To fix the optional ci legs, they should also move to the preview pool.
The reason I didn’t want to make the change for the optional ci legs immediately is that there’s been some discussion in #32853 about if we want to use different build pools for different legs.