azure-pipelines: Restore signing project from internal NuGet feed to avoid nuget.org requests

[Copilot]

Why builds were hitting nuget.org

The signing template azure-pipelines/templates/sign.yml runs DotNetCoreCLI@2 with command: "build" on the consumer repo's SignExtension.signproj. That signproj has a <PackageReference> on Microsoft.VisualStudioEng.MicroBuild.Core, so dotnet build performs an implicit dotnet restore against whatever NuGet sources the agent has configured — by default the public api.nuget.org/v3/index.json feed. That's the source of the outbound NuGet traffic. The npm side already routes through ${{ parameters.npmFeed }} (DevDiv/azcode), which is why npm was already internal but NuGet wasn't.

The v2 templates under azdo-pipelines/ use a different signing flow (DDSignFiles.dll from $MBSIGN_APPFOLDER) and don't run dotnet build on a NuGet-referencing project, so they're unaffected.

Fix

• Added a new nugetFeed parameter (default DevDiv/azcode) to azure-pipelines/templates/sign.yml.
• Inserted an explicit DotNetCoreCLI@2 restore step using feedsToUse: select + vstsFeed: ${{ parameters.nugetFeed }} before the build step(s).
• Added --no-restore to both DotNetCoreCLI@2 build invocations (single-vsix and multi-vsix branches) so the build step doesn't trigger an implicit restore that would bypass the explicit one.
• Plumbed nugetFeed through azure-pipelines/1esmain.yml and azure-pipelines/1esstages.yml, with the same DevDiv/azcode default as npmFeed.
• Documented the feed prerequisite in azure-pipelines/README.md.

nugetFeed: '' opts out cleanly (falls back to default NuGet sources = previous behavior), so the parameter is fully optional.

Manual steps required (cannot be automated)

The DevDiv/azcode Azure Artifacts feed currently only mirrors npm. To finish the fix, do one of the following in Azure DevOps:

1. Recommended: add api.nuget.org/v3/index.json as a NuGet upstream source on the DevDiv/azcode feed (Feed Settings → Upstream sources → Add upstream → Public source → nuget.org). The first signing build after this change will populate the feed with Microsoft.VisualStudioEng.MicroBuild.Core and its transitive dependencies on demand; nothing else needs to change downstream.
2. Or point a specific downstream extension pipeline at a different NuGet-enabled feed by passing nugetFeed: '<Project>/<Feed>' when extending azure-pipelines/1esmain.yml@azExtTemplates.
3. Or, for a given pipeline, pass nugetFeed: '' to fall back to the default NuGet sources (i.e., keep the previous behavior).

Notes

• The release pipeline (azure-pipelines/release-extension.yml) does not run dotnet, so it does not need this change.
• YAML validated locally.

[Copilot]

Pull request overview

This PR updates the legacy Azure Pipelines signing flow to restore signing-project NuGet dependencies from an internal Azure Artifacts feed before building, reducing unintended public nuget.org traffic.

Changes:

• Adds a nugetFeed parameter with DevDiv/azcode defaults and passes it through the 1ES templates.
• Adds an explicit DotNetCoreCLI@2 restore step for SignExtension.signproj.
• Uses --no-restore for signing builds and documents the NuGet feed prerequisite.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
azure-pipelines/templates/sign.yml	Adds explicit NuGet restore and prevents implicit restore during signing builds.
azure-pipelines/1esmain.yml	Exposes and forwards the new nugetFeed parameter.
azure-pipelines/1esstages.yml	Forwards nugetFeed into the signing template.
azure-pipelines/README.md	Documents the signing NuGet feed requirement and override behavior.

---

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

[bwateratmsft]

Nothing is working for this.