Skip to content
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

windows-latest uses 14.37 toolkit instead of 14.38 #9086

Closed
3 of 11 tasks
thomthom opened this issue Jan 2, 2024 · 6 comments
Closed
3 of 11 tasks

windows-latest uses 14.37 toolkit instead of 14.38 #9086

thomthom opened this issue Jan 2, 2024 · 6 comments

Comments

@thomthom
Copy link

thomthom commented Jan 2, 2024

Description

According to the Windows2022 image description the Visual Studio VC 14.38 toolkit should be available:
https://github.com/actions/runner-images/blob/main/images/windows/Windows2022-Readme.md

image

I have a Visual Studio 2022 project set to use v143 toolset (default, not locked to any version) and latest Windows SDK.

Locally this picks up VC 14.38.33130, but on the GitHub agent I'm getting 14.37.32822.

As seen in the logs:

ClCompile:
         C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.37.32822\bin\HostX86\x64\CL.exe

This particular project have warnings treated as errors and the std lib with 14.37.32822 will emit warnings (thus errors in my configuration).

My workflow is picking msbuild with the following setup:

    - name: Add MSBuild.exe to PATH
      uses: microsoft/setup-msbuild@v1.3
      with:
        vs-version: '[17.8,18.0)' # Version 17.*

It accepts Visual Studio 17.8 as a minimum version, but it's not picking the 14.38 toolkit that shipped with that version.

Platforms affected

  • Azure DevOps
  • GitHub Actions - Standard Runners
  • GitHub Actions - Larger Runners

Runner images affected

  • Ubuntu 20.04
  • Ubuntu 22.04
  • macOS 11
  • macOS 12
  • macOS 13
  • macOS 13 Arm64
  • Windows Server 2019
  • Windows Server 2022

Image version and build link

Version: 20231217.2.0

Is it regression?

unknown

Expected behavior

I would expect the latest VC (14.38) toolkit installed to be picked when my Visual Studio project is setup to use latest.

Actual behavior

I'm seeing that my build uses VC 14.37.

Repro steps

jobs:
  build-win:
    runs-on: windows-latest

    - name: Add MSBuild.exe to PATH
      uses: microsoft/setup-msbuild@v1.3
      with:
        vs-version: '[17.8,18.0)' # Version 17.*

    - uses: actions/checkout@v4

    - name: Build Binaries - Windows - Release
      shell: cmd
      run: msbuild Release.proj /maxcpucount:2 /p:RunCodeAnalysis=False

The project is not a public one.

@erik-bershel
Copy link
Contributor

erik-bershel commented Jan 2, 2024

Hey @thomthom! It's notorious issue of Visual Studio with multiple v143. Duplicate: #7867, #7832. Base thread. I may recommend to use https://github.com/marketplace/actions/setup-msvc-developer-command-prompt action to pin the latest toolset. Worked fine here #8891.

@thomthom
Copy link
Author

thomthom commented Jan 2, 2024

Ah! Thank you for the insight. This had me stomped for days both on Azure DevOps and GitHub Actions since I couldn't figure out why I wasn't seeing the errors locally.

I'll try that alternate action. Does it only lock to specific versions? No means of providing "14.38 or newer"? Or "newest". Seems a bit fragile to pin to an exact given how the agents keeps updating. Also, I can easily see myself forgetting to update the CI script when the project updates.

@erik-bershel
Copy link
Contributor

erik-bershel commented Jan 3, 2024

Does it only lock to specific versions?

There seems to be only one option that really works. When I tried to use something like "latest version from 14" which is the default behaviour, it itself didn't work correctly with the same error.

Also, I can easily see myself forgetting to update the CI script when the project updates.

Oh, how I understand you. Unfortunately, I don't have a more reasonable solution at the moment - this bug will really affect many runs. I think that sooner or later the guys from Visual Studio will solve this problem.

@thomthom
Copy link
Author

thomthom commented Jan 3, 2024

I understand. Is there a public open ticket to track that fix?

Also, how did you make use of that action to lock the toolset?

I commented out my microsoft/setup-msbuild step and replaced it with:

    - uses: TheMrMilchmann/setup-msvc-dev@v3
      with:
        arch: x64
        toolset: '14.38'

But when I run msbuild it's still using 14.37.

@erik-bershel
Copy link
Contributor

@thomthom

   - name: Setup MSVC dev command prompt
      uses: TheMrMilchmann/setup-msvc-dev@v3
      with:
        arch: x64
        toolset: 14.38.33130

@thomthom
Copy link
Author

thomthom commented Jan 3, 2024

hm.. it's still failing, even with full version. I also tried to move the action to the very top of the job in case something else earlier should affect things.

Could there be some caching issue in regard to choosing a kit version?

Additional context of my workflow:

jobs:
  build-win:
    runs-on: windows-latest

    steps:
    - name: Dump info
      run: |
        echo 'github.ref: ${{ github.ref }}'
        echo 'github.head_ref: ${{ github.head_ref }}'
        echo 'github.base_ref: ${{ github.base_ref }}'

    - name: Setup Ruby for use with actions
      uses: ruby/setup-ruby@v1
      with:
        ruby-version: '3.1' # Not needed with a .ruby-version file

    # https://github.com/actions/runner-images/issues/9086
    # - name: Add MSBuild.exe to PATH
    #   uses: microsoft/setup-msbuild@v1.3
    #   with:
    #     vs-version: '[17.8,18.0)' # Version 17.*

    - uses: TheMrMilchmann/setup-msvc-dev@v3
      with:
        arch: x64
        toolset: 14.38.33130

    - uses: actions/checkout@v4
      with:
        token: ${{ secrets.ACTION_PAT }}
        submodules: recursive

    - name: Build Binaries - Windows - Release
      working-directory: CExt
      shell: cmd
      run: msbuild Release.proj /maxcpucount:2 /p:RunCodeAnalysis=False

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants