Add assembly signing for Microsoft.Data.SqlClient.Extensions.Azure

[paulmedynski]

What's This All About?

This is PR 5 of 6 in the assembly signing stack that builds on #4569.

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 is the last of the signing-infrastructure PRs, and covers Microsoft.Data.SqlClient.Extensions.Azure. With it, every package produced by an internal Package-mode CI run is strong named, and every test assembly that needs internal access is signed with the test key.

The shape mirrors #4568: Azure has a test project, so both the product assembly and the test assembly need signing, plus a public-key-qualified InternalsVisibleTo grant to connect them.

This PR:

• threads isInternalBuild through the CI core into the Azure stage, the Azure pack job, and all five Azure test jobs;
• downloads the driver strong-name signing key in the pack job, and both the driver and test keys in the test jobs, for internal Package-reference builds only;
• passes SigningKeyPath when packing Microsoft.Data.SqlClient.Extensions.Azure, and both SigningKeyPath and TestSigningKeyPath when building the test project;
• adds a public-key-qualified InternalsVisibleTo grant for the test assembly, used only when the build is both signed and in Package mode. The existing unqualified grant still covers every unsigned configuration, and signed + Project mode is deliberately omitted so that production-signed assemblies never grant internal access to locally built test assemblies;
• signs the Azure test assembly when TestSigningKeyPath is supplied; and
• threads the signing arguments into the build.proj TestAzure target.

It also renames the test job's buildArguments variable to dotnetBuildOpts. That is not cosmetic: Azure Pipelines exports job variables as environment variables, and dotnet build picks up $BUILDARGUMENTS implicitly, so a variable named buildArguments gets injected into the build a second time. The same rename was made in the Abstractions test job in #4568.

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, quoted secure-file paths, positive referenceType comparisons, no parameter defaults, the duplicated signing conditional collapsed, and a normalized BuildNumber/FileVersion note across the pack branches.

Issues

Works towards addressing #4193.

Testing

This is a pipeline and project-file change, so no unit or integration tests were added.

As with #4568, the coverage gain is that the Azure test suite now runs on internal CI with both the product and test assemblies strong named, so a broken public-key-qualified IVT grant surfaces as a compile error rather than passing silently.

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 Build Azure Package stage succeeds 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 Azure.Artifacts package reports Signed with the 23ec7fc2d6eaa4a5 public key token.

[Copilot]

Pull request overview

Enables strong-name signing for the Microsoft.Data.SqlClient.Extensions.Azure assembly in internal CI package-mode builds, including signing the corresponding test assembly to keep InternalsVisibleTo (IVT) working when the product assembly is signed.

Changes:

• Adds conditional test-assembly signing in Azure.Test.csproj when TestSigningKeyPath is provided.
• Updates Azure.csproj IVT to include the test public key only for signed + Package reference builds.
• Threads an isInternalBuild flag through the Azure CI stage/jobs and passes signing key properties to dotnet build/pack; also updates build.proj to pass signing properties to the Azure test invocation.

Reviewed changes

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

Show a summary per file

File	Description
src/Microsoft.Data.SqlClient.Extensions/Azure/test/Azure.Test.csproj	Conditionally strong-name signs the test assembly when a test key path is supplied.
src/Microsoft.Data.SqlClient.Extensions/Azure/src/Azure.csproj	Adjusts IVT to support signed package-mode builds (public-key IVT only when signing is enabled).
eng/pipelines/stages/build-azure-package-ci-stage.yml	Adds and propagates isInternalBuild into Azure build/test/pack job templates.
eng/pipelines/jobs/test-azure-package-ci-job.yml	Downloads signing keys and passes SigningKeyPath/TestSigningKeyPath for internal package-mode builds; avoids {command}Arguments env-var injection by renaming the variable.
eng/pipelines/jobs/pack-azure-package-ci-job.yml	Adds signing key download and passes SigningKeyPath into dotnet pack for internal package-mode builds.
eng/pipelines/dotnet-sqlclient-ci-core.yml	Threads isInternalBuild into the Azure package stage invocation.
build.proj	Includes signing-related MSBuild properties when running the Azure test project via build orchestration.

---

💡 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 7 out of 7 changed files in this pull request and generated no new comments.

[Copilot]

🟢 Approval recommended

The signing and IVT changes are consistently gated to internal Package-mode builds and are correctly threaded through the Azure CI stage/jobs and build.proj without introducing API surface changes.

Review details

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