Add assembly signing for Microsoft.SqlServer.Server - #4566
Draft
paulmedynski wants to merge 2 commits into
Draft
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the Azure DevOps pipeline templates to enable strong-name (assembly) signing for Microsoft.SqlServer.Server in internal build scenarios, and centralizes secure-file key download logic into a reusable step template.
Changes:
- Added a shared
download-assembly-signing-key.ymlstep template to download signing keys from secure files. - Threaded
isInternalBuild(andreferenceType) through the CI core → SqlServer stage/job to conditionally applySigningKeyPathduring packing. - Updated OneBranch build steps and the internal package CI pipeline to use the shared download template and the new
driverKeyFilereference.
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| eng/pipelines/stages/build-sqlserver-package-ci-stage.yml | Adds referenceType / isInternalBuild parameters and forwards them to the SqlServer pack job. |
| eng/pipelines/onebranch/steps/build-buildproj-step.yml | Switches to the shared signing-key download template and uses driverKeyFile.secureFilePath. |
| eng/pipelines/onebranch/jobs/validate-signed-package-job.yml | Comment wording tweak around strong-name signing verification. |
| eng/pipelines/jobs/pack-sqlserver-package-ci-job.yml | Conditionally downloads signing key + passes SigningKeyPath for internal Package-mode packing. |
| eng/pipelines/dotnet-sqlclient-ci-project-reference-pipeline.yml | Passes isInternalBuild into the core template based on System.TeamProject. |
| eng/pipelines/dotnet-sqlclient-ci-package-reference-pipeline.yml | Passes isInternalBuild into the core template based on System.TeamProject. |
| eng/pipelines/dotnet-sqlclient-ci-core.yml | Introduces isInternalBuild parameter and forwards it into the SqlServer build stage. |
| eng/pipelines/common/steps/download-assembly-signing-key.yml | New reusable step template to download driver/test SNK secure files. |
| eng/pipelines/ci/package/sqlclient-ci-package-pipeline.yml | Uses the shared signing-key download template in internal package CI pipeline. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
paulmedynski
commented
Aug 21, 2026
| inputs: | ||
| secureFile: netfxKeypair.snk | ||
| name: driverKeyFile | ||
| - template: /eng/pipelines/common/steps/download-assembly-signing-key.yml@self |
Contributor
Author
There was a problem hiding this comment.
This PR adds a shared helper template to download signing keys, so you will see changes to several pipeline like this.
| - Project | ||
|
|
||
| # True when building on the internal ADO.Net project. | ||
| - name: isInternalBuild |
Contributor
Author
There was a problem hiding this comment.
You will see this concept throughout the PR stack, used to determine when assembly signing is required.
The PR pipelines (legacy and modern) always use Project mode, and never sign any assemblies. They will not have this concept.
The modern CI pipeline always uses Package mode, and when running on ADO.Net, it will sign all assemblies (driver and test).
The legacy CI pipelines use both Project and Package mode. In Project mode, no signing occurs, so internal vs public doesn't matter. In Package mode and internal, we will be signing everything to satisfy InternalsVisibleTo safely.
paulmedynski
force-pushed
the
dev/paul/assembly-signing-sqlserver
branch
from
August 21, 2026 15:33
1da18ed to
9bb6342
Compare
paulmedynski
added
Area\Engineering
This was referenced Aug 21, 2026
Introduce the shared signing-key download step and thread isInternalBuild through the CI core so the SqlServer package is strong-name signed on internal Package-mode builds. - Add eng/pipelines/common/steps/download-assembly-signing-key.yml, which exports driverKeyFile or testKeyFile from ADO secure files. - Adopt that step in the OneBranch build and nightly CI package pipelines, renaming keyFile to driverKeyFile. - Declare isInternalBuild in dotnet-sqlclient-ci-core.yml and set it from the CI package- and project-reference pipelines. - Sign the SqlServer package when isInternalBuild is true and referenceType is not Project.
paulmedynski
force-pushed
the
dev/paul/assembly-signing-sqlserver
branch
from
August 21, 2026 20:28
9bb6342 to
a222a0c
Compare
- Quote SigningKeyPath in buildProperties so the secure-file path is robust to spaces, matching build-buildproj-step.yml and sqlclient-ci-package-pipeline.yml. - Move the BuildNumber/FileVersion note directly above buildProperties in both the signed and unsigned pack branches. No change to signing behaviour: signing stays gated on internal Package-reference builds.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What's This All About?
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 the SqlServer project.
Microsoft.SqlServer.Serverwas not receivingSigningKeyPathwhen it was packed by the internal, Package-reference CI flow. As a result, that package could be produced without the strong-name signing applied to the other internal package artifacts. Internal Package-mode builds need a consistent set of signed assemblies; public builds and Project-reference builds should continue to build without access to the internal signing key.This PR:
driverKeyFileoutput name;isInternalBuildandreferenceTypethrough the CI core, SqlServer stage, and SqlServer pack job;SigningKeyPathwhen packingMicrosoft.SqlServer.Serveronly for internal Package-reference builds; andSupplying
SigningKeyPathactivates the existing signing behavior insrc/Directory.Build.props; this PR does not change product source, public APIs, package contents beyond assembly signing, or compatibility behavior.Issues
Works towards addressing #4193.
Testing
This is a pipeline-only change, so no unit or integration tests were added.
The GitHub PR validation pipelines exercise the public Package-reference and Project-reference paths and are currently running. The internal signing branch requires the ADO.Net secure file and is exercised only by an internal Package-reference pipeline run.