-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The Action fails with "Could not setup Developer Command Prompt" #1
Comments
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 |
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. |
Here's the debug logging:
For this configuration:
|
If I change the configuration to pick a newer version of the toolset, eg Is the problem that 9.0 (Visual Studio 2008) is too old and not supported? |
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? |
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., 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. |
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/setup-msbuild@v1.0.0
with:
vs-version: [9.0]
- uses: ilammy/msvc-dev-cmd@v1.2.0
with:
toolset: 9.0 @ilammy, it looks like |
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/setup-msbuild@v1.0.0
with:
vs-version: 9.0 but I get an error on: - uses: ilammy/msvc-dev-cmd@v1.2.0
with:
toolset: 9.0 @ilammy, would you be able to support 9.0 for building python 2.7 packages? |
@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/msvc-dev-cmd@v1.3.0 Unfortunately, I don't really have Windows machines at hand to check it out myself. Though, I'll look at whatever |
@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. > 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?
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. |
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 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. |
Attempting to use the action like this:
results in a failure:
The text was updated successfully, but these errors were encountered: