Add assembly signing for Microsoft.Data.SqlClient and the AKV Provider

[paulmedynski]

What's This All About?

This is PR 4 of 6 in the assembly signing stack that builds on #4568.

The first 5 PRs in this stack are all about adding assembly signing and public-key-protected InternalsVisibleTo support to the legacy CI pipeline. This is infrastructure work necessary to support the Native AOT fix in the final PR.

We have never been including assembly signing in our CI, which IMO was a blind spot. Now, when CI runs in our internal ADO.Net project, all assemblies will be signed, we will be running tests against signed assemblies, and fully testing our nascent inter-assembly IVT just as it would be in a real app. Public project CI and all of our PR pipelines will continue to use unsigned assemblies, and testing that requires inter-assembly IVT will only be done in Project mode (PR, legacy CI Project-mode pipeline) or via internal CI with signed assemblies.

The 6th and final PR in the stack addresses the Native AOT issue #4193 by eliminating inter-assembly reflection and using signed IVT with proper package dependencies.

Description

This PR sets up assembly signing in the legacy CI pipeline for Microsoft.Data.SqlClient itself and for the Always Encrypted Azure Key Vault provider. These are the last two shipping packages in the legacy CI flow that were not receiving SigningKeyPath, so internal Package-mode builds could produce a mix of signed and unsigned artifacts.

Unlike the earlier PRs in this stack, MDS already carries a public-key-qualified InternalsVisibleTo grant for UnitTests in Microsoft.Data.SqlClient.csproj. What was missing was the pipeline plumbing to actually supply the keys, so that grant was never exercised. This PR supplies them.

This PR:

• threads isInternalBuild through the CI core into the SqlClient package stage, the MDS/AKV build job, and the test stage and test jobs;
• downloads the driver strong-name signing key in the MDS/AKV build job, and both the driver and test keys in the test jobs, for internal Package-reference builds only;
• adds a signingKeyPath parameter to ci-project-build-step.yml and passes it through to both the MDS and AKV Provider builds;
• adds signingKeyPath and testSigningKeyPath parameters to run-all-tests-step.yml and passes them to every build.proj test invocation - unit, functional and manual, including the flaky variants, the x86 variants, and the Linux/macOS paths - so tests always build and run against a consistently signed set of assemblies; and
• threads SigningKeyPath into the TestSqlClientUnit, TestSqlClientFunctional and TestSqlClientManual targets in build.proj, and groups the arguments in those targets into build / test / reference-type sections to match the rest of the file.

TestSqlClientUnit already passed TestSigningKeyPath; without the matching SigningKeyPath the driver would be rebuilt unsigned underneath a signed test assembly, and the public-key-qualified IVT grant would not match.

Supplying SigningKeyPath activates the existing signing behavior in src/Directory.Build.props; this PR does not change product source, public APIs, package contents beyond assembly signing, or compatibility behavior.

The second commit pre-applies the review feedback already addressed on #4566 and #4567 so the same comments aren't raised again here: the split download-driver-signing-key-step.yml / download-test-signing-key-step.yml templates, positive referenceType comparisons, no parameter defaults, and consistent "strong-name signing" terminology in the parameter documentation.

Issues

Works towards addressing #4193.

Testing

This is a pipeline and build.proj change, so no unit or integration tests were added.

The coverage gain is that the full MDS test suite - unit, functional and manual - now runs against strong-named driver and test assemblies on internal CI. That is the configuration in which the UnitTests public-key-qualified IVT grant actually has to match; previously it was only ever compiled in the unsigned configuration.

The GitHub PR validation pipelines exercise the public Package-reference and Project-reference paths. The internal signing branch requires the ADO.Net secure files and is exercised only by an internal Package-reference pipeline run.

CI pipeline runs

The GitHub PR pipelines never set isInternalBuild, so they always take the unsigned path. As with #4566 and #4567, the four CI runs below are what actually exercise this change, covering all four quadrants of the signing matrix. Run links and the tools/PackageValidator artifact verification table will be added here once the runs complete.

