Replace Microbuild with 1ES PT + ESRP

[mjcheetham]

Microbuild doesn't give us as much control as we'd like over our build images, pool admin, and signing process. Since moving to NativeAOT, the SignFiles target of Microbuild runs at the wrong time.

The fact we're using Microbuild is a holdover from the organisational parentage of the then GVFS team back in 2017/2018. The Git Client team also maintains Git Credential Manager and Microsoft Git, where we use regular 1ES PT builds and ESRP directly for signing. Let's standardise on this model.

Also, whilst we're at it, we can add automatic GitHub release publishing (as draft)! See an example of a run with this branch:

This PR is probably easiest to review commit by commit, and referencing microsoft/git and GCM's build pipelines for prior art.

[Copilot]

Pull request overview

This PR replaces MicroBuild-based release signing with a 1ES Pipeline Template + ESRP signing flow and adds draft GitHub Release publishing for release builds.

Changes:

• Removes MicroBuild package/signing metadata from project files.
• Adds ESRP signing template and Azure release pipeline stages for build, signing, artifact staging, and GitHub release creation.
• Adds CI helper scripts for installing VS C++ workload and enabling ProjFS.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
scripts/Build.bat	Fails the build when VS MSBuild is unavailable.
GVFS/GVFS.Payload/layout.bat	Removes C++ code-analysis marker files from payload output.
GVFS/GVFS.Payload/GVFS.Payload.csproj	Removes MicroBuild signing integration from payload generation.
GVFS/GVFS.Installers/GVFS.Installers.csproj	Removes MicroBuild signing and allows installer creation to be skipped.
GVFS/FastFetch/FastFetch.csproj	Removes MicroBuild signing integration.
Directory.Packages.props	Removes the MicroBuild.Core package version.
.azure-pipelines/scripts/install-vs-cpp-workload.ps1	Adds VS C++ workload bootstrap/verification logic.
.azure-pipelines/scripts/enable-projfs.ps1	Adds ProjFS optional-feature enablement logic for CI.
.azure-pipelines/release.yml	Replaces MicroBuild release pipeline with 1ES PT build/sign/release flow.
.azure-pipelines/esrp/sign.yml	Adds reusable ESRP signing step template.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mjcheetham]

Fair point, but given we treat the ESRP inline op JSON blob as an opaque data structure (generated by an ESRP tool we use) I'd like to keep this per artifact. Especially if we ever decide to publish, say, a NuGet package in the future.. that uses different signing key codes and settings.

[derrickstolee]

I believe that we've never shipped FastFetch through the public project before. But should we? Is this an opportunity to unify and clarify that tool's signing and publishing story?

[mjcheetham]

Yeah, I intentionally omitted publishing FastFetch since we've not published it externally (at least not in the past 6 years!) If we find teams or others want FastFetch published 'officially' then we can add this easily to the GitHub releases later. For now it can be manually downloaded from the pipeline artifacts.

[derrickstolee]

Should we even allow manual runs? Should the only trigger be a push to the release branch (gated by PR)?

[mjcheetham]

We have allowed manual runs in the past to allow for testing and debugging of the release workflow against non-release branches. Pipeline queue permissions are still restricted to members of the Git Client team, so only a restricted few of us can make releases still.

I'd like to keep manual as an option for now until we have put this pipeline through more real-world usage :-)

[mjcheetham]

