Choco install visualstudio2017-workload-vctools no longer works on windows-2019

[collinpeters]

Cross-posting this from actions/runner-images#2857

I am having the same issue as the author there. Specifically that the install fails on the GitHub Actions Windows 2019 image which is itself unchanged.

Please see that issue for full details but I will copy/paste the error here.

WARNING: Found 2 still running Visual Studio installer processes:
WARNING: [436] vs_bootstrapper
WARNING: [3104] vs_setup_bootstrapper
WARNING: Waiting for the processes to finish...
visualstudio2017buildtools has been installed.
  visualstudio2017buildtools may be able to be automatically uninstalled.
 The install of visualstudio2017buildtools was successful.
  Software install location not explicitly set, could be in package or
  default install location if installer.

visualstudio2017-workload-vctools v1.3.2 [Approved]
visualstudio2017-workload-vctools package files install completed. Performing other installation steps.
ERROR: Unable to detect any supported Visual Studio product. You may try passing --installPath or both --productId and --channelId parameters.
The install of visualstudio2017-workload-vctools was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\visualstudio2017-workload-vctools\tools\ChocolateyInstall.ps1'.
 See log for details.

Chocolatey installed 5/6 packages. 1 packages failed.
 See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).

Installed:
 - visualstudio2017buildtools v15.9.33.0
 - dotnetfx v4.8.0.20190930
 - chocolatey-visualstudio.extension v1.9.0
 - visualstudio-installer v2.0.1
 - chocolatey-dotnetfx.extension v1.0.1

Failures
 - visualstudio2017-workload-vctools (exited -1) - Error while running 'C:\ProgramData\chocolatey\lib\visualstudio2017-workload-vctools\tools\ChocolateyInstall.ps1'.

[jberezanski]

As I wrote in that issue. in order to try to determine the cause, I need:

• the full Chocolatey log: $Env:ChocolateyInstall\logs\chocolatey.log
• the Visual Studio log files (there will be a lot of them): $Env:TEMP\chocolatey\dd_*.log

[collinpeters]

I'm not a Windows guy but I just used GitHub Actions using the workflow file in the other ticket and it looks like the run has all the files you need.

Failed run with artifact attached with logs: https://github.com/collinpeters/win-vs-test/actions/runs/643660346

For reference the workflow file is:

# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the action will run. 
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

  workflow_dispatch:

jobs:
  build:
    runs-on: windows-latest

    steps:
      - uses: actions/checkout@v2

      - name: Env
        run: |
          gci env:* | sort-object name

      - name: Set up Visual C Build Tools Workload for Visual Studio 2017 Build Tools
        run: choco install visualstudio2017-workload-vctools

      - name: Upload artifacts
        uses: actions/upload-artifact@v2
        if: failure()
        with:
          path: |
            C:\ProgramData\chocolatey\logs
            C:\Users\runneradmin\AppData\Local\Temp\chocolatey\dd_*.log

[jberezanski]

Oh dear, this is a tough one.

The image you are using already contains a version of Visual Studio 2019 Enterprise. Both VS 2017 and 2019 are serviced (installed/updated) by the same helper program, the Visual Studio Installer. The version of the Visual Studio Installer present in the image is sufficiently new to support the newest VS 2017, but is older than required for the newest VS 2019. When the package for VS 2017 invokes the Installer, telling it to install VS 2017, the Installer ignores that request at first*, looks at the already installed Visual Studio instances, sees the VS 2019 Enterprise, checks the Installer version required by the newest VS 2019 update, decides that its own version is too old and refuses to install anything. To add insult to injury, it returns a "success" exit code (0), so the package does not even know the installation of VS 2017 was not done.

* - to make matters even worse, my tests show that this is nondeterministic - the check for updates to already installed VS instances seems to happen asynchronously (on a background thread?) in the VS Installer, so sometimes the installation of VS 2017 will proceed sufficiently quickly to win the race and finish successfully before the VS Installer detects the VS 2019 update and decides it is outdated, and at other times the 2019 update detection will run before the Installer starts installing VS 2017 and the Installer refuses to perform the installation.

Evidence:

chocolatey.log
2021-03-11 17:55:38,616 3512 [DEBUG] - Using VSSetup to detect Visual Studio instances
2021-03-11 17:55:38,886 3512 [DEBUG] - Found product instance: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise

2021-03-11 17:55:39,053 3512 [INFO ] - VERBOSE: Trying to determine the required installer and engine version from the manifests

2021-03-11 17:55:39,090 3512 [INFO ] - VERBOSE: Obtaining the manifest file for url 'https://aka.ms/vs/15/release/channel' (channel manifest)

