The Action fails with "Could not setup Developer Command Prompt"

[exarkun]

Attempting to use the action like this:

name: Python package
on: [push]
jobs:
  build:
    runs-on: "windows-latest"
    strategy:
      matrix:
        python-version:
          - "2.7"
    steps:
    - uses: ilammy/msvc-dev-cmd@v1

results in a failure:

##[error]Could not setup Developer Command Prompt
##[error]Node run failed with exit code 1

[ilammy]

Hm... I admit this action was not maintained well. For example, it lacked scheduled builds to verify that it's still working, and lacked ‘integration’ testing of the released versions. I’ll add those shortly to be notified about any breakage in the future. (Though, given how simple it is, this action unlikely to seriously break.)

Now... it’s really strange that you see it failing. I‘d expect some environment change and bit rot, or the influence of Python 2.7 which was recently EOLed. But that does not seem to be the case. I’ve checked the exact workflow that you provided too and it seems to work fine.

Could you please link a repo that fails the build? Enabled debug logging may also help: you need to define an Action secret named ACTIONS_STEP_DEBUG with value true to enable it.

[exarkun]

Hi. Thanks for the quick reply!

The project where I'm trying to use this action is https://github.com/LeastAuthority/magic-folder and there is an open PR that introduces the usage at tahoe-lafs/magic-folder#18.

Looking through the revisions to find the best workflow run demonstrating the issue, I see I might have over-simplified the example in the issue description here.

https://github.com/LeastAuthority/magic-folder/runs/438948109 is a workflow run using a configuration closest to what I posted above and where the step succeeded.

The problem actually came up when I tried to choose a specific version. https://github.com/LeastAuthority/magic-folder/blob/321796bd068af1f1729cd1a3aedcd75d9216ca80/.github/workflows/pythonpackage.yml produced the failure I described above, visible at https://github.com/LeastAuthority/magic-folder/runs/438969918.

I'll try enabling debug logging and see if that reveals anything interesting. Sorry about the initially incorrect report.

[exarkun]

Here's the debug logging:

##[debug]Evaluating condition for step: 'Run ilammy/msvc-dev-cmd@v1'
##[debug]Parsing expression: <success()>
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: Run ilammy/msvc-dev-cmd@v1
##[debug]Loading inputs
##[debug]Loading env
Run ilammy/msvc-dev-cmd@v1
##[debug]Arguments: x64 -vcvars_ver=9
##[debug]Writing helper file: C:\Users\runneradmin\msvc-dev-cmd.bat
##[debug]Executing helper
##[debug]Helper failed: Command failed: cmd.exe /q /c C:\Users\runneradmin\msvc-dev-cmd.bat
##[debug]
##[debug]Removing helper
##[error]Could not setup Developer Command Prompt
##[error]Node run failed with exit code 1
##[debug]Finishing: Run ilammy/msvc-dev-cmd@v1

For this configuration:

name: Python package

on: [push]

jobs:
  build:

    runs-on: "windows-latest"
    strategy:
      matrix:
        python-version:
          - "2.7"

    steps:
    - uses: actions/checkout@v2
    # Get MS VC++ 9                                                                                                                                                                           
    - uses: ilammy/msvc-dev-cmd@v1
      with:
        toolset: "9"

[exarkun]

If I change the configuration to pick a newer version of the toolset, eg toolset: "14.0", then it succeeds. :/

Is the problem that 9.0 (Visual Studio 2008) is too old and not supported?

[exarkun]

Maybe I misunderstood what this action is for. Looking at the debug output and some of the code, it looks like it is not for installing Visual Studio. Instead, it is for activating one of the existing installations that is already included in the GitHub Windows environment. Is that right?

[ilammy]

Oh!.. Yeah... You are right: this action is just a thin wrapper over Visual Studio's batch file. It can only activate the environment already included in GitHub Action runner. It does not install the specified toolset version, like some other actions do (e.g., actions-rs/toolchain for Rust toolchains).

Well, that’s mostly because I have no clue how to properly download and install Visual Studio from a script. For some reason I doubt it can be automated easily, especially for older ones. I’m also not aware of actions that do that, sadly.

