Develop#1376
Merged
Merged
Conversation
- Add -RunMode parameter (Auto/WDK/NuGet/EWDK/Github) defaulting to Auto - Auto-detection priority order: NuGet -> EWDK -> WDK - Github mode: same as NuGet but suppresses opening the HTML report - Add Get-VsInstallationsWithWdk: uses vswhere.exe from its fixed ProgramFiles path to find VS installs with the Microsoft.Windows.DriverKit component - Add Select-VsInstallation: errors if none found, verbose-logs if one found, presents a numbered interactive menu if multiple found - Replace Initialize-DevShell glob-based blind pick with the new helpers - Remove GITHUB_REPOSITORY auto-detect branch; replace HTML open guard with buildEnv.IsGithubMode - Update comment-based help with -RunMode parameter docs and examples Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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>
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>
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>
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>
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>
- 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>
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>
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>
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>
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>
…ment Improve Build-Samples for Visual Studio detection
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.