2021-03-11 17:55:43,164 3512 [INFO ] - VERBOSE: Required installer version determined from the channel manifest: '1.18.1116.1211'

2021-03-11 17:55:46,984 3512 [INFO ] - VERBOSE: Required engine version determined from the component manifest: '1.18.1063.29791'

2021-03-11 17:55:47,491 3512 [INFO ] - VERBOSE: Visual Studio Installer version 2.8.3077.1211 (engine version 2.8.3267.30329) is present (C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installer.exe).
2021-03-11 17:55:47,613 3512 [DEBUG] - The Visual Studio Installer is already present
2021-03-11 17:55:47,616 3512 [DEBUG] - The existing Visual Studio Installer version is greater than requested (no update required)
2021-03-11 17:55:47,616 3512 [DEBUG] - The existing Visual Studio Installer engine version is greater than requested (no update required)


dd_client_20210311175612.log
2021-03-11T17:56:39 : Verbose : The installer has an update required
2021-03-11T17:56:39 : Verbose : Preparing to perform the update
2021-03-11T17:56:39 : Error : Failed to get product summaries. [installerId: SetupEngine, error: Please update Visual Studio Installer before proceeding. at Microsoft.VisualStudio.Setup.UpdateRequiredException: https://download.visualstudio.microsoft.com/download/pr/308e891b-f15e-43d8-8cc1-0e41f4962d4b/5f57c993cb10d795278ad0c11a642d3af4b1ba2a36e07346108beff937796f0b/vs_Setup.exe
   at Microsoft.VisualStudio.Setup.ProductsProviderService.GetProductSummaries()]

chocolatey.log
2021-03-11 17:56:40,748 3512 [DEBUG] - Command ["C:\Users\runneradmin\AppData\Local\Temp\chocolatey\visualstudio2017buildtools\15.9.34.0\vs_BuildTools.exe" --quiet --norestart --wait] exited with '0'.

I'm not sure how to tackle this problem yet. The current packages already do know how to detect the fact that the VS Installer is outdated and are able to update it, but this logic is currently based on the requirements of the VS product being installed by the package. So the package for VS 2017 Build Tools knows how to obtain the minimum VS Installer version required for VS 2017 Build Tools - but not for other VS products which may already be installed on the machine... I need to think about it.

Meanwhile, you may try this workaround: in your workflow, update the already installed Visual Studio 2019 Enterprise first. This will have the side effect of updating the VS Installer to the newest version required by VS 2019, so the problem with VS 2017 should not appear. In other words:

      - name: Update Visual Studio 2019 Enterprise to work around Visual Studio Installer quirks
        run: choco upgrade visualstudio2019enterprise

      - name: Set up Visual C Build Tools Workload for Visual Studio 2017 Build Tools
        run: choco install visualstudio2017-workload-vctools

[jberezanski]

It seems that the VS Installer, before it quits with exit code 0, launches a separate process (which eventually lanuches additional processes) in order to 1) updates the installer, 2) perform the originally requested action (install 2017 Build Tools). The problem is, this is done in separate processes which the original bootstrapper process (started by the package) does not wait upon, ignoring the --wait switch (#7 strikes again).

The packages do try to handle this situation by detecting other VS Installer processes which are still running and waiting for them to finish. Unfortunately, the VS Installer internal architecture has changed with VS 2019 16.9 and it now uses a new process, which the packages do not know about.
Adding logic to detect this additional process to the packages should be easy to implement. But it will only solve a part of the problem - it will not work for workload packages, because they call the VS Installer in a different way than the product packages do. Your use case should be handled correctly, though (because the Build Tools product package is installed first, as a dependency).

[aminya]

I think I found the issue. The problem is that $Path, $TMP, and $TEMP environment variables are set inside GitHub Actions (due to msys64 installation). Unsetting these fixes this error:

Item has already been added. Key in dictionary: 'Path'  Key being added: 'PATH'

or other similar variable issues

# backup variables 
$env:Path=""
$env:TEMP=""
$env:TMP=""
# run installation 
# restore the variables

[d0ugparker]

Building on the March 13, 2021 comment.

    run: choco upgrade visualstudio2019enterprise
    run: choco install visualstudio2017-workload-vctools

Both were reportedly installed, but there were ugly error messages accompanying the splash screen on the vctools part.

chocolatey.log

DP

[ndevenish]

I've had a very similar issue on the basic Amazon EC2 windows 2019 and 2022 AMI images. Apparently the choco upgrade step has resolved the problem.

[maxbergs]

@ndevenish choco upgrade what?

[ndevenish]

@ndevenish choco upgrade what?

The choco upgrade visualstudio2019enterprise from the post directly above mine, #97 (comment)