@@ -53,12 +53,9 @@ Paths that belong to the agent or to the build output are deliberately **not** r
5353they do not move with the subtree :
5454
5555- ` $(Build.ArtifactStagingDirectory)` , `$(Pipeline.Workspace)`
56- - ` $(Agent.TempDirectory)` , `$(VCPKG_INSTALLATION_ROOT)`
56+ - ` $(Agent.TempDirectory)`
5757- ` $(buildOutDir)` , `$(buildOutDirAnyCpu)`, `$(artifactsDir)`, `$(packageLayoutDir)`
5858
59- `$(VCPKG_INSTALLATION_ROOT)` is the exception worth calling out : it is correctly *not* rooted, but a
60- consumer may not use the installation it points at. See `useAgentVcpkg` below.
61-
6259Nested template references need no help. Azure Pipelines resolves a `- template:` reference inside a
6360template file relative to *that file*, so the job templates find their siblings at any depth. Only
6461the entry point has to know where the subtree lives.
@@ -84,8 +81,7 @@ is neither a parameter nor a path in this directory.
8481**Pipeline variables.** None. `jobs-build.yml` sets what it needs at job scope — `solution`, so it
8582can be rooted, and `EnableDetectorVcpkg`, so Component Governance detects the vcpkg dependencies.
8683
87- **A Windows agent** with Visual Studio 2022 and vcpkg, exposing `VCPKG_INSTALLATION_ROOT`. The
88- Microsoft-hosted `windows-2025` image qualifies. **The `Test` and `BuildPowerShellModule` jobs need
84+ **A Windows agent** with Visual Studio 2022 and vcpkg. **The `Test` and `BuildPowerShellModule` jobs need
8985more than the `Build` job does — see "Agent requirements" below.**
9086
9187**Outbound network access.** The test jobs reach several public endpoints, which is worth checking
@@ -194,24 +190,6 @@ does not even build.
194190 /p:UseProdCLSIDs=false
195191` ` `
196192
197- # # `useAgentVcpkg`
198-
199- Defaults to `true`, matching the Microsoft-hosted images, where `VCPKG_INSTALLATION_ROOT` points at
200- a real vcpkg installation that this pipeline integrates and builds the native dependencies with.
201-
202- Set it to `false` when the consuming repository supplies vcpkg some other way — for example through
203- an MSBuild SDK that restores the ports itself. `VCPKG_INSTALLATION_ROOT` may well still be defined in
204- that case, since the agent image sets it, but nothing builds there. Two steps then become
205- meaningless and are dropped together :
206-
207- - *Enable Vcpkg Install*, which integrates an installation the build does not use.
208- - *Copy vcpkg logs*, which reads `$(VCPKG_INSTALLATION_ROOT)\buildtrees` — a directory that will not
209- exist, failing the job after a successful build.
210-
211- Dropping the log collection loses no real diagnostics : ` Build Solution` writes an MSBuild binary log
212- to `$(artifactsDir)\msbuild.binlog`, which is published with the rest of the build artifacts and
213- records the vcpkg invocation and its output.
214-
215193# # `releaseTagJob`
216194
217195` jobs-build.yml` stamps a build version obtained from a separate job. That job is named by the
0 commit comments