| Age | Commit message (Collapse) | Author |
|---|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
- 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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