Updated following Copilot's comments.. here's the range-diff:

 1:  b20b5552 =  1:  b20b5552 Build: drop MicroBuild signing wiring
 2:  21364aeb =  2:  21364aeb GVFS.Installers: gate CreateInstaller on $(SkipCreateInstaller)
 3:  f4b46619 !  3:  f3af9cd7 .azure-pipelines: migrate release pipeline from MicroBuild to 1ESPT + ESRP
    @@ .azure-pipelines/release.yml
     +      - stage: release
     +        displayName: 'Release'
     +        dependsOn: [build]
    -+        condition: and(succeeded(), eq('${{ parameters.github }}', true))
    ++        # Only publish a draft GitHub release when ESRP signing was enabled in
    ++        # this run -- otherwise we would risk uploading unsigned installer
    ++        # binaries to the public release workflow.
    ++        condition: and(succeeded(), eq('${{ parameters.github }}', true), eq('${{ parameters.esrp }}', true))
     +        jobs:
     +          - job: github
     +            displayName: 'Publish GitHub release'
 4:  58460323 =  4:  2fab771a .azure-pipelines: publish debug symbols with GitHub Release
 5:  64fc64e0 =  5:  11a41476 .azure-pipelines: install pinned .NET SDK from global.json
 6:  56aec454 =  6:  d7a11ae7 Build.bat: fail when VS MSBuild is missing
 7:  b57f278d !  7:  8721e68c .azure-pipelines: install VS C++ workload before build
    @@ .azure-pipelines/release.yml: extends:
      ## .azure-pipelines/scripts/install-vs-cpp-workload.ps1 (new) ##
     @@
     +#
    -+# Ensure the Visual Studio "Desktop development with C++" workload is
    -+# installed on the build agent.
    ++# Ensure a Visual Studio 2022 (or newer) install with the "Desktop
    ++# development with C++" workload is present on the build agent.
     +#
    -+# .NET NativeAOT publishing (used by every managed VFS for Git project via
    -+# PublishAot=true in Directory.Build.props) requires the C++ build tools
    -+# from this workload at publish time.
    ++# .NET NativeAOT publishing (used by every product-facing managed VFS for
    ++# Git project via PublishAot=true in Directory.Build.props) requires the
    ++# C++ build tools from this workload at publish time. The native VFS
    ++# projects also build against the v143 toolset, which ships with VS 2022.
     +#
     +# This script handles three situations:
    -+#   1. The C++ workload is already present -> exit early.
    -+#   2. Visual Studio (any product) is installed but the C++ workload is
    -+#      missing -> modify the install to add it.
    -+#   3. No Visual Studio at all -> install VS Build Tools 2022 with the
    -+#      VC tools workload.
    ++#   1. A VS 2022+ install with the C++ workload is already present
    ++#      -> exit early.
    ++#   2. A VS 2022+ install (any product) is present but the C++ workload
    ++#      is missing -> modify that install to add it.
    ++#   3. No VS 2022+ install at all -> install VS Build Tools 2022 with
    ++#      the VC tools workload. (An older VS install, e.g. VS 2019, is
    ++#      ignored here -- we leave it alone and install VS 2022 alongside.)
     +#
     +# vswhere.exe is bootstrapped from GitHub if not already on disk.
     +#
    @@ .azure-pipelines/scripts/install-vs-cpp-workload.ps1 (new)
     +$vswhereDownloadUrl    = 'https://github.com/microsoft/vswhere/releases/latest/download/vswhere.exe'
     +$buildToolsDownloadUrl = 'https://aka.ms/vs/17/release/vs_BuildTools.exe'
     +
    ++# The native VFS projects build against the v143 toolset, which ships with
    ++# Visual Studio 2022 (product line 17.x). VS 2019 (16.x) carries v142 and
    ++# is not sufficient -- so all vswhere queries below are scoped to 17.0+.
    ++$minVsVersion = '[17.0,)'
    ++
     +# Either of these workloads provides the C++ build tools we need.
     +# Microsoft.VisualStudio.Workload.NativeDesktop = "Desktop development with C++" (Community/Pro/Enterprise).
     +# Microsoft.VisualStudio.Workload.VCTools       = "C++ build tools" (Build Tools).
    @@ .azure-pipelines/scripts/install-vs-cpp-workload.ps1 (new)
     +        [Parameter(Mandatory = $true)] [string]   $VswhereExe,
     +        [string[]]                                $RequiredWorkloads
     +    )
    -+    $vswhereArgs = @('-latest', '-prerelease', '-products', '*', '-format', 'json')
    ++    $vswhereArgs = @('-latest', '-prerelease', '-products', '*', '-version', $script:minVsVersion, '-format', 'json')
     +    if ($RequiredWorkloads -and $RequiredWorkloads.Count -gt 0) {
     +        $vswhereArgs += '-requires'
     +        $vswhereArgs += $RequiredWorkloads
    @@ .azure-pipelines/scripts/install-vs-cpp-workload.ps1 (new)
     +# --- Find any VS install (regardless of workloads) ---
     +$install = Find-VsInstall -VswhereExe $vswhereExe
     +
    -+# --- If no VS at all, install VS Build Tools with the VC workload ---
    ++# --- If no VS 2022+ install at all, install VS Build Tools 2022 with the VC workload ---
     +if (-not $install) {
    -+    Write-Host "No Visual Studio installation found; installing VS Build Tools 2022 with the C++ workload..."
    ++    Write-Host "No Visual Studio 2022 (or newer) installation found; installing VS Build Tools 2022 with the C++ workload..."
     +    $bootstrapper = Join-Path $env:TEMP 'vs_BuildTools.exe'
     +    Write-Host "Downloading VS Build Tools bootstrapper from $buildToolsDownloadUrl..."
     +    Invoke-WebRequest -Uri $buildToolsDownloadUrl -OutFile $bootstrapper -UseBasicParsing
 8:  c859c6fc !  8:  0f30e3db .azure-pipelines: enable Projected File System for unit tests
    @@ .azure-pipelines/scripts/enable-projfs.ps1 (new)
     +$result = Enable-WindowsOptionalFeature -Online -FeatureName $featureName -NoRestart -ErrorAction Stop
     +
     +if ($result.RestartNeeded) {
    -+    Write-Warning "Windows optional feature '$featureName' was enabled but a restart is required to take effect."
    ++    # The pipeline runs unit tests immediately after this script which P/Invoke
    ++    # into ProjectedFSLib.dll. If the OS reports a reboot is required to make
    ++    # the feature usable, the build agent is in an inconsistent state and the
    ++    # tests will fail unpredictably -- so fail fast here instead.
    ++    throw "Windows optional feature '$featureName' was enabled but a restart is required to take effect; failing the build."
     +} else {
     +    Write-Host "INFO: Windows optional feature '$featureName' is now enabled."
     +}
 9:  51e58dc9 =  9:  c21ed310 GVFS.Payload: drop VS code-analysis marker files from payload
10:  fe60e1c3 = 10:  6eaea92f .azure-pipelines: introduce esrp/sign.yml template

[mjcheetham]

Run with the latest changes: https://dev.azure.com/mseng/1ES/_build/results?buildId=31501969

All green! I specifically ran with GitHub=true and ESRP=false to trigger the new condition we have added on release publishing.. it worked - step was skipped.

[dscho]

Is this change intentional? Windows runners tend to be slower than Linux runners...

[mjcheetham]

We need to re-archive our PDB symbols since the artifact that gets uploaded/downloaded between jobs gets the _manifest/ and internal SBOM stuff added. We need to keep release jobs separate since 1ES policies restrict certain job types from being 'build' vs 'release'.

We want to publish as a ZIP and the ArchiveFiles@2 task requires zip, which isn't on the Ubuntu images (nor can we install it mid-pipeline for reasons above).