Resolve WDK/toolset selection by MSBuild version

[Nicholas L (nmlud21)]

Description

Related to ebpf-for-windows/#5483

Three related VS2026 readiness fixes, needed before the OneBranch pipelines move to the ltsc2025/vse2026 container.

wdk.props / Directory.Build.props: gate the WDK, Windows SDK, platform toolset and code analysis ruleset selection on $(MSBuildAssemblyVersion) instead of $(VisualStudioVersion), and give the fallbacks an explicit '< 18.0' condition instead of leaving them unconditional.

$(MSBuildAssemblyVersion) is always defined, is numeric, and reports the MSBuild major version ("17.0" / "18.0"). $(VisualStudioVersion) is only guaranteed when the build is driven by VS or a Developer Command Prompt. With the previous unconditional fallbacks, any value other than the exact expected one silently selected the VS2022 WDK, which under MSBuild 18 produces a mismatched pair (target platform 10.0.28000.0 with WDK 10.0.26100.4204) and fails with MSB4062 while loading Microsoft.DriverKit.Build.Tasks.18.0.dll, plus MSB8036 for the missing 10.0.28000.0 SDK.

Note $(MSBuildToolsVersion) is NOT a valid discriminator here: it evaluates to the string "Current" on both VS2022 and VS2026, so a '>= 18.0' test never distinguishes the two and can raise MSB4086.

scripts/onebranch/post-build.ps1: resolve the Visual Studio installation with vswhere rather than hardcoding
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise". VS 2026 installs to "...\18\Enterprise", so the literal path fails on the new container with a missing Microsoft.VisualStudio.DevShell.dll. The Enter-VsDevShell call also puts msbuild on PATH for the nuget packaging step that follows, so it is retained rather than removed.

Verified by evaluating wdk.props with MSBuild 18: 17.0 selects v143 + WDK 10.0.26100.4204, 18.0 selects v145 + WDK 10.0.28000.1839.

Testing

CI/CD

Documentation

No

Installation

No

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

Suppressed comments (2)

wdk.props:22

• The comment says the '< 18.0' fallbacks make an unexpected toolset version “fail loudly”, but the current conditions still select a WDK for any numeric MSBuildAssemblyVersion (e.g., 16.x, 19.x). This is misleading—either tighten the logic to only accept known major versions or adjust the wording to reflect that the goal is preventing MSBuild 18+ from silently falling back when VisualStudioVersion is unset.

         The fallbacks are explicitly conditioned on '< 18.0' rather than left unconditional so an
         unexpected toolset version fails loudly instead of silently selecting the VS2022 WDK. -->

scripts/onebranch/post-build.ps1:41

• Import-Module is invoked without validating that the DevShell DLL exists at the discovered VS install path, so failures can be harder to diagnose (and may be non-terminating depending on PowerShell settings). Add an explicit Test-Path check and import with -ErrorAction Stop to fail fast with a clear message.

Write-Host "Using Visual Studio installation at '$vsInstallPath'."
Import-Module (Join-Path $vsInstallPath "Common7\Tools\Microsoft.VisualStudio.DevShell.dll")
Enter-VsDevShell -VsInstallPath $vsInstallPath -DevCmdArguments "-arch=x64 -host_arch=x64"