Describe the bug
Since a few hours, the command vcpkg install ace:x64-windows is failing to complete correctly
Area for Triage:
Question, Bug, or Feature?:
Bug
Virtual environments affected
Expected behavior
The ace:x64-windows port should be installed correctly.
Actual behavior
A description with steps to reproduce the issue. If your have a public example or repo to share,
please provide the link.
Run:
~
vcpkg install ace:x64-windows
~
See https://github.com/traversaro/reproduce-ace-vcpkg-github-actions-fails for a minimal reproducible example.
Interestingly, this was working fine as of 12 hours ago, and is working fine if vcpkg is used on our local laptops. Furthermore, the failure is present even on old vcpkg tags.
Hello, @traversaro
Today we have updated Windows Server 2019 to the latest version of Visual Studio 16.5.0+29911.84. Looks like something is incompatible with the VS 2019 16.5 and will be fixed in 16.6 - https://developercommunity.visualstudio.com/content/problem/954522/internal-compiler-error-1925286104.html.
Maybe ugly workaround will help:
- name: vcpkg
run: |
Remove-Item -Path "${env:ProgramFiles(x86)}\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.25.28610" -Force -Recurse
vcpkg install ace:x64-windows
Thanks a lot @al-cheb . I tried your workaround, but it seems that removing that directory prevents us to compile vcpkg at all: https://github.com/iit-danieli-joint-lab/idjl-software-dependencies-vcpkg/runs/528765035?check_suite_focus=true .
Thanks a lot @al-cheb . I tried your workaround, but it seems that removing that directory prevents us to compile vcpkg at all: https://github.com/iit-danieli-joint-lab/idjl-software-dependencies-vcpkg/runs/528765035?check_suite_focus=true .
Actually first boostrapping vcpkg, and then deleting that directory seems to work fine (even if I am not sure why), thanks!
Interestingly the workaround does not work on a custom vcpkg, and it fails with (see https://github.com/iit-danieli-joint-lab/idjl-software-dependencies-vcpkg/runs/528902446):
~~~
Remove-Item : Cannot remove item C:\Program Files (x86)\Microsoft Visual
Studio\2019\Enterprise\VC\Tools\MSVC\14.25.28610\bin\Hostx64\x86\mspdbcore.dll: Access to the path 'mspdbcore.dll' is
denied.
At D:\a_temp\523feeaa-870a-450f-aae8-ed41f1806374.ps1:3 char:1
~~~
I'm trying to get a build compiled on https://dev.azure.com/ using a .yml file. The problem I've got is that I need it to run with VS2019 version 16.5, because I'm using a library which won't compile with a previous one. I'm able to compile it from VS2019 16.5 locally, but when compiling on Azure the problem occurs because it is not using 16.5 version of vs2019.
We are using Microsoft-hosted agent windows2019 (https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=yaml).
Is there a way to check what version of vs2019 is being used?
We are setting it as follows:
pool:
vmImage: 'windows-2019'
variables:
buildConfiguration: 'Release'
outputDirectory: '$(build.binariesDirectory)/$(buildConfiguration)'
testsOutputDirectory: '$(build.binariesDirectory)/Tests'
buildPlatform: 'x64'
vsVersion: '16.0'
Not sure if I'm doing something wrong.
@josejavieralvarez VS 16.5 rolling out process isn't finished yet, supposed to be done in 2 days
@josejavieralvarez VS16.5 rollout has been finished
The very latest visual studio still has the same issue, waiting for release with the fix.
It is mentioned that the issue will be resolved in Visual Studio 16.6. Currently, it is in preview. Not sure about release date
I am closing this issue because actually, bug is related to Visual Studio. Not the images itself so I don't see any actions items from our side.
As I mentioned previously, fix should be available in Visual Studio 16.6 that will be released soon. We will deliver this update as soon as it is available. You can track new updates in our image documentation.
@traversaro VS 16.6 was released and the issue is fixed there. We've started the Image Deployment today and it will take a few days to propagate to all the environments.
Thanks @miketimofeev . For the enviroments that still use VS 16.5, the issue has been solved in the master vcpkg branch thanks to https://github.com/microsoft/vcpkg/pull/11369 , so updating to a recent vcpkg commit (as done in https://github.com/traversaro/reproduce-ace-vcpkg-github-actions-fails/pull/2) solves the issue as well.