[ajfriend]

It looks like I had the same problem (compiling for python 2.7), but was able to solve it with the following:

- name: Add msbuild to PATH
  uses: microsoft/[email protected]
    with:
      vs-version: [9.0]

- uses: ilammy/[email protected]
  with:
    toolset: 9.0

@ilammy, it looks like microsoft/setup-msbuild would solve the issue you mentioned around installing Visual Studio from a script.

[ajfriend]

Actually, that didn't work; it just failed silently.

It seems like i can install msbuild ok with

- name: Add msbuild to PATH
  uses: microsoft/[email protected]
  with:
    vs-version: 9.0

but I get an error on:

- uses: ilammy/[email protected]
  with:
    toolset: 9.0

@ilammy, would you be able to support 9.0 for building python 2.7 packages?

[ilammy]

@ajfriend, @exarkun, I've published a new version which could probably support some older versions of Visual Studio. Could you please try it out?

- uses: ilammy/[email protected]

Unfortunately, I don't really have Windows machines at hand to check it out myself. Though, I'll look at whatever microsoft/setup-msbuild does. Maybe that tool is a better choice, given that Microsoft knows better how to support Microsoft tools...

[pzhlkj6612]

@ajfriend Hi.

The action microsoft/setup-msbuild is used to find the parent directory of MSBuild.exe by calling vswhere.exe (source code). It has nothing to do with the MSVC toolset.
The vs-version parameter of that action is a version range of Visual Studio (when calling vswhere.exe, its value is after the -version parameter).

> vswhere -?
Visual Studio Locator version 2.7.1+180c706d56 [query version 2.6.2111.5687]
Copyright (C) Microsoft Corporation. All rights reserved.

Usage:  [options]

Selection options:
...
  -version arg   A version range for instances to find. Example: [15.0,16.0) will find versions 15.*.
...

In most cases, vswhere.exe is located in "C:\Program Files (x86)\Microsoft Visual Studio\Installer".

What if we only pass a version number instead of a range?

Examples

...

... The version range syntax is the same as that used by both VSIX and NuGet, and described below:

• ...
• A single version number, e.g. 1.2, means that version or newer. It's equivalent to [1.2, ).

https://github.com/microsoft/vswhere/wiki/Examples

I did some tests on a local computer with Visual Studio 2019 (16.6.30320.27) community edition installed:

> vswhere
Visual Studio Locator version 2.7.1+180c706d56 [query version 2.6.2111.5687]
Copyright (C) Microsoft Corporation. All rights reserved.

instanceId: 6a605317
installDate: 20/07/21 21:25:20
installationName: VisualStudio/16.6.5+30320.27
installationPath: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
installationVersion: 16.6.30320.27
...

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 0
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 9
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 9.0
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 9.0.0
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 9.0.0.0
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 15
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 16
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 16.6
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 16.6.30319
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 16.6.30320
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 16.6.30320.26
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 16.6.30320.27
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 16.6.30320.28

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 16.6.30321

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 16.7

> vswhere -products * -requires Microsoft.Component.MSBuild -property installationPath -latest -version 17

>

This is why you can specifiy "9.0" as the version of Visual Studio, and everything works fine even though Visual Studio 2008 (9.0) is not installed on the Windows 2016 runners or the Windows 2019 runners of GitHub Actions.

[pzhlkj6612]

More info:

For the MSVC toolset, Visual Studio 2019 supports up to v142, while Visual Studio 2017 only supports up to v141. If you want to use MSVC v142 with VS 2017, you will encounter some errors like this: c++ - How to install (v142) Build tools in Visual studio - Stack Overflow

For the GitHub Actions runners, we can learn which components have been installed by reading the documentation. Search "Microsoft.VisualStudio.Component.VC" in Windows2016-Readme.md and Windows2019-Readme.md
, and you will get what you need.

I don't know if it is possible to install a too old toolset on the runner (e.g., 9.0), but I believe that Microsoft discourages developers from doing this.