Project	Pipeline	Reference mode	Signing expected
public	CI-SqlClient	Project	No - public
public	CI-SqlClient-Package	Package	No - public
ADO.Net	MDS Main CI	Project	No - Project mode
ADO.Net	MDS Main CI-Package	Package	Yes - internal + Package

The expectation is that the MDS and AKV package stages and the test stages succeed in all four runs, that the Download Driver Signing Key and Download Test Signing Key steps appear only in MDS Main CI-Package, and that only that quadrant's MDS.Artifacts and AKV packages report Signed with the 23ec7fc2d6eaa4a5 public key token.

[Copilot]

Pull request overview

This PR wires up internal CI support for strong-name signing of Microsoft.Data.SqlClient and the AKV provider by threading an isInternalBuild flag through pipeline templates, downloading signing keys from ADO secure files, and passing signing-related MSBuild properties into build.proj-driven build/test steps.

Changes:

• Plumbs a new isInternalBuild parameter through core/stage templates so internal builds can enable extra steps (assembly signing).
• Adds secure-file download + parameter plumbing to pass signing key paths into build/test template invocations (including separate test signing key support).
• Updates build.proj test target dotnet test invocations to include signing-related MSBuild arguments (with review feedback about unintended signing of test assemblies).

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
eng/pipelines/stages/build-sqlclient-package-ci-stage.yml	Adds isInternalBuild parameter and forwards it to the SqlClient package build job.
eng/pipelines/dotnet-sqlclient-ci-core.yml	Threads isInternalBuild into the SqlClient package stage and test stage template calls.
eng/pipelines/common/templates/steps/run-all-tests-step.yml	Adds signingKeyPath / testSigningKeyPath parameters and passes them through to build.proj test targets.
eng/pipelines/common/templates/steps/ci-project-build-step.yml	Adds signingKeyPath parameter and forwards it to build.proj for MDS/AKV builds.
eng/pipelines/common/templates/stages/ci-run-tests-stage.yml	Adds isInternalBuild parameter and forwards it into the test job template.
eng/pipelines/common/templates/jobs/ci-run-tests-job.yml	Downloads driver/test signing keys (internal + Package mode) and forwards their paths to the test step template.
eng/pipelines/common/templates/jobs/ci-build-nugets-job.yml	Downloads the driver signing key (internal + Package mode) and forwards it to the build step template for package builds.
build.proj	Threads signing-related properties into dotnet test commands; also uses SigningKeyPath to include/exclude category=signed tests.

Suppressed comments (2)

build.proj:694

• Forwarding SigningKeyPath into the functional/manual test project build will strong-name sign those test assemblies with the driver key via src/Directory.Build.props. This is likely unnecessary (and potentially undesirable) if only UnitTests needs signing (with TestSigningKeyPath) to satisfy InternalsVisibleTo for signed packages.

        <!-- Build arguments -->
        -p:Configuration=$(Configuration)
        $(SigningKeyPathArgument)

        <!-- Test arguments -->

build.proj:728

• For UnitTests, TestSigningKeyPath is the mechanism intended to sign the test assembly for IVT when the driver is signed in Package mode. Forwarding SigningKeyPath here additionally signs the test assembly with the driver key (unless overridden) and enables STRONG_NAME_SIGNING for the test build, which seems outside the stated goal of signing tests only with the test key.

        <!-- Build arguments -->
        -p:Configuration=$(Configuration)
        $(SigningKeyPathArgument)
        $(TestSigningKeyPathArgument)

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

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

[Copilot]

🔵 Needs a closer look

The changes affect CI orchestration and internal-only secure-file signing flows, which are high-impact and best validated via full pipeline execution and human review.

Review details

• Files reviewed: 8/8 changed files
• Comments generated: 0 new
• Review effort level: Lite