msvc-dev-cmd icon indicating copy to clipboard operation
msvc-dev-cmd copied to clipboard

Older toolset with windows-2022

Open black-sliver opened this issue 6 months ago • 3 comments

You may not know the answer, but I thought I'd still ask.

Previously, we were able to install older toolsets by running vs_BuildTools.exe with --add <component>.

With VS2022, it looks like toolset v141 should be available and the following succeeds on windows-2022

          Invoke-WebRequest -Uri "https://aka.ms/vs/17/release/vs_BuildTools.exe" -OutFile "vs_BuildTools.exe"
          Start-Process -FilePath ./vs_BuildTools.exe -ArgumentList "--add", "Microsoft.VisualStudio.Component.VC.v141.x86.x64", "--quiet", "--norestart", "--force", "--wait" -Wait -PassThru

Running this action like so

        uses: ilammy/msvc-dev-cmd@v1
        if: |
          matrix.sln == 'vs2017'
        with:
          arch: win32
          toolset: '14.1'

also does not return an error, however if I want to use nmake, that's not found in PATH.

Here is the failing action: https://github.com/black-sliver/lua-apclientpp/actions/runs/16338050529/job/46154064455 If you unfold the failing step, you see which env vars were actually set by msvc-dev-cmd to what.

Do you have any idea what I might be missing? My assumption right now is that the toolset v141 does not ship a full dev environment in vs2022 and so does not work from command line, but it could also be that msvc-dev-cmd does not correctly enter the environment?

The build has 2 steps, one is using nmake and one is using msbuild. Neither seems to be working with v141.

There are kind of 2 reason why I would want to use v141:

  • the .sln/proj is vs2017/v141 and I don't really want to "upgrade" it every other year (originally we were using vs2015/v140)
  • the thing I am building is a DLL that can be loaded by various EXEs and while toolset/libc is back compatible in 14.x, it is not forward compatible, so I would like to target a 14.x that is as old as possible to maximize compatibility

(Side note: The whole windows-2022 and vs2022 situation makes me want to move away from using any Microsoft tools: Various things were broken (and some still are) and all available Windows images ship the same VS now, so there is no downgrade path. I think at this point, my time would've been better spent trying to figure out if we can build OpenSSL with a different toolchain.)

black-sliver avatar Jul 17 '25 07:07 black-sliver

really need this to build some old projects

Evilmass avatar Jul 29 '25 06:07 Evilmass

I found a solution

name: citra-ci

on:
  push:
    branches: [ "*" ]
    tags: [ "*" ]
  workflow_dispatch:

jobs:
  windows:
    runs-on: windows-2022
    steps:
      - uses: actions/checkout@v4
        with:
          submodules: recursive
      - name: Set up cache
        uses: actions/cache@v4
        with:
          path: ~/.buildcache
          key: ${{ runner.os }}-win-${{ github.sha }}
          restore-keys: |
            ${{ runner.os }}-win-
      - name: install MSVC 2017
        shell: pwsh
        run: |
          $vs_url = "https://aka.ms/vs/15/release/vs_BuildTools.exe"
          Invoke-WebRequest -Uri $vs_url -OutFile "vs_buildtools.exe"
          if (-not (Test-Path "vs_buildtools.exe")) {
              Write-Error "Failed to download VS Build Tools"
              exit 1
          }
          $components = @(
            "Microsoft.VisualStudio.Workload.VCTools",
            "Microsoft.VisualStudio.Component.Windows10SDK.19041",
            "Microsoft.VisualStudio.Component.VC.v141.x86.x64",
            "Microsoft.VisualStudio.Component.VC.CMake.Project"
          )
          $componentArgs = ($components | ForEach-Object { "--add $_" }) -join " "
          $installCmd = ".\vs_buildtools.exe --quiet --norestart --force --wait --installPath C:\BuildTools $componentArgs"
          Start-Process -FilePath ".\vs_buildtools.exe" -ArgumentList $installCmd.Split() -Wait -PassThru
      - name: Check components
        shell: cmd
        run: |
          call "C:\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" x64
          cl
          cmake -version
          msbuild -version

check components logs

call "C:\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" x64 is necessary, and the cmake -T parameter is applicable

      - name: Build
        shell: cmd
        run: |
          call "C:\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" x64
          mkdir build && cd build
          cmake .. -G "Visual Studio 17 2022" -A x64 -T v141 ^
            -DCMAKE_BUILD_TYPE=Release ^
            -DCITRA_USE_BUNDLED_QT=1 ^
            -DCITRA_USE_BUNDLED_SDL2=1 ^
            -DENABLE_QT_TRANSLATION=ON ^
            -DCITRA_ENABLE_COMPATIBILITY_REPORTING=OFF ^
            -DUSE_DISCORD_PRESENCE=OFF ^
            -DENABLE_FFMPEG_VIDEO_DUMPER=ON ^
            -DENABLE_MF=ON
          cd ..
          msbuild citra.sln -property:Configuration=Release,Platform=x64 -maxCpuCount -target:Rebuild

build logs

Evilmass avatar Jul 29 '25 09:07 Evilmass

Amazing that MSVC 141 works for cmake but not for sln xD

I may look into this (directly specifying the compiler) but it would be amazing if there was a working v141 dev cmd promt rather than having to frankenstein something.

black-sliver avatar Jul 29 '25 09:07 black-sliver