windows-driver-samples.git, branch user/jvalesmena/build-environment

docs: streamline Building-Locally.md and fix typos

2026-04-07T22:29:58Z

Simplify prerequisites with environment-specific requisites section, remove redundant build commands per WDK type since the script auto-detects. Fix typo (Enviroment), casing (powershell), formatting. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

fix: detect WDK component in both full VS and Build Tools

2026-04-07T21:55:32Z

Full VS editions register the WDK as 'Microsoft.Windows.DriverKit', while Build Tools uses 'Component.Microsoft.Windows.DriverKit.BuildTools'. Query vswhere for both component IDs and deduplicate by install path so machines with only VS Build Tools are properly detected. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

fix: include Build Tools in vswhere product search

2026-04-07T21:48:52Z

vswhere's default product filter only includes Community, Professional, and Enterprise editions. Build Tools (Microsoft.VisualStudio.Product.BuildTools) requires '-products *' to be discovered. Without this, machines with only VS Build Tools installed would fail detection. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

fix: use Write-Host for VS selection menu so it displays to console

2026-04-03T20:06:55Z

Write-Output goes to stdout and gets captured by the pipeline, making the menu invisible. Write-Host writes directly to the console, ensuring users see the numbered options. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

refactor: consolidate VS detection into Resolve-BuildEnvironment

2026-04-02T22:36:34Z

- Remove Initialize-DevShell as a separate step; VS Dev Shell setup is now fully owned by Resolve-BuildEnvironment alongside mode detection. This eliminates the ordering problem where vswhere ran unconditionally before knowing whether the environment was EWDK (which needs no VS). - Fix EWDK regression: EWDK mode now returns early before any vswhere or Dev Shell logic is invoked. - Fix Auto+WDK from plain terminal: the old isWdk guard required UCRTVersion to be set before the Dev Shell was opened, making Auto detection fail on a clean terminal. Removed the guard; the code now falls through to Dev Shell setup and validates UCRTVersion afterward. - Fix VSINSTALLDIR trailing-backslash mismatch: when the Dev Shell is already active, VSINSTALLDIR ends with '\' while vswhere installationPath does not. Added TrimEnd('\') on both sides before comparing. - Renumber Build-Samples.ps1 step comments (old Step 5 'Detect Build Environment' merged into Step 1; remaining steps renumbered). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

docs: rewrite Building-Locally.md for clarity

2026-04-02T21:45:56Z

Restructure the document into a logical flow: 1. Prerequisites — tools (winget), WDK download link, repo clone 2. Building the Samples — NuGet, EWDK, WDK MSI/winget subsections with -RunMode intro 3. Expected Output — build plan and completion summary 4. Ways to Run — common Build-Samples.ps1 invocations 5. Additional Notes — pre-release WDK, usbview .NET packs, NuGet version pinning Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

fix: prioritize EWDK over NuGet in auto-detection

2026-04-02T17:00:58Z

The packages\ folder is a passive disk artifact that persists between builds. If someone runs the script from inside an EWDK command prompt while packages\ exists from a previous NuGet restore, Auto mode would incorrectly select NuGet and then fail trying to find a VS installation that may not be present in an EWDK-only setup. EWDK is now checked first because \ being set is an active, explicit signal that the user is intentionally in the EWDK environment. Auto detection order is now: EWDK -> NuGet -> WDK Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

refactor: remove Github RunMode

2026-03-31T23:22:25Z

NuGet mode works correctly for GitHub Actions (the HTML open is already guarded by [Environment]::UserInteractive which is false on CI runners). The Github mode was redundant and is removed to keep the interface clean. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

fix: detect WDK component version from the selected VS installation

2026-03-31T23:22:25Z

Previously, WdkVsComponentVersion was read from the global ProgramData package cache, which is shared across all VS installations and could return the wrong version when multiple installs are present. - Add -include packages to the vswhere call in Get-VsInstallationsWithWdk so each returned installation includes its WdkVsComponentVersion - Initialize-DevShell now returns the selected installation object - Resolve-BuildEnvironment accepts an optional -VsInstallation parameter; when provided it reuses the already-selected install (no second prompt); when absent (Dev Shell was pre-active) it calls Select-VsInstallation once - Build-Samples.ps1 threads the result of Initialize-DevShell through to Resolve-BuildEnvironment Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Extract environment helper functions into BuildEnvironment.ps1

2026-03-31T23:22:25Z

Move Get-VsInstallationsWithWdk, Select-VsInstallation, Initialize-DevShell, Assert-MsBuildAvailable, and Resolve-BuildEnvironment out of Build-Samples.ps1 into a new BuildEnvironment.ps1 helper file. Build-Samples.ps1 dot-sources it via PSScriptRoot, consistent with the existing ListAllSamples.ps1 pattern. Reduces Build-Samples.ps1 from 733 to 565 lines with no behaviour change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>