fix: resolve MSVC toolset mismatch causing DLL load failure on Windo…

[kjdev]

…ws CI

Summary by CodeRabbit

• Bug Fixes
  • Improved Windows build reliability by better selecting the MSVC toolset when one is explicitly provided, with a safer fallback when it is not available.
  • Updated the Windows CI setup to initialize the Visual Studio developer environment more consistently, helping builds run more smoothly on supported toolset versions.

[coderabbitai]

📝 Walkthrough

Walkthrough

The Windows CI workflow gains explicit contents: read permissions and a new step that sets up the MSVC Developer Command Prompt via ilammy/msvc-dev-cmd, pinned to toolset 14.44 for vs17 builds. build.ps1 is updated to use a VCToolsVersion environment variable directly as the selected toolset when present, bypassing vswhere discovery.

Windows CI MSVC Toolset Pinning

Layer / File(s)	Summary
CI permissions and MSVC dev cmd step .github/workflows/windows.yaml	Adds contents: read permission to the ci job and inserts a Set up MSVC Developer Command Prompt step using ilammy/msvc-dev-cmd pinned to toolset 14.44, running only for vs17 matrix entries.
VCToolsVersion env var override in build.ps1 .github/workflows/build.ps1	Adds a conditional branch: if $env:VCToolsVersion is set, it trims and assigns that value as $selectedToolset, skipping the existing vswhere-based discovery path.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐇 A toolset was lost in the vswhere maze,
So I pinned it to 14.44 these days.
With a env var check and a YAML new line,
The MSVC command prompt works just fine.
No more hunting — the rabbit says: divine! 🎉

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title matches the PR's main fix: resolving an MSVC toolset mismatch behind the Windows DLL load failure.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/ci-windows

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/build.ps1:
- Around line 18-20: The override path in the build script bypasses the
fast-fail availability check, so a stale or injected VCToolsVersion can reach
phpsdk-starter.bat and fail later with a weaker error. In the build.ps1 flow
around the VCToolsVersion selection, keep the existing toolset availability
guard for the override branch by validating the selected toolset before using
it, and preserve the current fallback behavior when no override is set.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 3dd84a55-24ab-4a30-a210-93f616d0b1cc

📥 Commits

Reviewing files that changed from the base of the PR and between 3e35f34 and 41e24b0.

📒 Files selected for processing (2)

• .github/workflows/build.ps1
• .github/workflows/windows.yaml

[coderabbitai]

🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

Keep the fast-fail availability check on the override path.

Any non-empty VCToolsVersion now bypasses the "toolset not available" guard and is passed straight to phpsdk-starter.bat. A stale or manually injected value will fail later with a less actionable error.

Suggested fix

 if ($env:VCToolsVersion) {
     $selectedToolset = $env:VCToolsVersion.Trim()
+    $MSVCDirectory = vswhere -latest -products * -find "VC\Tools\MSVC"
+    if (-not $selectedToolset -or -not (Test-Path (Join-Path $MSVCDirectory $selectedToolset))) {
+        throw "toolset not available"
+    }
 } else {
     $MSVCDirectory = vswhere -latest -products * -find "VC\Tools\MSVC"

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	if ($env:VCToolsVersion) {
	$selectedToolset = $env:VCToolsVersion.Trim()
	} else {
	if ($env:VCToolsVersion) {
	$selectedToolset = $env:VCToolsVersion.Trim()
	$MSVCDirectory = vswhere -latest -products * -find "VC\Tools\MSVC"
	if (-not $selectedToolset -or -not (Test-Path (Join-Path $MSVCDirectory $selectedToolset))) {
	throw "toolset not available"
	}
	} else {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/build.ps1 around lines 18 - 20, The override path in the
build script bypasses the fast-fail availability check, so a stale or injected
VCToolsVersion can reach phpsdk-starter.bat and fail later with a weaker error.
In the build.ps1 flow around the VCToolsVersion selection, keep the existing
toolset availability guard for the override branch by validating the selected
toolset before using it, and preserve the current fallback behavior when no
override is set.